Challenge, Easy,  on  Kubernetes

Multi-Container Pod Security Design

Omkar Shelke
by  Omkar Shelke

Scenario

You need to create a Pod with two containers that run as different users but share a common group ID for file access. This is a common pattern when multiple containers need to collaborate on shared files while maintaining process isolation.

Tasks

  1. Create a Pod named twin-uid in the sec-ctx namespace.
  2. Configure two containers in the Pod:
    • Container named preproc running as user ID 1000
    • Container named shipper running as user ID 2000
  3. Both containers must use the image public.ecr.aws/docker/library/busybox:stable.
  4. Configure both containers to remain running (use a command like sleep infinity).
  5. Set a Pod-level security context with fsGroup (choose your own value) so both containers can share file access.
Hint 1 — Pod-Level vs Container-Level securityContext

Kubernetes Pods support securityContext in two places, and they serve different purposes:

  • spec.securityContext — Pod-level settings, applied to every container and volume in the Pod.
  • spec.containers[].securityContext — per-container settings, applied only to that one container.

Think about which of these two locations fits a setting that must be shared by both containers, versus a setting that needs a different value for each container. The general shape looks like this:

apiVersion: v1
kind: Pod
spec:
  securityContext:
    <pod-wide-setting>: <your-chosen-value>
  containers:
  - name: <container-name>
    securityContext:
      <container-specific-setting>: <its-value>

Documentation

Hint 2 — Choosing the fsGroup Value

There's nothing special about the number you pick for fsGroup — it just needs to be a positive integer, and it doesn't have to match either container's runAsUser. Its purpose is purely to set the supplemental group ownership on mounted volumes so that processes running as different UIDs (1000 and 2000 in this case) can still read/write the same files via shared group permissions.

Pick any value you like, for example 3000, and set it under spec.securityContext.fsGroup.

Hint 3 — Keeping Both Containers Running

The busybox image exits immediately unless you give it something to do. Override the container's command so it keeps running, for example:

command: ["sleep", "infinity"]

Add this to both the preproc and shipper container specs so the Pod reaches and stays in the Running state with both containers reporting ready: true.

⚒ Test Cases

How to Author Challenges on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull challenge content

labctl content pull challenge security-contexts-in-multi-container-pods-09f6fb9f

This will create a local copy of the challenge content in a directory named security-contexts-in-multi-container-pods-09f6fb9f. You only need to do this once per challenge.

Stream your changes

labctl content push -fw challenge security-contexts-in-multi-container-pods-09f6fb9f

Run this command in a separate terminal to continuously upload your changes to the server while editing the challenge in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help

Start challenge