Chapter 11: Additional security considerations

Introduction

The introduction previews Podman security topics and warns against using --privileged as a quick fix for denied container access.

• Additional security topics: Describe the chapter’s security-focused review of how containers run, Linux isolation features, image trust and signing, and where applications run.
  Why it matters: This gives you a map of the security questions the chapter will revisit.
• Privileged mode as a shortcut: Explain why the author cautions against responding to denied container access by running with --privileged: it turns off the container’s security separation, whereas understanding the relevant security features helps avoid that shortcut.
  Why it matters: A denied operation calls for understanding the security restriction, not automatically removing the container’s separation.

Key terms: fork and exec, Linux security features, container image trust, signing images, --privileged mode, security separation

11.1 Daemon versus the fork/exec model

11.1.1 Access to the docker.sock

This section shows how access to Docker’s root-owned daemon can grant host root privileges and contrasts that risk with rootless Podman’s user-level access.

• Docker socket privilege escalation: Explain why a user who can access /run/docker.sock may be able to obtain a fully privileged root shell on the host, even if that user did not start as root.
  Why it matters: Access to the Docker socket can amount to root access on the host.
• Rootless limits and log evidence: Distinguish rootless Podman’s user-level file access from the host root access available through Docker’s socket, and describe how a host root shell could let an attacker remove Docker’s file-based logs that administrators might examine.
  Why it matters: The privilege level of container processes affects both what they can change and what evidence an administrator may find.

Key terms: root-owned daemon, docker group, /run/docker.sock, root shell, rootless Podman, user UID, file-based logging, audit logs

11.1.2 Auditing and logging

This section shows how Podman’s fork/exec model preserves the launching user’s identity in Linux audit records, while Docker’s daemon model obscures it.

• Loginuid inheritance across processes: Explain how the kernel records a user’s loginuid and why it remains with processes started by that user, including processes launched through su, sudo, or Podman. Contrast this with Docker containers, which inherit the system-started daemon’s unset loginuid.
  Why it matters: The process ancestry explains why the two engines leave different evidence about who launched a container.
• Audit trail for container actions: Trace how the audit subsystem uses loginuid to attribute an auditable container action to a user. Describe the section’s watched /etc/passwd example and why an unset Docker audit identity makes access to docker.sock difficult to attribute.
  Why it matters: Audit attribution matters when investigating which user launched a container involved in a host compromise.

Key terms: loginuid, /proc/self/loginuid, fork/exec model, Docker daemon, 4294967295, audit subsystem, audit.log, auditctl, auid, /etc/passwd

11.2 Podman secret handling

This section explains how Podman supplies secrets to containers without saving them in images created by committing those containers.

• Secrets in committed images: Explain why applications should not hardcode secrets into images and why passing a secret as an ordinary environment variable can expose it when a container is committed to an image.
  Why it matters: The risk of saving a password in an image explains why Podman provides a separate secret mechanism.
• Podman secret delivery: Describe how `podman secret` supplies a file or environment-variable secret to a container without saving that secret in an image made by committing the container. State how the section passes `my_secret` as a secret environment variable.
  Why it matters: This lets a service receive a needed password without preserving it in a committed image.

Key terms: secret, environment variables, commit, image, podman secret, --secret my_secret,type=env

11.3 Podman image trust

This section explains how Podman image trust policies control which image sources are accepted, rejected, or required to provide signed images.

• Image trust scope and precedence: Explain how an image’s transport and registry host identify its source, and how Podman applies the most specific matching trust policy before falling back to the default policy.
  Why it matters: Scope and precedence determine whether a broad registry rule or a narrower repository rule governs an image pull.
• Trust policy configuration and outcomes: Describe how `podman image trust` sets acceptance and rejection rules in `/etc/containers/policy.json`, and how to view the resulting settings. Explain the section’s lockdown example: reject sources by default while allowing `docker.io/library`, signed images from `registry.redhat.io`, and images pulled directly from `docker-daemon`.
  Why it matters: An explicit policy lets operators limit where production images can come from.
• Trust command execution limits: State where and with what privileges the image trust commands must run: as root on Linux, not in Podman remote mode; Podman machine users can enter its VM with `podman machine ssh`.
  Why it matters: Running the command in the wrong environment or without root privileges prevents the policy change.

Key terms: transport, registry host, registry scope, repository, default, policy.json, podman image trust, podman image trust show, accept, reject

11.3.1 Podman image signing

This section shows how to sign an image during a Podman push, publish its signature, and configure Podman to accept signed images while rejecting unsigned ones.

• GPG image signing workflow: Describe how simple signing uses a GPG key pair to sign an image when Podman pushes it to a remote registry, and where Podman initially stores the signature.
  Why it matters: Signing an image creates the evidence that clients can later use to verify it.
• Signature publication infrastructure: Explain why signatures must be made available separately from images and how Podman is directed to retrieve them from a web service.
  Why it matters: Clients cannot verify a signature unless they can retrieve it.
• Signed image pull verification: Describe how to configure trust for a repository using the signer's public GPG key, then demonstrate that a signed pull succeeds and an unsigned pull is rejected.
  Why it matters: The successful and failed pulls show that the signature requirement is actually being enforced.

Key terms: GPG key pair, simple signing, podman push, sigstore-staging, sigstore, /etc/containers/registries.d/default.yaml, image trust, policy.json, publickey.gpg, signature

11.4 Podman image scanning

This section shows how Podman helps external tools scan an image safely by mounting its contents without running code from the image.

• Mounted image scanning: Explain that Podman is not an image scanner, but it can mount an image so a scanner can inspect its contents without executing code from that image. Explain why scanning with host tools is safer than relying on tools inside the image.
  Why it matters: An image could contain tampered scanning tools, so the choice of tools affects whether a scan can be trusted.
• Rootless image inspection sequence: Describe the rootless example: enter the user namespace with podman unshare, mount the ubi8 image, change to its mount directory, and use the host's find command to locate setuid binaries.
  Why it matters: Entering the user namespace makes mounting possible in rootless mode, after which ordinary host tools can inspect the image.

Key terms: image scanner, mounted content, host operating system, rootless mode, user namespace, podman image mount, podman unshare, ubi8, find

11.5 Security in depth

Introduces security in depth as layered protection and says Podman applies it by using Linux security mechanisms together.

• Layered container security: Explain security in depth as using multiple protective layers so an attacker must get through each one, and describe how Podman applies this idea by using Linux security mechanisms together.
  Why it matters: Thinking in layers helps explain why container security does not rest on a single safeguard.

Key terms: security in depth, Linux security mechanisms

11.5.1 Podman uses all security mechanisms simultaneously

Podman can layer multiple container defenses, and users should tailor those defenses to an application rather than disable them wholesale.

• Simultaneous security layers: Explain that Podman containers can use multiple security mechanisms at once, so an attacker who compromises a container must overcome several defenses to reach the host.
  Why it matters: A container compromise does not automatically mean the host is compromised.
• Selective security adjustments: Explain why a container that needs a relaxed security setting should have that setting adjusted specifically rather than be run with --privileged.
  Why it matters: A targeted adjustment can let an application run without discarding its other defenses.
• Application-specific container hardening: Describe how knowing an application’s requirements lets you strengthen its container security, using measures such as not running as root, dropping unneeded capabilities, using rootless containers, read-only mode, or separated user namespaces.
  Why it matters: Removing permissions an application does not need makes its security barriers stronger.

Key terms: read-only filesystems, namespaces, dropped capabilities, SELinux, seccomp, --privileged, security mechanisms, rootless containers, rootful containers, Linux capabilities

11.5.2 Where should you run your containers?

The section shows how to strengthen container security by separating workloads across VMs, machines, and networks.

• Layered workload separation: Explain how a web frontend and a sensitive database can be separated progressively: in different containers on one system, in containers on separate VMs, and on separate machines.
  Why it matters: Containers need not be the only boundary between workloads with different security needs.
• Frontend and database placement: Describe the example placement: an internet-exposed web frontend in a DMZ and the credit-card database in a private network, rather than treating both workloads as equally exposed.
  Why it matters: Where a workload runs matters alongside the isolation layers around it.

Key terms: containers, VMs, separate machines, web frontend, database with credit card data, DMZ, private network

11.6 Summary

The summary ties container isolation and image control together as complementary ways to protect the host.