The recent Bitnami changes made one thing very clear: container image catalogs can become infrastructure dependencies.

Docker Hardened Images (DHI) are an interesting alternative. The community catalog is free, published under Apache 2.0, and provides minimal images, SBOMs, provenance, and a very small CVE surface.

There is a lot to like about DHI. But before you move everything over, ask yourself one question: what if DHI is the next Bitnami?

On September 17, I took the beta of the new Certified Kubernetes Network Engineer, CKNE, exam. It was one of the hardest hands-on certification exams I have taken so far. The challenge was not one extremely deep topic, but moving quickly across a broad Kubernetes networking stack within a two-hour time limit.

CKNE combines core Kubernetes networking with Cilium, Istio, Gateway API, security, observability, and newer areas such as inference traffic. Because the exam is still in beta, difficulty and timing may change before the final version.

Since Kubernetes v1.36, image volumes are stable. They allow Kubernetes to pull an OCI image or artifact and mount its filesystem into a container. At first glance, this looks like a small storage feature, but it enables a much more interesting concept: platform-managed runtimes.

In this model, the application team publishes the application artifact, while the platform team provides and maintains the environment required to run it. Kubernetes combines both when the Pod starts, so the application team no longer needs to package Java, operating system libraries, and CA certificates into every application image.

Helm is a fantastic packaging and lifecycle tool—until you hit one of its hardest limits:

Error: create: failed to create: Secret "sh.helm.release.v1.my-release.v1" is invalid: 
data: Too long: must have at most 1048576 bytes

Helm stores release state in a Kubernetes object, and Kubernetes objects have a hard 1 MiB size limit. If your chart grows large (hello, “monster CRDs”), you can end up in a situation where helm install/upgrade fails even though nothing is “wrong” with your Kubernetes cluster.

Many developers use GitHub Actions. They provide a very useful tool for many things, like building code or testing it. Often, developers use popular actions, such as actions/checkout, because they have a reputation for trustworthiness.

But could someone change a trusted action without anyone knowing?

In this post, a problem with how GitHub forks work will be shown. This problem lets a bad person put their own code into a trusted action, even if they lack permission to change the action.

Kubernetes DNS provides a streamlined way for pods to discover one another using short, user-friendly names, keeping complex IP addresses out of sight. Yet, this very convenience can mask a significant security flaw. Without a thorough grasp of Kubernetes DNS behavior, an opening for attackers might unknowingly be created. Consider this: the ability to create namespaces and services allows an attacker to reroute traffic intended to leave a cluster, diverting it for their own purposes.