Phase 2: Containers & Orchestration

Non-Root Containers & Read-Only Filesystems

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Hey there! Imagine you're in a big, busy kitchen where lots of people are baking different things at the same time. Each person has their own little baking station. Now, some people in the kitchen have a special "Head Chef" badge. This badge means they can do anything: open any cupboard, change any recipe, add new ingredients to the main pantry, or even move the ovens around! That's a lot of power. In the computer world, we have something similar called a "root" user, who can do anything inside their little digital baking station, called a "container." But sometimes, we only need someone to bake a specific cake, not run the whole kitchen. So, we give them a "Baker's Assistant" badge instead. This assistant can only use the ingredients for their cake, follow their recipe, and put their cake in the oven. If they make a mistake or try to do something they shouldn't, they can't mess up the whole kitchen or other people's baking stations. This is what we call using a "non-root" container – it means giving just enough power for the job, and no more.

Now, let's think about those recipes. What if someone tries to change the main chocolate chip cookie recipe so it uses salt instead of sugar? That would be a disaster! To stop this, we can make some recipes "read-only." Imagine your recipe card is printed in a cookbook or laminated – you can read it, you can follow every step to bake your cake, but you can't scribble on it, cross out ingredients, or add new steps to the original recipe itself. It stays exactly the same for everyone. In our digital world, we can make a container's main recipe book, its "filesystem," read-only. This means that once the container starts up, no one can add new digital ingredients, change existing instructions, or secretly sneak in bad code.

So, when we combine these two ideas – a Baker's Assistant using a laminated, read-only recipe – it makes our kitchen super safe! If a naughty Baker's Assistant tries to sneak some super spicy peppers into the main cookie recipe, they can't, because the recipe is laminated. Even if they accidentally burn their own batch of cookies, they can't change the main oven settings for everyone else or steal ingredients from another person's baking station because they don't have that "Head Chef" badge. This combination makes it much harder for someone who is up to no good to cause big problems or make lasting changes.

This means that when grown-up developers like me build "digital baking stations" (which are our containers) for websites or apps, we make sure they have a "Baker's Assistant" badge and a "laminated recipe." This lets them do their important job of making our favorite websites and apps work smoothly, without letting anyone mess up the main kitchen or sneak in unwanted changes. It's like making sure everyone in a busy kitchen can bake delicious things safely, without making a huge, unfixable mess for everyone else!

When running containers, a common security hardening practice is to execute processes as a non-root user inside the container. By default, many container images run processes as the root user. While this root inside a container isn't the root of the host system (thanks to namespaces), it still grants extensive privileges within the container's isolated environment. Should an attacker compromise a container running as root, they gain significant control, making it easier to potentially escalate privileges or further attack other services. Adopting non-root containers adheres to the principle of least privilege, drastically limiting the potential blast radius of a breach by ensuring the container process only has the permissions it absolutely needs to function.

Complementing non-root users are read-only filesystems. This security control configures the container's primary filesystem to be immutable after startup, meaning no new files can be written, existing files cannot be modified, and binaries cannot be tampered with. This capability significantly reduces an attacker's ability to persist within a compromised container, install malicious software, or modify critical application components. For applications that genuinely need to write data (e.g., logs, temporary files, uploads), this is handled by mounting separate volumes (like emptyDir or PersistentVolume) at specific paths, which are writable. This clear separation reinforces the container's immutability and makes its behavior more predictable and auditable.

Implementing non-root containers alongside read-only filesystems provides a powerful defense-in-depth strategy. Non-root users limit what a process can do, while a read-only filesystem restricts where it can write. Together, they create a robust security boundary that makes containers significantly harder to exploit and compromise. This combination reduces the attack surface, improves the overall security posture of your applications, and aligns with best practices for secure containerization, pushing towards more resilient and predictable deployments. While it requires careful planning for data persistence and application configuration, the security benefits far outweigh the setup complexity for most production workloads.

Key Takeaways

  • Non-root users enforce the principle of least privilege, limiting an attacker's control within a compromised container.
  • Read-only filesystems prevent unauthorized writes, modifications, or installation of malicious files inside the container.
  • Combine both for a strong defense-in-depth strategy, significantly reducing the container's attack surface.
  • For necessary writes (logs, temporary data), always use explicitly mounted volumes that are writable.

Code Example

yaml
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsUser: 1000 # Run container processes as user ID 1000
    runAsGroup: 1000 # Use group ID 1000
  containers:
  - name: my-container
    image: myregistry/my-app:latest
    securityContext:
      readOnlyRootFilesystem: true # Make the root filesystem read-only
      allowPrivilegeEscalation: false # Prevent processes gaining more privileges
    volumeMounts:
    - name: app-data
      mountPath: /app/data # Mount a writable volume for specific data
  volumes:
  - name: app-data
    emptyDir: {} # Example: a temporary writable volume

How this code works

This code defines a Kubernetes Pod engineered for strong security, ensuring an application runs with minimal privileges and a largely immutable filesystem. Its primary job is to demonstrate how to restrict what an application can do and where it can write, making it harder for vulnerabilities to be exploited or for an attacker to persist changes.

The Pod achieves this by first setting a securityContext at the Pod level with runAsUser: 1000 and runAsGroup: 1000, ensuring all container processes execute as a non-root user. Inside the container's securityContext, readOnlyRootFilesystem: true locks down the main operating system files, preventing the application from modifying its own binaries or critical system components. Furthermore, allowPrivilegeEscalation: false acts as a crucial safeguard, preventing any process from gaining higher privileges within the container. A subtle but vital aspect is the inclusion of volumeMounts and volumes like emptyDir: {} for /app/data. Even with a read-only root, applications frequently need designated areas to write dynamic data or logs; this pattern provides a specific, writable location for legitimate operations without compromising the security of the core filesystem.

Related Articles

Hand-picked reads to go deeper on container security.

Back to DevOps Engineer Roadmap