In Kubernetes, containers typically start with root privileges.

This happens because, by default, container processes run as UID 0 unless overridden.

Kubernetes does not impose a non-root policy; it inherits whatever the image defines.

This isn't a bug, it's a design choice carried over from Docker.

While convenient during development, it introduces unnecessary risk in production environments.

If an attacker compromises the container, root access increases the likelihood of privilege escalation to the host.

The Kubernetes API offers several ways to restrict container privileges using the Security Context.

With it, you can control the user a container runs as, manage Linux capabilities, enforce read-only filesystems, and block privilege escalation.

However, despite its importance, Security Contexts are often misunderstood or misapplied.

Many teams discover these controls only after a security audit or scanner flags a running container.

The next steps are usually reactively patching the config, suppressing the warning and moving on.

Before we get into Kubernetes SecurityContexts, we need to understand what they're actually configuring under the hood.

As infrastructure as code (IaC) becomes a foundational pillar of modern cloud-native and DevOps practices, tools that bridge the gap between existing infrastructure and code are increasingly valuable. One such powerful utility is Terraformer, an open-source tool developed by Google that helps users generate Terraform configurations from existing infrastructure resources. This article thoroughly explores Terraformer, including its architecture, use cases, benefits, challenges, and practical examples.

We recently wrote a Terraform provider for an internal API at Typeform. This allowed us to manage mutable runtime data stored in an API through source files, with good change control, and a nice developer experience. Some of the steps were a little tricky, or required us to trawl through documentation, and I thought to myself: “I hope this is easier next time we do it!”

For a long time, Kubernetes resource management has been synonymous with Helm.

There have been plenty of attempts to replace Helm and its templating miasma known as Charts. But those attempts never seem to stick, sometimes because they’re not different enough, or more often because the size and mass of the Helm ecosystem creates an inertia that’s hard to overcome.

This post explores how Yoke is trying to do the impossible: introducing Flights, a complete alternative to Helm Charts, while bringing Helm along for the ride.

Kwatcher is a Kubernetes operator that:

1. Automatically creates a ConfigMap from data fetched from an external URL using a secured Secret,
2. Periodically polls the URL (based on refreshInterval),
3. Updates the ConfigMap when the data changes,
4. And automatically triggers pod redeployment via annotations in the related Deployments.

A deployment orchestration tool that simplifies multi-cloud, multi-region, and multi-service deployments.

Layer 4 Kubernetes load-balancer

Product ready cluster lifecycle management toolchains based on kubespray and other cluster LCM engine.

Backup Docker volumes locally or to any S3, WebDAV, Azure Blob Storage, Dropbox, Google Drive or SSH compatible storage

DockFlare is a powerful, self-hosted ingress controller that simplifies Cloudflare Tunnel and Zero Trust management. It uses Docker labels for automated configuration while providing a robust web UI for manual service definitions and policy overrides.