Container Security PDF

Liz Rice

Scan to Download
 Container Security
Assessing Security Risks in Cloud Native Container
Deployments
Written by Bookey
Check more about Container Security Summary
Listen Container Security Audiobook

Scan to Download
About the book
In today's fast-paced technological landscape, many
organizations leverage cloud-native environments to run
applications using containers and orchestration for enhanced
scalability and resilience. But ensuring the security of these
deployments is crucial. In "Container Security," Liz Rice,
Chief Open Source Officer at Isovalent, offers a practical
guide to understanding the foundational technologies that
underpin container systems. This book equips developers,
operators, and security professionals with the knowledge to
evaluate security risks and implement effective solutions.
Readers will gain insights into the inner workings of
containerization within Linux, empowering them to assess
potential vulnerabilities in their deployments. If you're familiar
with container tools like kubectl or Docker and comfortable
using Linux command-line utilities such as ps and grep, you’re
well-prepared to delve into the essential concepts presented in
this vital resource.

Scan to Download
About the author
Liz Rice is a prominent figure in the field of container security
and cloud-native computing, recognized for her expertise and
thought leadership in the realm of software security. As the
Chief Technology Officer at Aqua Security, she plays a pivotal
role in shaping strategies that address security challenges in
modern containerized environments. With a rich background
in software development and a passion for DevSecOps, Liz
has contributed extensively to the open-source community,
sharing her knowledge through engaging talks at various tech
conferences and her insightful writings. Her work not only
emphasizes the importance of securing applications in the
cloud but also empowers developers and organizations to
adopt robust security practices in their container ecosystems.

Scan to Download
Summary Content List
Chapter 1 : 1. Container Security Threats

Chapter 2 : 2. Linux System Calls, Permissions, and

Capabilities

Chapter 3 : 3. Control Groups

Chapter 4 : 4. Container Isolation

Chapter 5 : 5. Virtual Machines

Chapter 6 : 6. Container Images

Chapter 7 : 7. Software Vulnerabilities in Images

Chapter 8 : 8. Strengthening Container Isolation

Chapter 9 : 9. Breaking Container Isolation

Chapter 10 : 10. Container Network Security

Chapter 11 : 11. Securely Connecting Components with TLS

Chapter 12 : 12. Passing Secrets to Containers

Chapter 13 : 13. Container Runtime Protection

Chapter 14 : 14. Containers and the OWASP Top 10

Scan to Download
Chapter 15 : Conclusions

Chapter 16 : Security Checklist

Scan to Download
 Chapter 1 Summary : 1. Container
Security Threats

Chapter Content

Chapter 1: Container Security

Threats Overview of Containerization: Containers encapsulate applications, easing dependency
management and allowing simultaneous operations without conflicts.
Security Perspective: Unique risks in container environments due to architecture.
Understanding Risks and Threats:

Risk: Issues arising from a threat (e.g., data theft).

Threat: Means through which a risk may occur (e.g., phishing).
Mitigation: Countermeasures to reduce threat success.

Risk Management Framework & Threat Modeling: Identifying and prioritizing threats to
define mitigations.
Container Threat Model: Actors include external attackers, internal attackers, malicious
internal actors, inadvertent internal actors, and application processes.
Potential Attack Vectors: Vulnerable code, misconfigured images, build machine attacks,
supply chain attacks, host system vulnerabilities, exposed secrets, and misconfigured
networks.
Security Boundaries: Containers as protection boundaries isolating application processes.
Multitenancy Considerations: Shared hardware implies stronger boundaries to prevent
cross-user vulnerabilities.
Container Instances: Managed services can lead to colocated instances requiring strong
security measures.
Security Principles:

Least Privilege
Defense in Depth
Reducing Attack Surface
Limiting Blast Radius
Segregation of Duties

Conclusion: Emphasizes importance of understanding threats and security principles for

containerized environments.

Scan to Download
Chapter Content

Chapter 2: Linux System

Calls, Permissions, and Understanding the Linux Environment: Containers typically operate on Linux;
Capabilities understanding its features is crucial for security.
System Calls: Applications use system calls to interact with the Linux kernel,
necessitating permissions for operations.
File Permissions: Governed by discretionary access control (DAC) affecting user actions
on files.
setuid and setgid: setuid allows execution with owner permissions, posing a security
threat.
Linux Capabilities: Provide fine-grained control over actions, enhancing security by
granting necessary process privileges.
Privilege Escalation: Gaining unauthorized permissions, often exploited by attackers
from low-privileged accounts.
Summary of Key Concepts: Covers essential Linux mechanisms relevant to container
security, establishing a foundation for understanding containerization and mitigations.

Chapter 1: Container Security Threats

Overview of Containerization

The use of containers has surged, especially with Docker's

release in 2013, which popularized container technology.
Containers encapsulate an application and its dependencies,
enabling uniform execution across different environments
and easing dependency management. They facilitate the
simultaneous operation of multiple applications on the same
machine without conflicts.

Security Perspective

Scan to Download
Despite the familiar threats in traditional systems (data theft,
unauthorized access), container environments introduce
unique risks due to their architecture.

Understanding Risks and Threats

-
Risk
: Potential issues if a threat is realized (e.g., data theft).
-
Threat
: The means through which a risk may materialize (e.g.,
phishing).
-
Mitigation
: Countermeasures to reduce threat success likelihood.
An organization's specific risk landscape varies, impacting
how they prioritize threats and enforce mitigations.

Risk Management Framework & Threat Modeling

A risk management framework systematically identifies and

prioritizes threats to define suitable mitigation strategies.
Threat modeling entails identifying potential vulnerabilities

Scan to Download
in a system.

Container Threat Model

Consider various actors involved in a threat model:

1.
External Attackers
: Target the deployment from outside.
2.
Internal Attackers
: Have gained access to parts of the system.
3.
Malicious Internal Actors
: Privileged users with potential for harm.
4.
Inadvertent Internal Actors
: Users causing issues accidentally.
5.
Application Processes
: Could unintentionally compromise the system.

Potential Attack Vectors

- Vulnerable application code.

Scan to Download
- Incorrectly configured container images.
- Build machine attacks that modify container images.
- Supply chain attacks altering deployed images.
- Vulnerable host systems impacting container security.
- Exposed secrets, misconfigured networking, and container
escape vulnerabilities.

Security Boundaries

A security boundary or trust boundary imposes different

permission requirements for interactions. Containers serve as
security boundaries, keeping application processes isolated.

Multitenancy Considerations

Multitenancy involves different users running workloads on

shared hardware, requiring stronger boundaries to prevent
interference. Sharing allows for vulnerabilities that may
impact all users on the same host.

Container Instances

Managed services (e.g., AWS Fargate) allow container

execution without managing the infrastructure. However,

Scan to Download
they might be colocated with instances from other users,
necessitating cautious security considerations.

Security Principles

1.
Least Privilege
: Limit access strictly based on necessity.
2.
Defense in Depth
: Utilize multiple protective layers to safeguard against
breaches.
3.
Reducing Attack Surface
: Simplify systems to minimize potential attack points.
4.
Limiting Blast Radius
: Segment security controls to contain damage.
5.
Segregation of Duties
: Ensure critical actions require cooperation between
different users.
Security principles guide the effective use of containers to
mitigate risks and implement proper defenses while

Scan to Download
maintaining operational efficiency.

Conclusion

This chapter introduces critical threats and security principles

relevant to containerized environments. Understanding these
concepts is essential for applying security best practices in
future discussions of container mechanisms and security
tools.
---

Chapter 2: Linux System Calls, Permissions, and

Capabilities

Understanding the Linux Environment

Containers primarily operate on Linux. Familiarity with

Linux features is vital for understanding security
implications. This chapter covers system calls, file-based
permissions, and capability management.

System Calls

Scan to Download
Applications interact with the Linux kernel through system
calls, requiring permissions to perform operations like file
access and network communication. While specific system
calls are typically abstracted in higher-level programming,
they are crucial for understanding containerized processes.

File Permissions

File permissions are foundational in Linux security,

determining user actions related to files. Discretionary access
control (DAC) grants access based on user and group
ownership, visible via commands like `ls -l`.

setuid and setgid

The setuid bit allows files to execute with the permissions of

the file owner rather than the invoking user, presenting a
potential security threat.

Linux Capabilities

Linux capabilities enable finer-grained control over specific

actions (e.g., binding to network ports) compared to
traditional setuid. They allow for increased security by

Scan to Download
granting only necessary privileges to processes.

Privilege Escalation

Privilege escalation refers to gaining unauthorized

permissions, often starting from a low-privileged user.
Attackers exploit vulnerabilities in services running higher
privileges.

Summary of Key Concepts

This chapter provides essential knowledge of Linux

mechanisms relevant to container security. It serves as a
foundation for understanding containerization's intersection
with Linux capabilities, permissions, and privileged access,
setting the stage for discussions on mitigations in subsequent
chapters.

Scan to Download
Example
Key Point:Understanding and Mitigating Container
Security Risks
Example:As you deploy containerized applications, it’s
crucial to recognize unique risks; for instance, if an
external attacker discovers a vulnerability in your
container images, you could face data breaches.
Therefore, implementing a rigorous risk management
framework to identify potential threats and prioritize
mitigations becomes essential in safeguarding your
deployment.

Scan to Download
Critical Thinking
Key Point:The unique architectural risks of
container environments versus traditional systems.
Critical Interpretation:Liz Rice highlights that while the
familiar threats of data theft and unauthorized access
persist in containerization, there are unique architectural
risks inherent to this technology. This perspective urges
a reconsideration of standard security practices, as it
suggests that containers may introduce new
vulnerabilities that could compromise their intended
advantages. Readers should critically assess this
viewpoint, particularly given ongoing debates
surrounding the security strengths and weaknesses of
containers compared to virtual machines (VMs). It’s
essential to explore various sources, such as research by
Gartner (2020) and findings from the Cloud Native
Computing Foundation (CNCF), which offer differing
views on container security efficacy. Ultimately, while
Rice articulates a valid concern regarding container
architecture, it invites scrutiny and a broader discourse
on security practices across different environments.

Scan to Download
Chapter 2 Summary : 2. Linux System
Calls, Permissions, and Capabilities

Chapter 2: Linux System Calls, Permissions, and

Capabilities

Containers primarily run on Linux, hence understanding the

fundamental Linux features, including system calls,
file-based permissions, and capabilities, is crucial for
container security. This knowledge informs how permissions
are assigned at runtime or during the container image build
process.

System Calls

Scan to Download
- Applications operate in user space, requiring the kernel to
perform actions like accessing files or network
communication on their behalf via system calls (syscalls).
- There are over 300 system calls in modern Linux kernels,
which are generally abstracted for application developers via
libraries such as glibc and the Golang syscall package.
- Containers share the same kernel and, hence, security
implications arise because all containers can utilize the same
syscall interface.
- Features exist to limit the system calls a program can
access, enhancing security by adhering to the principle of
least privilege.

File Permissions

- File permissions are a fundamental aspect of security in

Linux, dictating which users can access files and what
actions they can perform.
- Permissions are represented in three groups (for owner,
group, and others) with read (r), write (w), and execute (x)
bits.
- Operations like setuid and setgid allow executables to run
with higher privileges than they would normally have,
raising potential security concerns.

Scan to Download
- The setuid bit enables a process to inherit the user ID of the
file owner, which can introduce vulnerabilities if
mismanaged.

Linux Capabilities

- The Linux kernel includes over 30 capabilities that refine

privilege control, allowing specific actions without granting
full root privileges.
- Examples include capabilities for binding low-numbered
ports or loading kernel modules.
- Setting capabilities can provide necessary privileges for
certain commands (like the ping command) enhancing
security without giving excessive permissions.

Privilege Escalation

- Privilege escalation involves gaining additional permissions

beyond what should normally be available, often via
exploiting system vulnerabilities.
- Attackers frequently target processes running as root,
exploiting any vulnerabilities that permit remote code
execution, posing significant risks if not managed correctly.
- Containerized environments pose higher risks if they

Scan to Download
default to running applications as root, as any compromised
application within could threaten the host system.

Summary

Chapter 2 highlights crucial Linux mechanisms related to

system calls, permissions, and capabilities, foundational for
understanding container security. These concepts apply in
various security states; the subsequent chapter will introduce
more about container mechanisms, emphasizing the
relationship between host root access and containerized
processes.

Scan to Download
 Chapter 3 Summary : 3. Control Groups
Chapter Content

Chapter 3:
Control Groups Cgroups Overview: Foundation of containerization limiting process resource usage (memory,
CPU, network I/O) to prevent resource monopolization.
Cgroup Hierarchies: Organized by resource type with each Linux process assigned a cgroup upon
creation.
Creating Cgroups: Establish new directories within memory hierarchy to set resource limits using
kernel-generated files.
Setting Resource Limits: Illustrated through modifying the `config.json` for runc to enforce
memory limitations.
Assigning a Process to a Cgroup: Processes assigned by writing the PID into `cgroup.procs` file.
Docker and Cgroups: Docker automatically implements cgroups for resource management during
container operations.
Cgroups V2: Introduced in Linux kernel 4.6; simplifies management but presents compatibility
challenges.
Summary: Cgroups are crucial for resource management and security against resource exhaustion
in Linux environments.

Chapter 4:
Container Linux Namespaces: Control resource visibility and access among processes with types including
Isolation UTS, PID, Mount, Network, User, IPC, and Cgroup Namespaces.
Changing the Root Directory: Controlled by `chroot`, limiting filesystem visibility in containers.
Combining Namespacing and Changing Root: Containers use both for isolation and unique root
filesystem.
Container Processes from the Host Perspective: Containers share the kernel with the host, raising
security concerns if host access is compromised.
Best Practices for Container Hosts: Recommendations include running containers on dedicated
hosts, using thin OS distributions, and adopting immutable infrastructure.
Summary: Containers utilize namespaces and cgroups for isolation and resource control,
highlighting the need for vigilant security practices in shared host environments.

Chapter 3: Control Groups

In this chapter, we explore control groups (cgroups), a

foundational element of containerization. Cgroups limit the
resources (memory, CPU, network I/O) utilized by groups of
processes, preventing them from monopolizing resources and

Scan to Download
impacting other applications. They are critical for securing
system integrity, notably in scenarios like fork bombs which
can rapidly create processes leading to resource exhaustion.

Cgroup Hierarchies

Cgroups are organized in hierarchies categorized by resource

type, managed via cgroup controllers. Each process in Linux
is assigned a cgroup upon creation, inheriting characteristics
from its parent’s cgroups, with information accessible
through the pseudo-filesystem at `/sys/fs/cgroup`.

Creating Cgroups

To create a cgroup, a new directory within the memory

hierarchy can be established. The kernel auto-generates files
for parameters, where files like `memory.limit_in_bytes` and
`memory.usage_in_bytes` are manipulated to set and monitor
resource limits for processes.

Setting Resource Limits

Install Bookey App to Unlock Full Text and
Resource limits ensure thatAudio
a process doesn't consume
excessive memory, which could lead to starvation of other

Scan to Download
 Chapter 4 Summary : 4. Container
Isolation
Section Description

Chapter Title Container Isolation

Overview This chapter covers container isolation mechanisms, highlighting the use of unique Linux features
for security.

Key Linux Features Includes Namespaces and Cgroups to manage resource visibility and control available resources.

Namespaces Control resource visibility for processes. Types: UTS, PID, Mount, Network, User, IPC.

Cgroups Manage resources like CPU and memory for processes.

Isolating Hostname UTS namespace allows for isolated hostnames; processes can be run using `unshare` command.

Isolating Process IDs PID namespace shows only container processes; can be demonstrated with `unshare` command.

Changing the Root The `chroot` command isolates filesystems, crucial for container isolation.
Directory

Combining Features Integrating namespaces and `chroot` achieves effective isolation for containers.

Mount Namespace Provides separate mount namespaces to prevent visibility of host filesystems.

Network Namespace Containers maintain their own network setups, including loopback and virtual Ethernet interfaces.

User Namespace Maps user IDs in containers for enhanced security; allows users to run containers as root without
host risks.

IPC Namespace Ensures containers have separate IPC namespaces for secure inter-process communication.

Cgroup Namespace Isolates cgroup configurations for processes from the host system.

Container Processes Containers share a kernel with the host, limiting filesystem and resource visibility for security.
Perspective

Best Practices for Use dedicated hosts, minimal OS environments, and monitor logs for secure container management.
Container Hosts

Conclusion Understanding Linux features for isolation is critical for application security; future chapters will
cover more on container security techniques.

Chapter 4: Container Isolation

Scan to Download
Overview

This chapter explores the mechanisms of container isolation,

emphasizing how containers operate similarly to virtual
machines but rely on unique Linux features for their security
boundaries. Understanding these differences is crucial for
assessing the security measures suitable for containerized
applications.

Key Linux Features for Isolation

-
Namespaces
: These control the visibility of resources for processes,
providing various types such as:
- UTS: Isolates hostname and domain names.
- PID: Restricts visible process IDs.
- Mount: Provides independent filesystem views.
- Network: Isolates network interfaces and routing tables.
- User: Allows separate user and group IDs in containers.
- IPC: Manages communication between processes via
shared memory.
-
Cgroups

Scan to Download
: Control the resources (CPU, memory, etc.) available to a
process.

Understanding Namespaces

Namespaces provide distinct environments for processes:

- Each process can be assigned to its own namespace,
allowing it to operate independently of others.
- Using the command `lsns`, users can view the current
namespaces.

Isolating the Hostname

By creating a UTS namespace, processes can have their own

isolated hostnames. The `unshare` command is used to run
processes in their own namespaces.

Isolating Process IDs

Inside a container, commands like `ps` only display

processes running within that container thanks to the PID
namespace. To demonstrate this, processes can be run using
the `unshare` command to create a new PID namespace.

Scan to Download
Changing the Root Directory

The `chroot` command changes the perceived root directory

for processes, limiting their visibility of the filesystem. This
is an essential feature for container isolation:
- A container uses an encapsulated filesystem from its image.
- A practical example involving Alpine Linux illustrates how
to execute commands in a new root directory.

Combining Features for Effective Isolation

By combining namespaces (e.g., PID) with changing the root

directory and mounting a new `/proc` directory, containers
can be fully isolated, showing only their internal processes.

Mount Namespace

- Containers are typically given their mount namespace to

prevent them from seeing the host's filesystem.
- Commands can create separate mount points that are
isolated from the host.

Network Namespace

Scan to Download
- Containers maintain their own routing and network setups,
started with a loopback interface.
- Setting up virtual Ethernet interfaces allows the container to
communicate externally.

User Namespace

- This allows mapping of user IDs within containers,

enabling root privileges in containers while protecting the
host.
- Although not widely implemented, this feature enhances
security by allowing unprivileged users to effectively run
containers as root.

Inter-process Communications Namespace

Processes need access to shared memory within the same IPC

namespace, and containers are given separate IPC
namespaces to secure communication.

Cgroup Namespace

Like chroot for cgroups, this namespace keeps a process from

seeing configurations higher than its assigned cgroup.

Scan to Download
Container Processes from the Host Perspective

Containers maintain a kernel shared with the host while

exhibiting limited filesystem and resource views, crucial for
security.

Best Practices for Container Hosts

To minimize risks:
- Use dedicated hosts for containers, whether physical or
virtual.
- Opt for minimalistic "Thin OS" environments to reduce the
attack surface.
- Regularly monitor logs and alert for suspicious activities
related to host access.

Conclusion

Overall, understanding container isolation through Linux

features like namespaces and cgroups is fundamental for
ensuring application security and preventing potential
vulnerabilities. Future chapters will further explore container
security techniques and the distinctions between
containerization and virtualization.

Scan to Download
Example
Key Point:Understanding Container Isolation is
Essential for Outmaneuvering Security Risks.
Example:Imagine you're a security officer overseeing a
facility where each department has its own fenced area,
preventing unauthorized access. This mirrors the
function of Linux namespaces in container security,
isolating resources and processes to ensure threats
remain contained. As you manage these spaces, you'll
appreciate how each department's independence, just
like the PID and mount namespaces for containers,
allows you to mitigate potential risks effectively,
safeguarding the entire operation from external
vulnerabilities.

Scan to Download
Critical Thinking
Key Point:The Importance of Understanding Linux
Isolation Features
Critical Interpretation:While Liz Rice outlines that
Linux namespaces and cgroups are vital for container
security, readers should critically evaluate this stance.
Relying solely on these features may lead to
misunderstandings about their limits. For example,
namespaces, while effective, can introduce complexity
in managing container security and may not suffice
against sophisticated attacks. Additionally, the notion
that containers can operate securely as if they were
completely isolated virtual machines oversimplifies the
inherent risks tied to shared kernel usage. Critics might
argue, as supported by research from the National
Institute of Standards and Technology (NIST), that
additional security layers and comprehensive policy
frameworks are necessary to truly safeguard
containerized environments, suggesting that an
overreliance on Linux features might lead to an illusion
of security.

Scan to Download
Chapter 5 Summary : 5. Virtual
Machines

Chapter 5: Virtual Machines

Introduction

This chapter explores the differences between virtual

machines (VMs) and containers, particularly focusing on the
isolation they provide. Understanding how VMs operate will
help assess security boundaries when applications run in
containers or VMs—a crucial aspect for discussions about
container security.

Booting Up a Machine

When a physical server boots, the BIOS or UEFI scans

hardware availability, which leads to the bootloader running
the operating system’s kernel. The kernel operates at a higher
privilege level than application code, managing memory and
user-space programs.

Scan to Download
Enter the VMM

Virtual Machine Monitors (VMMs) manage virtual

machines, providing an abstraction over hardware resources
by allocating memory and CPU, setting up virtual devices,
and ensuring resource boundaries are maintained.

Types of VMM

1.
Type 1 VMMs (Hypervisors):
Run directly on the hardware without a host OS. Examples
include Hyper-V and Xen, operating at Ring 0. Guest
operating systems operate at lower privilege levels.
2.
Type 2 VMMs:
Run on top of a host operating system, like VirtualBox,
where the hypervisor operates within user space.
3.
Kernel-Based Virtual Machines (KVM):
A hybrid approach where the virtual machine monitor runs
within the Linux kernel.

Scan to Download
Trap-and-Emulate

VMMs use a technique where certain privileged CPU

instructions are trapped and emulated by the VMM, ensuring
guest OSs do not interfere with one another. Unique
challenges arise from handling non-privileged but sensitive
instructions.

Process Isolation and Security

ACHieving process isolation is essential for security:

physical isolation (running on entirely separate machines)
offers the strongest guarantee. However, kernel management
bugs could lead to unauthorized memory access, making
VMs generally more secure than containers due to their
isolation boundaries and reduced complexity.

Disadvantages of Virtual Machines

Though VMs provide strong isolation, their considerable

startup times and resource overhead pose significant
challenges compared to containers, which are more efficient
and speedier to deploy, particularly in auto-scaling and
frequent code updates.

Scan to Download
Container Isolation Compared to VM Isolation

Containers may share a kernel, leading to weaker isolation

than VMs. However, enhanced security features and
sandboxing in containers can mitigate these weaknesses.
Understanding these dynamics is essential in discussing
container security.

Summary

The chapter explains the concepts of virtual machines, the

isolation they offer, the differences with containers, and the
importance of understanding these for assessing security. It
highlights potential vulnerabilities due to kernel complexity
and stresses the significance of VMs in security contexts,
preparing for subsequent discussions on container images.
---

Chapter 6: Container Images

Introduction

Scan to Download
This chapter delves into container images used in platforms
like Docker or Kubernetes, clarifying their composition,
usage, and significance in security.

Root Filesystem and Image Configuration

Container images comprise two parts: the root filesystem,

which includes the structure and files necessary for runtime,
and configuration that tailors image behavior. Dockerfiles
play a pivotal role in defining these elements compounding
the importance of secure image construction.

Overriding Config at Runtime

Docker allows runtime configuration overrides through

command-line parameters, enhancing flexibility for
user-defined environments in Kubernetes deployment
constructs.

OCI Standards

The Open Container Initiative (OCI) sets standards for

container images, ensuring compatibility and consistent user
experiences. Tools like Skopeo and umoci facilitate the

Scan to Download
handling and inspection of OCI-compliant images.

Image Configuration and Building Images

Understanding how image configurations interact with

runtime behaviors is vital. Observations on image tagging
emphasize security practices against potential vulnerabilities
enacted during the build phase.

The Dangers of Docker Build

The use of the Docker daemon introduces risks, primarily

around unauthorized access potentially allowing malicious
modifications during the image creation process. Exploring
daemonless builds enhances security.

Image Layers and Sensitive Data

The concept of image layers introduces challenges regarding

sensitive data—unintentionally included files may remain
accessible through layers. Proper practices must be observed
to safeguard confidentiality.

Storing Images and Image Security

Scan to Download
Container images must be securely stored in registries,
emphasizing image integrity measures to prevent
unauthorized alterations that could lead to deploying
malicious code.

Admission Control and Deployment Security

Validating the security of images through admission control

ensures that only images meeting security standards are
deployed, which is vital for maintaining production integrity.

GitOps and Deployment Security

The GitOps methodology enhances security through

controlled access to infrastructure changes, fostering
traceability and minimizing direct human intervention in
production environments.

Conclusion

This chapter underscores the complexity and importance of

securing container images, detailing practices for building,
storing, and deploying images. It sets the stage for the next

Scan to Download
chapter, which addresses vulnerabilities in dependencies
encapsulated within container images.

Scan to Download
Chapter 6 Summary : 6. Container
Images

Chapter 6: Container Images

This chapter covers the fundamentals of container images,

their components, and the security implications of building,
storing, and using them. Below is a summary of the key
points discussed in this chapter:

Container Image Components

- A container image consists of two main parts: the root

filesystem and configuration settings.
- The root filesystem includes directories and files that the
container uses while the configuration might specify
parameters like environment variables, ports, and user
settings.

Overriding Configuration at Runtime

- Configuration can be overridden using command-line

Scan to Download
parameters in Docker or through YAML definitions in
Kubernetes.

OCI Standards

- The Open Container Initiative (OCI) was created to

standardize container images and runtimes, allowing
compatibility across platforms.
- OCI specifications detail how images are built and
distributed, and tools like Skopeo and umoci aid in
manipulating and unpacking OCI images.

Building Images

- Building images often utilizes a Dockerfile with a series of

instructions.
- Security concerns arise during the build process since the
Docker daemon requires root privileges, potentially exposing
sensitive operations.

Security Risks in Build Processes

Install Bookey App to Unlock Full Text and
Audiosocket can execute
- Users with access to the Docker
commands, leading to potential abuse.

Scan to Download
Chapter 7 Summary : 7. Software
Vulnerabilities in Images

Chapter 7. Software Vulnerabilities in Images

Introduction to Software Vulnerabilities

Patching vulnerabilities is crucial for maintaining secure

deployments. As container technology evolves, so does the
patching process. This chapter discusses software
vulnerabilities, their identification, publication, and
management in the context of containers.

Vulnerability Research

A vulnerability denotes flaws in software that attackers can

exploit. More complex software typically presents a higher
incidence of such flaws. There’s a dedicated industry for
identifying and reporting vulnerabilities, particularly in
operational software like OS packages and libraries.
Noteworthy vulnerabilities like Shellshock, Meltdown, and

Scan to Download
Heartbleed often gain significant attention but represent only
a small fraction of reported cases annually.

Responsible Security Disclosures

Upon identifying a vulnerability, security researchers

typically contact the software developers or vendors before
public disclosure to allow a timely patch release, minimizing
the window for potential exploits. Vulnerabilities receive
unique identifiers (CVE) for tracking in the National
Vulnerability Database (NVD).

Understanding Patches and Distributions

The complexity of assessing vulnerability risks is highlighted

through examples like Shellshock, where patched software
versions exist across various distributions. It emphasizes that
users need to consult both CVEs and the pertinent security
advisories for their specific Linux distributions to determine
vulnerability status accurately.

Application-Level Vulnerabilities

Vulnerabilities also arise at the application level, frequently

Scan to Download
through third-party libraries managed by specific package
managers (like npm for Node.js). The chapter underscores
the importance of assessing these libraries while noting the
potential for vulnerabilities even in standalone binaries that
may not have external dependencies.

Vulnerability Risk Management

Managing software vulnerabilities involves identifying

security threats, assessing severity, and prioritizing fixes.
Vulnerability scanners automate these processes, presenting
critical data on vulnerabilities and associated patches.

Vulnerability Scanning

The chapter discusses various scanning tools available for

detecting vulnerabilities not just at runtime, but also in
containers' installed software. It highlights the importance of
established mechanisms to ensure accuracy during scanning,
emphasizing that vulnerabilities may exist due to direct
installations bypassing package managers.

Container Image Scanning

Scan to Download
To confirm if deployed containers contain vulnerable
software, comprehensive scanning of dependencies is
necessary. The efficiency of scanning the container image
rather than running instances is emphasized, along with the
principle of immutability.

Immutable Containers

The text explains the importance of treating containers as

immutable to avoid runtime vulnerabilities introduced
through code modifications during execution. Various
methods are recalled for ensuring this immutability, such as
utilizing read-only filesystems.

Regular Scanning Practices

Due to the continual discovery of vulnerabilities by security

researchers, it’s critical to establish routines for regular
rescanning. Continuous monitoring allows proactive
responses to newly identified vulnerabilities, suggesting
common practices such as daily rescans as part of CI/CD
processes.

Varied Scanning Tools

Scan to Download
Numerous tools exist to assist with container image
scanning, ranging from open source to commercial offerings.
Different results across these tools necessitate careful
consideration of their capabilities and information sources,
including security feeds.

Challenges in Vulnerability Reporting

Despite advancements in scanning technology, inaccuracies

remain prevalent, and understanding limitations is crucial.
The chapter acknowledges the potential for false positives
and negatives and the administrative challenges of
maintaining accurate profiling.

Zero-Day Vulnerabilities

Zero-day vulnerabilities, or undisclosed risks, pose unique

challenges as they are unknown until they are patched.
Defensive strategies against such exploits include runtime
behavior detection and real-time anomaly detection.

Conclusion

Scan to Download
This chapter emphasizes understanding software
vulnerabilities, implementing continuous scanning strategies,
and managing risks related to dependencies comprehensively
to ensure secure container deployments. The need for robust
vulnerability management practices integrated into CI/CD
pipelines is reinforced throughout the discussion.

Scan to Download
Critical Thinking
Key Point:The importance of continuous
vulnerability scanning and management
Critical Interpretation:In 'Container Security', Liz Rice
emphasizes the crucial need for continuous vulnerability
scanning to ensure secure container deployments.
Readers are encouraged to reflect critically on this
assertion, considering that while regular scanning can
greatly enhance security by identifying known
vulnerabilities, it may inadvertently lead to
overconfidence in the security posture if organizations
assume that continuously scanning alone can mitigate
all risks. Other studies suggest that reliance solely on
automation can overlook vulnerabilities due to
misconfigurations, organizational processes, or the
inherent limitations of scanning tools (e.g., dyke et al.,
2019). Hence, while Rice's viewpoint highlights an
essential practice, its effectiveness heavily relies on
complementary security measures and a comprehensive
understanding of the dynamic threat landscape.

Scan to Download
Chapter 8 Summary : 8. Strengthening
Container Isolation

Chapter 8: Strengthening Container Isolation

Introduction

Containers offer a degree of isolation between workloads on

the same host, but advanced tools and techniques can
enhance that isolation further. This chapter covers strategies
to prevent workloads from interfering with one another
through effective isolation techniques.

Sandboxing Concept

Sandboxing involves isolating applications to limit their

access to resources. This confines potential attackers,
restricting their ability to compromise a system. Containers
are ideal for sandboxing as they encapsulate application
code.

Scan to Download
Seccomp

Seccomp (secure computing mode) is a mechanism for

limiting the system calls an application can make. Initially
restrictive, modern seccomp-bpf allows configuration
through Berkeley Packet Filters, letting users create profiles
that block unwanted system calls. Docker implements a
default seccomp profile that mitigates risks effectively.
Kubernetes, however, requires explicit annotations to use
seccomp.

AppArmor

AppArmor is a Linux security module that enforces

mandatory access controls through profiles associated with
executables. Administrators can create granular permissions
within this framework, enhancing security while limiting
user access. It provides logs for policy violations that can be
refined over time.

SELinux

SELinux is another type of mandatory access control that

operates independently of user identity, allowing processes to

Scan to Download
interact only with files designated by labels. The creation of
effective SELinux profiles hinges on understanding a given
application's access needs. Policy violations are logged to
address issues prior to enforcement.

gVisor

gVisor is a sandboxes container framework that functions

like a user-space kernel, intercepting system calls to enhance
application security. It is heavily sandboxed, ensuring that
even filesystem-related calls are offloaded to separate
processes, adding a layer of isolation akin to a traditional
VM.

Kata Containers

Kata Containers run containers within virtual machines,

allowing separation at the virtual machine level while
maintaining compatibility with container image formats.
While this approach strengthens isolation, it introduces
delays due to VM boot times.

Firecracker

Scan to Download
Firecracker is a lightweight virtual machine designed for
rapid startup (around 100ms) that enhances secure isolation
without the overhead typical of traditional VMs. It is
optimized for running multiple microVMs efficiently on
shared resources.

Unikernels

Unikernels create compact images containing only the

required components of the OS for specific applications. This
minimizes the attack surface and allows for quick booting,
providing isolation similar to VMs.

Conclusion

This chapter emphasizes various methods to bolster container

isolation through mechanisms like seccomp, AppArmor,
SELinux, gVisor, Kata Containers, Firecracker, and
Unikernels. The choice of strategy depends on risk tolerance
and the nature of applications in use. Monitoring for potential
misconfigurations that could undermine security is crucial,
especially in multitenant environments.

Scan to Download
Chapter 9 Summary : 9. Breaking
Container Isolation

Chapter 9: Breaking Container Isolation

In this chapter, the author discusses how container isolation

can be compromised through various configurations.
Notably, containers run as root by default unless specified
otherwise, posing significant security risks. If an attacker
escapes a container running as root, they gain full access to
the host.

Containers Run as Root by Default

Containers default to running as the root user, which can lead

to privilege escalation. This section explains why running as
a non-root user is crucial for security and how to override
user IDs to run containers as non-root.

Root Requirement Inside Containers

Containers run many applications initially designed to

Scan to Download
operate on servers, which often require root access under
traditional configurations. However, this poses less of a
necessity in containerized settings, and users are encouraged
to adopt unprivileged user configurations.

Rootless Containers

The concept of rootless containers allows non-root users to

operate containers, mapping user IDs from the host to root
inside the container, thus enhancing security. However, not
all functionalities and image behaviors may transition
smoothly when using rootless execution.

The --privileged Flag and Capabilities

The `--privileged` flag in container runtimes is deemed

dangerous due to its expansive capabilities, potentially
leading to complete access if not managed properly. Users
are advised to use specific capabilities instead of using
`--privileged`, and ensure proper auditing and controls.

InstallSensitive
Mounting BookeyDirectories
App to Unlock Full Text and
Audio
Mounting host directories into containers, especially root

Scan to Download
Chapter 10 Summary : 10. Container
Network Security

Chapter 10: Container Network Security

In this chapter, we cover the essentials of container network

security, starting with container firewalling, moving through
the seven-layer networking model, and discussing how
network policy rules can be effectively implemented.

Container Firewalls

Container firewalling allows for granular control over

network traffic in a microservice architecture where
applications are divided into small, independently deployed
components. Firewalls can restrict traffic between specific
containers and external sources, enhancing security. In
Kubernetes, network policies serve as the equivalent to
traditional firewalls, controlling traffic between containers.

OSI Networking Model

Scan to Download
The OSI model consists of seven layers—application,
transport, and network, among others. It illustrates the
communication process between applications, utilizing
different protocols such as DNS for addressing and ARP for
MAC address resolution.

Sending an IP Packet

When an application sends a request, it performs a DNS

lookup, followed by routing decisions that involve mapping
destination IP addresses to MAC addresses using ARP. The
data encapsulation process occurs at various layers of the
OSI model, ultimately sending the packet to its destination.

IP Addresses for Containers

In Kubernetes, each pod gains its own IP address, enabling

direct communication between pods without the need for
NAT. This model simplifies networking compared to
traditional VLAN approaches, but it is essential to enforce
network policies for security.

Network Isolation

Scan to Download
Effective network isolation ensures components can only
communicate if they are on the same network. Kubernetes
allows all pods to access each other by default, but network
policies can restrict traffic as required.

Layer 3/4 Routing and Rules

Layer 3 routing involves making decisions based on IP

addresses, while Layer 4 adds port-level controls. Tools like
iptables and IPVS are utilized for handling network packets
through netfilter rules, with iptables historically being the
more common tool.

Network Policies

Network policies in Kubernetes define traffic rules between

pods based on service names, ports, or labels. Implementing
these policies often involves writing sophisticated rules with
tools like iptables, which can be complex and
performance-intensive at scale.

Network Policy Solutions

Automation through Kubernetes NetworkPolicy objects

Scan to Download
allows for the enforcement of these policies. Best practices
include using a default deny configuration for both ingress
and egress traffic, restricting pod communication, and
limiting access to specific ports.

Service Mesh

Service meshes like Istio and Linkerd enhance

communication security at the application layer (Layers 5-7).
They enable mutual TLS (mTLS) for encrypted connections
and provide a strategic separation of concerns for
application-layer network policies.

Best Practices

- Default deny policies enhance security by limiting ingress

and egress traffic to only expected flows.
- Service meshes should be enforced to secure
inter-component communication effectively.
- Certificates and keys play crucial roles in ensuring secure
connections.

Summary

Scan to Download
Ultimately, the chapter highlights how container-based
firewall solutions enhance security principles like least
privilege, limited blast radius, and layered defenses through
service meshes and traditional firewalling methods. The next
chapter will explore TLS and its importance in securing
communications.

Scan to Download
Example
Key Point:Implementing Network Policies in
Kubernetes
Example:Imagine deploying a new microservice in your
Kubernetes environment. You need to ensure that this
service only communicates with specific, trusted
components while preventing unauthorized access. By
implementing Network Policies, you can create rules
that restrict traffic based on pod labels, thus enforcing a
'default deny' stance. This means that by default, all
communications are blocked except those you explicitly
allow, significantly increasing security by only
permitting designated traffic through a fine-tuned
approach. By using this method, you become the
gatekeeper, ensuring that your applications
communicate securely and minimizing potential
vulnerabilities. This control not only enhances security
but also aligns with essential principles like least
privilege and reduced blast radius, ensuring that your
system is as resilient and robust as possible.

Scan to Download
Critical Thinking
Key Point:Granular Control via Container
Firewalling
Critical Interpretation:The chapter emphasizes the
critical role of granular control through container
firewalling to enhance security in microservice
architectures. Although the author argues that this
approach significantly improves security by allowing
precise traffic control, some experts argue that overly
complex firewall configurations may introduce
misconfigurations or bottlenecks that can undermine
security. For instance, in the article 'The Perils of
Over-Engineering Security' from SecurityWeek, it is
suggested that simplicity in security implementations is
often more effective than complicated rulesets. Thus,
while container firewalling is essential, its efficacy
depends on the balance between control and
manageability.

Scan to Download
 Chapter 11 Summary : 11. Securely
Connecting Components with TLS
Chapter Key Points

Chapter 11: Securely

Connecting Components with
TLS Importance of secure communication in distributed systems using TLS for
encrypted messages.
X.509 certificates are crucial for verifying identities and secure communication.
Certificate Authorities (CAs) certify identities; self-signed certificates may be
used in private systems.
Certificate Signing Requests (CSRs) are used to request X.509 certificates from
CAs.
Client-server communication through TLS involves certificate verification and
message encryption.
Mutual TLS (mTLS) enables mutual authentication, enhancing trust between
components.
Secure connections in Kubernetes can be configured with tools like kubeadm,
requiring access to certificates.
Certificate Revocation Lists (CRLs) are important for managing invalidated
certificates.
Implementing mTLS is advised for security against man-in-the-middle attacks.

Chapter 12: Passing Secrets to

Containers
Secure methods are needed for passing secret credentials to application code in
containers.
Secrets must remain confidential and accessible only to authorized users;
revocation and rotation are essential.
Various methods to transmit secrets: inclusion in container images (bad practice),
environment variables, network passing, and mounting files (preferred).
Kubernetes offers native support for managing secrets, including encryption and
flexible mounting options.
Root access to the host poses a risk to container secrets, necessitating prevention
of unauthorized access.
Robust secrets management is crucial for security, governance, and compliance
during development.

Chapter 11: Securely Connecting Components with

TLS

Scan to Download
In distributed systems, secure communication between
components, such as containers, is crucial. This chapter
explores Transport Layer Security (TLS) and its role in
ensuring secure connections for sending encrypted messages.
A foundational understanding of keys, certificates, and
certificate authorities (CAs) is necessary for those involved
in administering cloud-native systems.

Secure Connections

Secure connections, like HTTP-Secure (HTTPS), ensure that

users know they are communicating with the correct entity
and that their messages are encrypted to prevent interception.
The security at the transport layer is managed using TLS,
which relies on X.509 certificates. While the old term Secure
Sockets Layer (SSL) is still in use, the industry
predominantly employs TLS.

X.509 Certificates

X.509 certificates provide essential information about the

identity of the certificate owner and the corresponding public
key. The key elements of a certificate include the subject
name, public key, the CA's name, and its validity period.

Scan to Download
Public/private key pairs facilitate secure communication by
encrypting messages and enabling the signing of messages
for identity verification.

Certificate Authorities

A CA is a trusted entity that verifies identities by signing

certificates. The trust hierarchy often leads back to a
self-signed certificate. Browsers typically trust certificates
from well-known root CAs. In private systems, self-signed
certificates can be used without public trust.

Certificate Signing Requests (CSRs)

CSRs contain the public key, domain name, and identity

details. They are submitted to a CA to request an X.509
certificate. Tools like OpenSSL can generate CSR along with
key pairs.

TLS Connections

TLS connections require a client to initiate requests to a

server. The client verifies the server by checking its
certificate, and if trusted, can encrypt messages that will be

Scan to Download
secured on a symmetric key for future communications.
“Skip verify” options can bypass certificate validation, but
should not be used in production environments.

Mutual TLS (mTLS)

In some configurations, both the client and server provide

certificates, enabling mutual authentication (mTLS). This
allows both parties to trust each other's identities.

Secure Connections Between Containers

For Kubernetes and distributed systems, secure connections

between components can be configured during installations
with tools like kubeadm. Developers must ensure that
application code can access required certificates for
establishing secure communications.

Certificate Revocation

Certificate revocation lists (CRLs) maintain records of

invalidated certificates to prevent unauthorized access. It is
important to ensure individual secrets rather than shared ones
are used to enhance security.

Scan to Download
Summary

To establish robust security against man-in-the-middle

attacks, implementing mTLS between application
components is advised. Understanding keys, certificates, and
CAs is key for configuration and ensuring secure
environments, especially as components start to share
sensitive data.
---

Chapter 12: Passing Secrets to Containers

Application code often needs access to credentials (secrets)

to function correctly, requiring secure methods for passing
these secrets into containers. This chapter discusses desirable
properties of secrets and the various mechanisms for
transmitting them, especially focusing on Kubernetes' native
support.

Secret Properties

Secrets must remain confidential and only be accessible to

authorized users or components. Best practices involve

Scan to Download
encrypting secrets during storage and transmission and
limiting access. The ability to revoke and rotate secrets is
essential for maintaining security, especially if credentials
are compromised.

Getting Information into a Container

There are several mechanisms to transmit secret data to a

running container:
1.
Inclusion in the Container Image
: Generally bad practice as it exposes secrets to unauthorized
access.
2.
Environment Variables
: Suitable for configuration but can lead to vulnerabilities due
to potential logging or exposure.
3.
Passing Over the Network
: Least commonly seen in practice, and necessitates proper
security measures, such as encryption.
4.
Mounting Files from the Host
: Preferred method that allows flexibility in updating secrets

Scan to Download
without container restarts.

Kubernetes Secrets

Kubernetes provides a native way to manage secrets,

including encryption at rest and in transit. It allows for
flexible mounting of secrets into containers and encrypted
storage. Third-party solutions can enhance secret
management.

Secrets Accessible by Root

Regardless of the method of secret transmission, if a root

user has access to the host, they can access container secrets.
This underlines the importance of preventing unauthorized
root access.

Summary

A comprehensive understanding of secrets is essential for

maintaining security in containerized environments.
Organizations should implement best practices for handling
credentials, including integrated solutions for robust secrets
management, keeping in mind governance, compliance, and
security needs throughout the development lifecycle.

Scan to Download
Chapter 12 Summary : 12. Passing
Secrets to Containers

Chapter 12: Passing Secrets to Containers

Introduction

Application code often requires credentials, known as

secrets, to access resources like databases or APIs. Protecting
these secrets is crucial to ensure they are only accessible by
necessary entities, following the principle of least privilege.

Secret Properties

-
Confidentiality:
Secrets must remain confidential, which is typically ensured
by encryption.
-
Storage Security:
Secrets should be stored in encrypted form and transferred in

Scan to Download
encrypted channels to avoid interception.
-
Revocation and Rotation:
Secrets should have the capability to be revoked or rotated to
mitigate risks of exposure.
-
Limited Access:
Access to secrets should only be granted to components that
genuinely require it, minimizing the risk of unauthorized
access.

Getting Information into a Container

There are multiple methods to inject secrets into containers:

1.
Container Image Inclusion:
Hardcoding secrets in images is discouraged as it's insecure.
2.
Network Transfer:
Secrets can be retrieved over a network, necessitating secure
channels.
3. Install Bookey App to Unlock Full Text and
Environment Variables: Audio
This method is generally considered insecure due to logging

Scan to Download
Chapter 13 Summary : 13. Container
Runtime Protection

Chapter 13: Container Runtime Protection

In this chapter, the discussion focuses on container runtime

protection as it relates to microservice architectures.
Containers allow for breaking down complex applications
into manageable services, which enhances security through
the creation of runtime profiles.

Container Image Profiles

- Each container image encapsulates a microservice's code,

enabling the definition of a runtime profile that governs
expected behaviors of instantiated containers.
- In Kubernetes, runtime security can be applied on a pod
basis, impacting all containers sharing the network
namespace.

Network Traffic Profiles

Scan to Download
- The expected network behavior of a microservice can be
defined based on the services it interacts with, such as a
database or a load balancer, allowing for precise traffic
management.
- Security tools can record normal traffic patterns to create
firewall rules or network policies.

Executable Profiles

- Monitoring should ensure only the expected executables

run in a container. For instance, in a Go-based microservice,
only the primary Go executable should run.
- Tools like eBPF can be used to observe and identify
running executables within containers.

File Access Profiles

- Similar to monitoring executables, file access can be

tracked using system calls to confirm that a microservice
accesses only the expected files.
- Tools like Tracee help establish file access profiles for
different container types.

User ID Profiles

Scan to Download
- Each container should ideally operate under a single user
identity that aligns with its task, avoiding unnecessary
privilege escalations.

Other Runtime Profiles

- Further profiling can be done on system calls and

capabilities, generating tailored security profiles (seccomp or
AppArmor) specific to the container’s functions.

Container Security Tools

- Tools like AppArmor, SELinux, and seccomp can be used

to establish security profiles for containers.
- Open source options like Falco leverage eBPF to monitor
behavior and alert users to anomalies.

Prevention or Alerting

- It’s crucial to have a strategy for responding to detected

anomalies, balancing prevention techniques with alerting to
identify and confirm security issues.

Scan to Download
Drift Prevention

- Containers should be treated as immutable, with all

necessary code and dependencies included in the image. Drift
prevention checks at runtime ensure integrity by validating
executables against pre-scanned fingerprints.

Summary

- The ability to enforce granular runtime protection is

essential for organizations like banks or healthcare providers,
emphasizing the integration of various security tools to create
a robust container security posture.
---

Chapter 14: Containers and the OWASP Top 10

The OWASP Top 10 outlines critical web application security

risks, applicable to both traditional and containerized
applications.

Injection

- Code injection flaws allow attackers to execute harmful

Scan to Download
commands disguised as data. Addressing this through regular
code reviews and dependency scanning is essential.

Broken Authentication

- Containers should treat credentials as secrets, with secure

storage and handling. Communication between microservices
should utilize secure connections.

Sensitive Data Exposure

- Protect sensitive information using strong encryption both

at rest and in transit. Limit access to data strictly to
containers that need it.

XML External Entities

- Follow general practices for analyzing code vulnerabilities

and use image scanning to detect flaws in dependencies.

Broken Access Control

- Ensure the least privilege principle by limiting user roles

and capabilities to counter unauthorized access during

Scan to Download
microservice interactions.

Security Misconfiguration

- Adopt best practices such as CIS Benchmarks for ensuring

proper configurations, while validating setup and security
policies continuously.

Cross-Site Scripting (XSS)

- Implement code reviews and vulnerability scanning

specifically for exposed dependencies related to XSS risks.

Insecure Deserialization

- Isolate deserialization processes within low-privileged

environments to prevent exploitation.

Using Components with Known Vulnerabilities

- Regularly scan and update dependencies to mitigate risks

associated with known vulnerabilities.

Insufficient Logging and Monitoring

Scan to Download
- Enhance monitoring capabilities to detect breaches early
and integrate logging of critical events to assess ongoing
security postures effectively.

Summary

- Active monitoring, timely updates, and security best

practices like scanning for vulnerabilities are vital. The
insights from OWASP Top 10 are invaluable for reinforcing
containerized applications' security, emphasizing that
proactive measures yield significant security benefits.

Scan to Download
Chapter 14 Summary : 14. Containers
and the OWASP Top 10

Chapter 14: Containers and the OWASP Top 10

Introduction to OWASP

The OWASP (Open Web Application Security Project)

provides a vital resource in the security landscape, sharing a
list of the top 10 web application security risks. This chapter
explores how these risks apply specifically to containerized
applications, offering insights into security practices within
this framework.

1. Injection

Injection flaws allow attackers to execute commands by

injecting malicious data. While universal to all applications,
container image scans can help identify injection
vulnerabilities in dependencies. Regular review and testing
of application code against OWASP guidelines are essential.

Scan to Download
2. Broken Authentication

This risk involves compromised credentials. For containers,

treat credentials as secrets, store them safely, and pass them
into containers at runtime. Use secure methods such as
certificates for communication among containerized
components.

3. Sensitive Data Exposure

Protect sensitive data (personal, financial, etc.) by employing

strong encryption at rest and in transit. Minimize access to
sensitive data through proper access controls and conduct
scans for embedded sensitive information in container
images.

4. XML External Entities (XXE)

XXE vulnerabilities affect XML processors and are not

specific to containers. Use OWASP advice for code analysis
and container image scanners to check for vulnerability in
dependencies.

Scan to Download
5. Broken Access Control

Abuse of user privileges demands a careful approach to

privilege management. Implement least privilege by not
running containers as root, limiting container capabilities,
and applying security profiles like seccomp, AppArmor, or
SELinux.

6. Security Misconfiguration

Poor configurations can lead to serious vulnerabilities. Use

CIS Benchmarks to evaluate configurations against best
practices and tools like CloudSploit to manage settings and
detect insecure configurations in cloud services.

7. Cross-Site Scripting (XSS)

While primarily an application layer concern, XSS risks in

containers require image scanning to identify vulnerable
dependencies.

8. Insecure Deserialization

Maliciously crafted objects can exploit deserialization

Scan to Download
processes, leading to unauthorized privileges or altered
behaviors. Use OWASP recommendations for isolating
deserialization code and running it in low-privileged
environments.

9. Using Components with Known Vulnerabilities

Identify known vulnerabilities in container images through

regular scans, and ensure up-to-date packages are used for
container images to prevent exploitation.

10. Insufficient Logging and Monitoring

Recognizing that breaches can remain undetected for

extended periods, logging essential events in production
deployments can facilitate timely response to unexpected
behaviors. Implement logging of actions like container
start/stop events, access to secrets, and privilege
modifications.

Summary

The OWASP Top 10 serves as an important resource for

enhancing the security of internet-connected applications,

Scan to Download
including containerized environments. Key takeaways
emphasize the importance of scanning container images for
vulnerabilities while concurrently addressing specific coding
and configuration practices to fortify security postures
against potential threats.

Conclusions

This chapter reinforces the reader's understanding of

container security in relation to OWASP's guidelines,
highlighting the layered defenses necessary to withstand
breaches and the continuous review process for improving
security measures. Practical feedback and stories from
real-world experiences enhance the learning process and
inform ongoing security practices.

Scan to Download
Critical Thinking
Key Point:Vulnerability Management in
Containerized Applications
Critical Interpretation:The chapter argues that container
security aligns closely with the OWASP Top 10 risks,
which is a significant perspective. However, one might
challenge the absolute applicability of these guidelines
to all container scenarios since unique vulnerabilities
may arise due to orchestration and cloud integration.
Critics could point to emergent literature on dynamic
container environments, such as Greg Skorka's 'Securing
Kubernetes' and various case studies that illustrate how
the operational context can complicate these established
risks. This highlights the necessity of adapting security
strategies to specific contexts rather than solely
depending on broadly applicable frameworks.

Scan to Download
Chapter 15 Summary : Conclusions

Conclusions

Congratulations on completing the book! The key goal is for

you to have a robust understanding of containers and how to
secure your deployments effectively. You should be informed
about various isolation options for workloads and have an
insight into container communication and networking.
The main takeaway is that containers provide a unit of not
just deployment but security, allowing for traffic restrictions
to safeguard interactions within and outside the container
environment. Implementing layered defenses increases the
chances of thwarting attacks, as multiple barriers complicate
an attacker’s potential breach.
As presented in Chapter 14, you have learned about
preventative measures specific to container deployments
against typical vulnerabilities. Revisiting the “Container
Threat Model” and utilizing the list of questions in the
Appendix will help you identify and strengthen your
deployment’s most vulnerable points. Your feedback and
experiences are valuable; feel free to share them through the
provided contact avenues.

Scan to Download
Appendix: Security Checklist

This checklist outlines critical security considerations for

container deployments. While it may not be exhaustive,
contemplating each item will put you on the right path:
1. Run containers as a non-root user.
2. Avoid using the --privileged flag.
3. Drop unnecessary capabilities for each image.
4. Use read-only containers when possible.
5. Check for sensitive directories mounted from the host,
including the Docker socket.
6. Ensure your CI/CD pipeline operates securely and doesn’t
have privileged access.
7. Scan container images for vulnerabilities and have a
process for remediation.
8. Utilize seccomp or AppArmor profiles tailored to your
applications.
9. Enable SELinux if supported by your OS and attach
appropriate profiles.
10. Opt for minimal base images to reduce attack surfaces.
11.Install
Enforce Bookey
the use of App to Unlock
immutable Full Text and
containers.
Audio
12. Set resource limits on your containers.
13. Implement admission control to verify approved images

Scan to Download
Chapter 16 Summary : Security
Checklist

Appendix: Security Checklist

This appendix outlines essential security considerations for

container deployments. While not every item may apply to
your specific environment, reflecting on these issues will
provide a solid foundation for securing your containers.

Key Security Considerations

1.
Non-root User

- Are all containers run as a non-root user?

2.
Privileged Flag

- Are any containers operating with the --privileged flag?

3.

Scan to Download
Capabilities Management

- Have you dropped unnecessary capabilities for each

image?
4.
Read-only Containers

- Are containers run as read-only whenever feasible?

5.
Sensitive Directories

- Are you monitoring for sensitive directories mounted

from the host, including the Docker socket?
6.
CI/CD Pipeline

- Is your CI/CD pipeline operating within the production

cluster? Does it have privileged access or utilize the Docker
socket?
7.
Vulnerability Scanning

- Are container images regularly scanned for

vulnerabilities? Is there tooling in place for rebuilding and

Scan to Download
redeploying affected containers?
8.
Runtime Profiles

- Are you utilizing seccomp or AppArmor profiles? Default

profiles are a good starting point, but consider customizing
them for each application.
9.
SELinux Configuration

- If your host OS supports SELinux, is it enabled? Are

appropriate SELinux profiles attached to your applications?
10.
Base Image Selection

- What base images are being used? Can you opt for
smaller, more secure images like scratch, distroless, Alpine,
or RHEL minimal?
11.
Immutable Containers

- Are you enforcing the use of immutable containers,

ensuring all executable code is added during build time?
12.

Scan to Download
Resource Limits

- Have resource limits been set on containers?

13.
Admission Control

- Is there an admission control system to ensure only

approved images can be run in production?
14.
mTLS Connections

- Are mTLS connections established between application

components? This can be implemented via service mesh.
15.
Network Policies

- Are network policies in place to restrict traffic between

components?
16.
Secrets Management

- Are secrets passed into containers using a temporary

filesystem? Are they encrypted at rest and in transit? Is there
a secrets management system for storage and rotation?

Scan to Download
17.
Runtime Protection Tools

- Are you employing runtime protection tools to validate

that only expected executables are running inside containers?
18.
Drift Prevention

- Do you have a runtime security solution for drift

prevention?
19.
Dedicated Host Machines

- Are hosts exclusively used for running containers,

separated from other applications?
20.
Host Security Updates

- Are host systems kept updated with the latest security

patches?
21.
CSPM Tools

- Are you running regular checks on the security settings

Scan to Download
of your cloud infrastructure using a Cloud Security Posture
Management (CSPM) tool?
22.
Best Practices Compliance

- Do your hosts and containers adhere to security best

practices, such as the CIS Benchmarks for Linux, Docker,
and Kubernetes?
Reflecting on and implementing this checklist will strengthen
your container security posture significantly.

Scan to Download
Best Quotes from Container Security by
Liz Rice with Page Numbers
View on Bookey Website and Generate Beautiful Quote Images

Chapter 1 | Quotes From Pages 155-422

1.Containers bring many advantages: as described
in Docker’s original tagline, they allow you to
'build once, run anywhere.'
2.A risk is a potential problem, and the effects of that
problem if it were to occur. A threat is a path to that risk
occurring. A mitigation is a countermeasure against a
threat—something you can do to prevent the threat or at
least reduce the likelihood of its success.
3.The principle of least privilege states that you should limit
access to the bare minimum that a person or component
needs in order to do their job.
4.The principle of defense in depth tells us that you should
apply layers of protection.
5.The concept of segmenting security controls into smaller
subcomponents or 'cells' means that should the worst

Scan to Download
 happen, the impact is limited.
6.Segregation of duties so that, as much as possible, different
components or people are given authority over only the
smallest subset of the overall system that they need.
7.Adding and strengthening the security boundaries in your
deployment will make life more difficult for the attacker.
8.You’ll see how these [Linux security features] can be
applied to containers in Chapter 8.
Chapter 2 | Quotes From Pages 423-601
1.In most cases, containers run within a computer
running a Linux operating system, and it’s going
to be helpful to understand some of the
fundamental features of Linux so that you can see
how they affect security, and in particular how
they apply to containers.
2.Permissions on files determine which users are allowed to
access those files and what actions they can perform on the
files.
3.There is a saying that in Linux, everything is a file.

Scan to Download
4.Not all applications need all system calls, so—following
the principle of least privilege—there are Linux security
features that allow users to limit the set of system calls that
different programs can access.
5.The setuid bit provided a mechanism for granting extra
privileges to non-root users.
6.Privilege escalation means extending beyond the privileges
you were supposed to have so that you can take actions that
you shouldn’t be permitted to take.
7.By setting limits on the memory and other resources that
one process can access, you can reduce the effects of this
kind of attack and ensure that other processes can carry on
as normal.
Chapter 3 | Quotes From Pages 602-784
1.Cgroups limit the resources available to different
Linux processes.
2.Constraining resources provides protection against a class
of attacks that attempt to disrupt your deployment by
consuming excessive resources, thereby starving legitimate

Scan to Download
 applications.
3.When you start a Linux system, it has a single namespace
of each type, but as you’ll see, you can create additional
namespaces and assign processes into them.
4.User namespaces allow an unprivileged user to effectively
become root within the containerized process.
5.The main benefit of this is that you can map the root ID of
0 within a container to some other non-root identity on the
host.
6.The fact that container processes are visible from the host
is one of the fundamental differences between containers
and virtual machines.
7.Changing the root limits the set of files and directories that
the container can see.

Scan to Download
Chapter 4 | Quotes From Pages 785-1253
1.Although the general concepts of these constructs
are fairly straightforward, the way they work
together with other features of the Linux kernel
can be complex.
2.With an understanding of these constructs under your belt,
you’ll have a feeling for how well protected your
applications are when they run inside containers.
3.You can change the root directory in Linux with the chroot
command.
4.User namespaces allow an unprivileged user to effectively
become root within the containerized process.
5.If a host gets compromised, all the containers on that host
are potential victims.
6.The Center for Internet Security (CIS) publishes
benchmarks for best practices for configuring and running
various software components, including Docker,
Kubernetes, and Linux.
Chapter 5 | Quotes From Pages 1254-1476

Scan to Download
1.Making sure that applications are safely isolated
from each other is a primary security concern.
2.Physical isolation is the strongest form of isolation
possible.
3.The kernel is responsible for managing its user space
processes, including assigning memory to each process.
4.Hypervisors have a much, much simpler job.
5.Avoid including sensitive information such as passwords or
tokens in an image.
6.Refer to an image from a trusted registry.
7.Image signing associates an identity with an image.
Chapter 6 | Quotes From Pages 1477-2061
1.If you allow for the possibility of a container
installing additional packages at runtime, how will
you check that those packages are legitimate?
2.The smaller the base image, the less likely that it includes
unnecessary code, and hence the smaller the attack surface.
3.Don’t include anything in any layer that you aren’t
prepared to be seen by anyone who has access to the image.

Scan to Download
4.Imagine that you want to dedicate a machine (or virtual
machine) to build container images and store them in a
registry.
5.The first line of the Dockerfile is a FROM instruction
indicating a base image that the new image is built from.
6.If an attacker can breach the build machine and run code on
it, can they reach other parts of your system?
7.Users no longer need direct access to the running system
because everything is done at arm’s length via the source
code control system.
8.Image signing associates an identity with an image.
9.Following these recommendations will help you build
images that are harder to exploit.

Scan to Download
Chapter 7 | Quotes From Pages 2062-2462
1.A vulnerability is a known flaw in a piece of
software that an attacker can take advantage of to
perform some kind of malicious activity.
2.Once a vulnerability is identified, the race is on to get a fix
published so that users can deploy that fix before attackers
take advantage of the issue.
3.If you don’t have a scanner in place and use it regularly,
you really have no way of knowing whether your software
is prey to an easy exploit.
4.By treating your containers as immutable, you only need to
scan each image to find all the vulnerabilities that might be
present in all the containers.
5.The best hope for defending against zero-day exploits is to
detect and prevent anomalous behavior at runtime.
Chapter 8 | Quotes From Pages 2463-2656
1.If an attacker can escape a container that is
running as root, they have full root access to the
host, which means free access to everything on the

Scan to Download
 machine.
2.It’s worth noting, however, that although these protection
mechanisms limit what the user space application can do,
there is still a shared kernel. A vulnerability within the
kernel itself... would not be prevented by any of these tools.
3.The recommended approach is to drop all capabilities and
then add back the necessary ones as follows: $ docker run
--cap-drop=all --cap-add=<cap1> --cap-add=<cap2>
<image> ...
4.Rootless containers make use of the user namespace feature
that you saw in 'User Namespace'. A normal non-root user
ID on the host can be mapped to root inside the container.
5.For your own application code, use a non-root user
whenever you can, or run with user namespaces... so that
root inside the container is not the same as root on the host.
Chapter 9 | Quotes From Pages 2657-2931
1.Containers Run as Root by Default
2.A sidecar container is deliberately given access to one or
more of an application container’s namespaces so that it

Scan to Download
 can offload functionality from that application.
3.The --privileged flag is incredibly powerful, and it’s widely
misunderstood.
4.Default deny Following the principle of least privilege, set
up a policy for each namespace that denies ingress traffic
by default and then add policies to permit traffic only
where you expect it.
5.Mutual TLS... gives the benefit of secure, encrypted
connections within the deployment, making it much harder
for an attacker to intercept traffic.
6.Recognizing that running as root is a problem, many
vendors now provide Docker images that run as normal,
unprivileged users.
7.Set policies for each namespace to deny egress traffic by
default and then add policies for expected egress traffic.
8.If you’re running in any kind of multitenant environment,
you should be even more attentive to containers with these
potentially dangerous configurations.
9.With user ID overrides and rootless containers, there are

Scan to Download
 options for avoiding running containers as the root user.
10.A service mesh can provide security support only to pods
into which it has been injected as a sidecar.

Scan to Download
Chapter 10 | Quotes From Pages 2932-3249
1.Every external attack reaches your deployment
across a network, so it’s important to understand
something about networking in order to consider
how to secure your applications and data.
2.A container firewall can restrict the traffic that flows to and
from a set of containers.
3.Combining them with container-aware security gives
additional defense in depth.
4.It’s worth explicitly pointing out that two components can
communicate with each other only if they are connected to
the same network.
5.A service mesh provides an additional set of controls and
capabilities for how applications connect with each other
that are implemented at the application layer.
6.The best practice for enterprises is to use the principle of
defense in depth.
7.Segregation of duties/least privilege by allowing containers
only a limited ability to communicate.

Scan to Download
8.Service meshes also typically provide options to enforce
application-layer network policies.
Chapter 11 | Quotes From Pages 3250-3423
1.If you can trust the connections between
containers and identify the component at the far
end of a connection, you are in a good place to
start passing secrets between containers.
2.Secure connections based on mTLS are a tried-and-tested
way to ensure [trust].
3.Try not to share identities (and their certificates) across
multiple components or users.
4.You should only trust a certificate that has been signed by
an authority you trust.
5.The life cycle of a secret should ideally be independent of
the life cycle of the component that uses it.
6.If you’re using Kubernetes, the good news is that it has
native secrets support that meets many of the criteria I
described at the start of this chapter.
7.Even if it’s in a temporary directory, the root user will be

Scan to Download
 able to access it.
Chapter 12 | Quotes From Pages 3424-3585
1.Every container instantiated from a given image
should behave the same way, so it makes sense that
a profile of expected behavior can be defined for
an image and then used to police the traffic to and
from all the containers based on that image.
2.If you were to monitor the executables running inside these
product search containers, you should only ever see
productsearch. Anything else would be an anomaly and
possibly a sign of attack.
3.Treating containers as immutable gives us another
incredibly powerful option for detecting code injection at
runtime: drift prevention.
4.If your security tools can actually prevent bad behavior
within a container before it happens, there is a possibility
that the container can carry on as before.
5.There is no single correct answer when it comes to figuring
out how to handle a security alert automatically.

Scan to Download
Chapter 13 | Quotes From Pages 3586-3780
1.Breaking a large system into smaller components
with well-defined interfaces makes it easier to
design, code, and test the individual components.
2.Every container instantiated from a given image should
behave the same way, so it makes sense that a profile of
expected behavior can be defined for an image and then
used to police the traffic to and from all the containers
based on that image.
3.Prevention is much better than cure in this regard.
4.Treating containers as immutable gives us another
incredibly powerful option for detecting code injection at
runtime: drift prevention.
5.Even better than observing attacks and reporting on them
after the event, these tools can provide the protection of not
just reporting on unexpected behaviors but preventing them
from happening based on runtime profiles.
Chapter 14 | Quotes From Pages 3781-3880
1.The OWASP Top 10 is a useful resource for

Scan to Download
 making any internet-connected application more
secure against the most common types of attack.
2.You should review and test your own application code,
following the OWASP advice.
3.The credentials required by each container should be
treated as secrets.
4.Following the principles of least privilege and segregation
of duties, limit credentials to only those containers that
really need access.
5.An attacker can get it to execute commands masquerading
as data.
6.Many attacks take advantage of systems that are poorly
configured.
7.Even better than observing attacks and reporting on them
after the event, these tools can provide protection not just
reporting on unexpected behaviors but preventing them
from happening based on runtime profiles.
8.Container start/stop events, including the identity of the
image and the invoking user Access to secrets.

Scan to Download
9.You may have spotted that the container-specific
recommendation that comes up most often in this chapter is
to scan container images for known vulnerabilities in
third-party dependencies.
10.There are lots of options for restricting traffic so that only
what is expected can flow between containers and to/from
the outside world.
Chapter 15 | Quotes From Pages 3881-3891
1.My first hope for you at this point is that you now
have a solid mental model of what containers are.
2.Networking is a vast topic in its own right, but the most
important takeaway here is that containers give you a unit
not just of deployment but also of security.
3.The more layers of defense, the less likely an attack is to
succeed.
4.I hope that the information in this book helps you to defend
your deployment, come what may.
5.If you are subject to an attack—whether you are breached
or you succeed in keeping your application and data

Scan to Download
safe—I would love to hear about it.

Scan to Download
Chapter 16 | Quotes From Pages 3892-3999
1.Are you using a seccomp or AppArmor profile?
The default Docker profiles are a good starting
point; even better would be to shrink-wrap a
profile for each application.
2.Are you enforcing the use of immutable containers? That is
to say, are you making sure that all executable code is
added to a container image at build time and not installed at
runtime?
3.Are your secrets encrypted at rest and in transit? Are you
using a secrets management system for storage and
rotation?
4.Are you running regular checks on the security settings on
the underlying cloud infrastructure using a CSPM tool?
5.Do you have admission control to make sure that only
approved images can be instantiated in production?

Scan to Download
Container Security Questions
View on Bookey Website

Chapter 1 | 1. Container Security Threats| Q&A

1.Question
What has contributed significantly to the popularity of
containers in the developer community?
Answer:The easy-to-use command-line tools
provided by Docker, launched in 2013, greatly
contributed to the popularity of containers among
developers.

2.Question
How do containers manage dependencies for
applications?
Answer:Containers isolate applications and their
dependencies, allowing multiple applications to run on the
same server without interference, thus avoiding dependency
conflicts.

3.Question
What is a risk management framework in the context of
container security?

Scan to Download
Answer:A risk management framework is a systematic
process that helps identify possible threats to a containerized
system, prioritizes their significance, and establishes a
mitigation strategy.

4.Question
What are the definitions of risk, threat, and mitigation?
Answer:A risk is a potential problem and its consequences; a
threat is a means by which a risk could occur; and a
mitigation is a countermeasure to reduce the likelihood or
impact of that threat.

5.Question
Why is the concept of multitenancy significant in
container security?
Answer:Multitenancy refers to different users running
workloads on shared hardware. It necessitates stronger
security boundaries to prevent interference and protect
against unauthorized access.

6.Question
What is the principle of least privilege in security?
Answer:The principle of least privilege advises limiting

Scan to Download
access to only what is necessary for a person or component to
perform its job, thus minimizing the risk of unauthorized
actions.

7.Question
What does defense in depth mean when applied to
security?
Answer:Defense in depth involves implementing multiple
layers of security so that if one defense is breached, other
measures can protect the system from further harm.

8.Question
How can containers reduce the attack surface in a
system?
Answer:By splitting applications into microservices and
using containers, the interfaces between them can be
simplified, which helps to minimize complexity and potential
vulnerabilities.

9.Question
What are the implications of using setuid binaries in
container security?
Answer:Setuid binaries allow users to execute processes with

Scan to Download
the privileges of the binary's owner, which can present
security risks if exploited by attackers to escalate privileges.

10.Question
What are Linux capabilities, and why are they important
in container security?
Answer:Linux capabilities provide a more granular access
control mechanism that allows processes to use certain
privileges without granting full root access, helping to
minimize risks.
Chapter 2 | 2. Linux System Calls, Permissions, and
Capabilities| Q&A
1.Question
What are system calls and why are they important for
containers?
Answer:System calls are the means by which
applications request services from the operating
system's kernel, allowing them to perform actions
like file access or network communication. In the
context of containers, understanding system calls is
crucial because containerized processes interact with

Scan to Download
the same kernel as the host system. This shared
interaction influences the security model, especially
concerning which system calls each container can
access. Limiting system calls is a key aspect of
applying the principle of least privilege, enhancing
overall container security.

2.Question
How does Linux manage file permissions, and what is the
significance of the setuid bit?
Answer:Linux uses a permission model that dictates which
users can read, write, or execute files based on the identity of
the user and the file's ownership. The setuid bit allows a file
to execute with the privileges of its owner rather than the
user executing it. This is crucial for utilities like 'ping', which
require elevated privileges for operation, yet it introduces
security risks, as malicious users could exploit setuid to gain
unauthorized access or control.

3.Question
What is privilege escalation and how does it relate to
container security?

Scan to Download
Answer:Privilege escalation occurs when a user gains
elevated access to resources that they are normally restricted
from using. In containers, this is concerning because
applications typically run as root, increasing risk if an
attacker gains control of a container. If a containerized attack
can escape the container environment, it can achieve root
access on the host, making privilege escalation a significant
security threat.

4.Question
Describe how cgroups (control groups) enhance security
in containers.
Answer:Cgroups allow the limiting of resources (e.g., CPU,
memory) available to processes, preventing a single process
from monopolizing system resources. By controlling
resource allocation, cgroups help ensure that applications can
operate smoothly without interference, thus enhancing
stability and security. For example, they can prevent a fork
bomb from crippling the system by limiting the number of
processes a cgroup can spawn.

Scan to Download
5.Question
Why is it important to apply the principle of least
privilege when configuring container systems?
Answer:Applying the principle of least privilege minimizes
the risk of accidental or malicious actions by limiting the
capabilities and permissions a user or process has. In
containers, restricting access to only necessary system calls
and resources reduces the attack surface and helps prevent an
attacker from exploiting potential vulnerabilities to gain
higher privileges or access sensitive data.

6.Question
What role do Linux capabilities play in container
security?
Answer:Linux capabilities provide a more granular level of
privilege management than traditional root privileges,
allowing specific capabilities to be assigned to processes.
This means that even if a process runs as a non-root user, it
can be granted just enough privileges to perform specific
tasks (like binding to a low-numbered port) without giving it

Scan to Download
full root access, thereby reducing the risk of privilege
escalation and improving security within containerized
environments.
Chapter 3 | 3. Control Groups| Q&A
1.Question
What are control groups (cgroups) and how do they
contribute to container security?
Answer:Control groups (cgroups) are a Linux
kernel feature used to limit and manage the
resources that a group of processes can use,
including CPU, memory, and network I/O. By
properly tuning cgroups, one process cannot starve
others of resources, maintaining application
performance and security. This prevents attacks,
such as denial-of-service, that exploit resource
exhaustion.

2.Question
What is a fork bomb and how do cgroups help mitigate its
impact?

Scan to Download
Answer:A fork bomb is a type of denial-of-service attack that
creates a large number of processes rapidly, overwhelming
the system. Cgroups can limit the number of processes
allowed in a control group, effectively preventing the fork
bomb from exhausting system resources.

3.Question
How do cgroups and namespaces differ in functionality
within containers?
Answer:Cgroups control the resources available to processes,
while namespaces control the visibility of resources to
processes. Cgroups limit resource usage (like CPU and
memory), whereas namespaces isolate resources (like process
IDs and network interfaces) so that processes in different
namespaces cannot see each other.

4.Question
What does the command '/sys/fs/cgroup/' contain and
why is it important?
Answer:/sys/fs/cgroup/ contains various cgroup hierarchies
that correspond to different resource types managed through

Scan to Download
cgroups. This directory is essential for managing and
monitoring resource limits for processes and containers,
allowing for efficient resource allocation and ensuring that
applications do not interfere with one another.

5.Question
What is the process for creating and assigning a cgroup to
a process?
Answer:To create a cgroup, a new subdirectory is made
under a specific resource type (e.g., memory) within
/sys/fs/cgroup/. You then write configuration parameters (like
memory limits) into files in this new directory. To assign a
process to the cgroup, write its process ID into the
'cgroup.procs' file within that cgroup's directory.

6.Question
How can Docker automatically create and manage
cgroups for containers?
Answer:When a Docker container is started, Docker
automatically sets up cgroups for that container to manage its
resources, ensuring that the limits configured during the

Scan to Download
container's creation are applied appropriately. This is done
using the Docker daemon, which interacts with the cgroup
filesystem to create the necessary control groups.

7.Question
What is cgroups v2 and how does it differ from cgroups
v1?
Answer:Cgroups v2, introduced in newer Linux kernels,
simplifies management by allowing a process to join a single
cgroup per resource type, unlike v1, where it could join
multiple groups for different resource types. V2 also has
better support for rootless containers and improves overall
resource management.

8.Question
Why is it important to set memory and CPU limits for
containerized applications?
Answer:Setting memory and CPU limits is critical for
maintaining overall system performance and security. It
ensures that no single container can overwhelm the host
system, protecting other applications and maintaining

Scan to Download
stability.

9.Question
What are the security implications of using cgroups and
namespaces for container isolation?
Answer:While cgroups and namespaces provide a level of
isolation between containers, they do not prevent all potential
attacks. Containers share the same kernel, making them
vulnerable to kernel-level attacks. Proper configuration and
monitoring are essential to mitigate these risks.

10.Question
How do user namespaces enhance container security?
Answer:User namespaces allow processes inside a container
to have different user and group IDs than those on the host.
This means that even if a process runs as root inside the
container, it can be mapped to a non-privileged user on the
host, decreasing the risk of privilege escalation attacks.

11.Question
What is the purpose of the ‘unshare’ command in Linux?
Answer:The ‘unshare’ command allows a user to run a
program with a new namespace (e.g., UTS, PID, or network

Scan to Download
namespace), effectively giving it a separate view of the
system resources, similar to how containers operate. It’s used
for testing and demonstrating isolation features of
namespaces.

Scan to Download
Chapter 4 | 4. Container Isolation| Q&A
1.Question
What are the main mechanisms that limit a container's
access to host resources?
Answer:Namespaces, changing the root directory,
and cgroups.

2.Question
What is the significance of namespaces in container
isolation?
Answer:Namespaces control what a process can see and
restrict visibility of resources to ensure that processes within
containers are isolated from the host and from each other.

3.Question
How does changing the root directory contribute to the
container's filesystem isolation?
Answer:Changing the root directory allows a process inside a
container to access only a subset of the filesystem beneath
the new root, isolating it from the host's filesystem.

4.Question
What are cgroups and what role do they play in container

Scan to Download
security?
Answer:Cgroups (control groups) manage and limit the
resources (CPU, memory, I/O) that a container can use,
preventing it from monopolizing system resources.

5.Question
Explain the difference between Linux containers and
virtual machines in terms of isolation.
Answer:Containers share the same OS kernel and only isolate
their processes, network stacks, etc., while virtual machines
have their own kernel and are more isolated from the host.

6.Question
What security implications arise from the fact that
containers share the Linux kernel with the host?
Answer:If an attacker compromises the host, they can
observe or manipulate all running containers, especially if
they gain elevated privileges.

7.Question
Why is it recommended to run container applications on
dedicated host machines?
Answer:To limit the attack surface and ensure that only

Scan to Download
necessary components are running, which reduces
vulnerabilities and increases security.

8.Question
What does a user namespace accomplish?
Answer:User namespaces enable the mapping of a container's
root user (UID 0) to a non-root user on the host, enhancing
security by limiting the privileges of a potential attacker.

9.Question
How can an attacker exploit space between user
namespaces and the host?
Answer:An attacker escaping a container could potentially
gain root privileges on the host if user namespaces are not
properly configured or isolated.

10.Question
What must be done to ensure that a process within a new
PID namespace can see only its own set of processes?
Answer:A separate copy of the /proc directory needs to be
created for the new process to limit its visibility to only the
processes within its PID namespace.

Scan to Download
Chapter 5 | 5. Virtual Machines| Q&A
1.Question
What are the fundamental differences between virtual
machines (VMs) and containers in terms of isolation and
security?
Answer:Virtual machines run an entire copy of an
operating system including its kernel, providing
strong isolation between applications through
hardware-level separation. In contrast, containers
share the host system's kernel, resulting in a weaker
isolation barrier since they operate within the same
kernel space. This difference makes VMs inherently
more secure against cross-application
vulnerabilities, whereas containers require
additional security measures to enhance their
isolation.

2.Question
How does the boot process of a physical server impact the
operation of virtual machines (VMs)?
Answer:When a physical server boots up, it runs a BIOS or

Scan to Download
UEFI that initializes hardware and loads an operating system
kernel. In a VM environment, a Virtual Machine Monitor
(VMM) performs this resource management, allocating CPU
and memory resources to each VM while ensuring they don't
breach their assigned limits, which is crucial for maintaining
security.

3.Question
What role does the 'USER' instruction in a Dockerfile
play in enhancing container security?
Answer:The 'USER' instruction in a Dockerfile sets a
non-root user to run the container instead of the default root
user. This helps mitigate security risks, as running containers
with root privileges can lead to potential privilege escalation
attacks.

4.Question
What are some best practices for building container
images to enhance security?
Answer:Best practices include using minimal, trusted base
images, applying multi-stage builds to eliminate unnecessary

Scan to Download
components, not including sensitive data in images, avoiding
setuid binaries, and ensuring that any RUN commands in the
Dockerfile are limited to trusted individuals.

5.Question
Why is it important to sign container images and what
tools are available for this purpose?
Answer:Signing container images is vital for verifying their
integrity and authenticity, ensuring that the images being
deployed are the ones intended. Tools implementing image
signing include Notary based on the TUF specification,
ensuring that each deployment is from a trusted source.

6.Question
How does the concept of GitOps improve container
deployment security?
Answer:GitOps improves security by keeping configuration
and state management code under version control, reducing
the need for direct access to running systems. This ensures
that only approved configurations are used for deployments,
creating a verifiable and auditable process.

Scan to Download
7.Question
What is the significance of quickly identifying and using
image digests instead of tags?
Answer:Using image digests provides a unique and
immutable reference to a specific image version, ensuring
that the exact same image with the same contents is
deployed. This helps prevent discrepancies when using tags
that might be reassigned to different versions, thus
maintaining consistent security.

8.Question
What risks does the build machine pose in container
security, and how can these be mitigated?
Answer:The build machine can be a target for attackers
aiming to influence the build process or directly execute
malicious code. Risk mitigation strategies include
minimizing access, running builds in isolated environments,
restricting network access, and using non-privileged tools to
build images.

9.Question
How does the use of namespaces and cgroups enhance

Scan to Download
container isolation?
Answer:Namespaces provide process isolation by allowing a
container to have its own views of system resources like
process IDs, user IDs, and network interfaces. Cgroups
(control groups) limit, police, and account for the resource
usage of the container, further enhancing security by
preventing resource contention and misuse.
Chapter 6 | 6. Container Images| Q&A
1.Question
What are the two main components of a container image?
Answer:The two main components of a container
image are the root filesystem and configuration
data.

2.Question
How do you override the configuration of a container
when running it?
Answer:You can override the configuration of a container at
runtime using command-line parameters in Docker (e.g.,
using -e to set environment variables) or by defining

Scan to Download
environment variables in a Kubernetes YAML definition.

3.Question
What does the Open Container Initiative (OCI) do?
Answer:The OCI defines standards around container images
and runtimes to ensure a consistent user experience across
different tools and platforms for building and managing
containers.

4.Question
Why is it risky to use 'docker build' without considering
security?
Answer:Because the Docker daemon runs as root, any user
able to invoke 'docker build' can potentially execute any
command on the host machine, leading to a risk of malicious
activity and privilege escalation.

5.Question
What is a safe practice when including sensitive data in
Dockerfiles?
Answer:You should avoid including sensitive data such as
passwords or tokens in Dockerfiles, as they can be accessed
by anyone with access to the image.

Scan to Download
6.Question
What does the term 'daemonless builds' refer to, and why
are they considered more secure?
Answer:Daemonless builds refer to the practice of using
tools like BuildKit or Podman that don't require running a
privileged Docker daemon, reducing the risk of unauthorized
command execution on the host.

7.Question
What should you do to ensure that your container images
don't run sensitive data?
Answer:You should never include sensitive data in any layer
of the image, even if it's removed in subsequent layers, as it
can still be accessed.

8.Question
What additional measures should be taken when using
container registries?
Answer:Ensure that your registries are secure by controlling
access, using image signing to verify integrity, and only
allowing images from trusted sources.

9.Question

Scan to Download
How can vulnerabilities in container images be mitigated
during the build process?
Answer:By implementing best practices such as using a
trusted base image, avoiding unnecessary packages,
performing vulnerability scans, and controlling access to
Dockerfiles.

10.Question
What considerations should be made when deploying
container images in orchestrators like Kubernetes?
Answer:It's crucial to verify that the correct image is being
deployed, use image digests instead of tags for accurate
reference, and implement admission control to ensure
compliance with security policies.

Scan to Download
Chapter 7 | 7. Software Vulnerabilities in Images|
Q&A
1.Question
What is the significance of the term 'vulnerability' in the
context of software security?
Answer:A vulnerability is a known flaw in software
that attackers can exploit for malicious purposes. It
signifies potential weaknesses that need to be
identified and addressed in order to enhance
software safety and security.

2.Question
Why is responsible security disclosure important after a
vulnerability is found?
Answer:Responsible security disclosure prevents the
immediate public announcement of vulnerabilities, which
could lead to exploitation by attackers. It ensures that
developers have time to create and release a fix before the
potential for data breaches increases.

3.Question
How does the CVE system function in tracking

Scan to Download
vulnerabilities?
Answer:The Common Vulnerabilities and Exposures (CVE)
system assigns unique identifiers to vulnerabilities, managed
by an organization called MITRE. It assists in cataloging
vulnerabilities reported each year, simplifying information
access for security management.

4.Question
In what ways can containerization address dependency
management problems?
Answer:Containerization isolates applications by providing
separate root filesystems for each container, minimizing
compatibility issues that arise from different applications
needing various package versions on the same host system.

5.Question
What role does regular scanning play in vulnerability
management?
Answer:Regular scanning helps identify newly discovered
vulnerabilities and check for updates to existing
vulnerabilities, allowing organizations to maintain secure

Scan to Download
environments and be proactive about potential exploits.

6.Question
What is the purpose of using seccomp in container
security?
Answer:Seccomp restricts the set of system calls an
application can make, limiting its ability to interact with
critical system services and reducing the attack surface for
potential exploits.

7.Question
How do AppArmor and SELinux enhance Linux
security?
Answer:Both provide mandatory access control, allowing
administrators to enforce policies that govern how processes
interact with files and other system resources, thereby
limiting potential damage from compromised applications.

8.Question
What are some downsides of using default security
profiles for applications?
Answer:Default security profiles may not be tailored for
specific applications, potentially allowing too many

Scan to Download
privileges or failing to restrict necessary system calls, which
can create vulnerabilities.

9.Question
Why might a zero-day vulnerability be more concerning
than a known one?
Answer:Zero-day vulnerabilities are unknown to the public
and typically lack immediate fixes, posing a heightened risk
as attackers have time to exploit them before they are
discovered and patched.

10.Question
How can organizations effectively manage and automate
vulnerability scanning in CI/CD pipelines?
Answer:By integrating vulnerability scanning as an
automated step in the CI/CD pipeline, organizations can
ensure regular assessments of application security, promptly
addressing vulnerabilities before deployment.
Chapter 8 | 8. Strengthening Container Isolation|
Q&A
1.Question
What is one of the most significant vulnerabilities

Scan to Download
regarding containers and user permissions?
Answer:By default, containers run as root unless
specified otherwise, leading to potential privilege
escalation where a compromised container can gain
root access to the host.

2.Question
How does seccomp enhance container security?
Answer:Seccomp limits the system calls that a containerized
application can make, effectively acting as a filter to prevent
the execution of harmful commands.

3.Question
What are some pitfalls of AppArmor and SELinux in
container security management?
Answer:Both AppArmor and SELinux can be challenging to
configure correctly, and maintaining their profiles as
applications change can impose significant administrative
overhead.

4.Question
What innovative method does gVisor utilize for container
isolation?

Scan to Download
Answer:gVisor acts as a user-space kernel, intercepting
system calls and applying security policies similar to a
virtual machine, providing an additional layer of isolation.

5.Question
What is the benefit of using rootless containers?
Answer:Rootless containers allow non-root users to run
containers without granting them root access on the host,
significantly reducing the risk of privilege escalation.

6.Question
How can mounting sensitive directories from the host
compromise a container's isolation?
Answer:By mounting host directories, especially root
directories (/), a container may gain access to critical system
files, allowing a compromised container to affect the host's
security.

7.Question
What does the --privileged flag do in Docker?
Answer:It grants a container access to all the host's
capabilities, essentially elevating its privileges, which can be
dangerous and lead to potential exploits.

Scan to Download
8.Question
What do sidecar containers accomplish in a microservices
architecture?
Answer:Sidecar containers offload functionality, such as
networking or logging, from application containers, allowing
for improved efficiency and reusability across microservices.

9.Question
What is the primary concern when a container is
configured to run as root?
Answer:If an attacker escapes from a root container, they
gain full root access to the host, which poses serious security
risks.

10.Question
What strategies can be employed to enhance the security
of containerized applications?
Answer:Using non-root user IDs, applying minimal
capabilities, employing seccomp or AppArmor profiles, and
opting for rootless containers are effective strategies for
improving security.
Chapter 9 | 9. Breaking Container Isolation| Q&A

Scan to Download
1.Question
What is the default user that containers run as, and why
is this a security concern?
Answer:Containers run as root by default. This
poses a security risk because if an attacker escapes
from a root container, they gain full root access to
the host machine.

2.Question
How can you mitigate the risk of running containers as
root?
Answer:By running containers as non-root users or utilizing
rootless containers, where non-root host user IDs can be
mapped to root inside containers.

3.Question
What does the --privileged flag do in the context of
container security?
Answer:The --privileged flag grants a container additional
capabilities and access to the host's resources, potentially
leading to severe security breaches. It can allow a container
to perform almost any action on the host.

Scan to Download
4.Question
Explain the concept of 'sidecar containers.' How do they
enhance functionality?
Answer:Sidecar containers run alongside application
containers, providing shared functionality such as handling
networking or observability without compromising the
isolation of the application container.

5.Question
Why is it important to configure network policies in
environments like Kubernetes?
Answer:Network policies control traffic flow between pods,
ensuring that only authorized pods can communicate, which
improves security and minimizes unauthorized access or
attacks.

6.Question
What are the potential dangers of mounting sensitive
directories from the host into a container?
Answer:Mounting sensitive directories can allow an attacker
with access to the container to modify critical files on the
host, such as /etc/passwd or logging directories, potentially

Scan to Download
leading to full control of the host.

7.Question
What are rootless containers and what advantages do
they offer?
Answer:Rootless containers allow non-root users to run
containers without needing root privileges, which reduces the
risk of privilege escalation attacks in shared environments.

8.Question
How do service meshes enhance security in containerized
applications?
Answer:Service meshes can enforce mutual TLS for secure
communication, provide traffic control policies, and isolate
applications at the application layer, enhancing overall
security.

9.Question
Discuss the principle of 'least privilege' as it pertains to
container deployment.
Answer:The principle of least privilege means configuring
containers and services to have only the permissions
necessary for their tasks, minimizing potential damage from

Scan to Download
compromised containers.

10.Question
How might a compromised application container affect
the overall safety of a service mesh?
Answer:If a service mesh sidecar is compromised, the
security policies it enforces could be bypassed, allowing an
attacker to attack other services or resources.

Scan to Download
Chapter 10 | 10. Container Network Security| Q&A
1.Question
Why is understanding networking essential for securing
applications and data in a container deployment?
Answer:Understanding networking is crucial
because external attacks rely on network pathways
to reach applications. By comprehending
networking principles, one can better secure
applications and data within container deployments,
preventing unauthorized access and ensuring proper
traffic management.

2.Question
What advantages do container firewalls offer over
traditional firewalls?
Answer:Container firewalls provide a more granular
approach to network security, enabling specific traffic
restrictions for container interactions, unlike traditional
firewalls that may operate at a broader level.

3.Question
How does the seven-layer OSI networking model relate to

Scan to Download
container network security?
Answer:The OSI model segments networking functions into
seven layers, allowing a structured approach to
understanding how different network features operate at
various levels. This model helps in identifying which layer
certain security measures, including firewalls and policies,
act upon.

4.Question
What is the role of a service mesh in container
networking security?
Answer:A service mesh facilitates secure communication
between application components through sidecar proxies,
enforcing policies and managing traffic at the application
layer while enabling encrypted connections using mutual
TLS.

5.Question
What should a best practice for network policies within
Kubernetes be?
Answer:A best practice is to implement a 'default deny'

Scan to Download
policy for both ingress and egress traffic, allowing only
expected and approved communications to enhance security
across namespaces.

6.Question
What does mutual TLS (mTLS) provide in container
communications?
Answer:mTLS establishes secure, encrypted connections
between containers, ensuring that each component can
authenticate the other, thereby preventing unauthorized
access and eavesdropping.

7.Question
How can the principle of 'defense in depth' be applied to
container network security?
Answer:Defense in depth involves employing multiple layers
of security controls, such as combining container firewalls
with network policies and service meshes, to protect
applications from various attack vectors.

8.Question
What challenges might arise with managing iptables rules
in a Kubernetes environment?

Scan to Download
Answer:Managing iptables can become cumbersome with a
large number of rules, especially if many services and pods
are involved, leading to performance issues and complexity
in configuration.

9.Question
Why is it important to limit pod-to-pod traffic in
Kubernetes?
Answer:Limiting pod-to-pod traffic enhances security by
restricting communication to only necessary pods, which
prevents potential lateral movement by compromised
containers.

10.Question
What is the significance of Certificate Signing Requests
(CSRs) in securing communications?
Answer:CSRs play a critical role in obtaining X.509
certificates by providing the necessary information, like
public keys and identity details, to certificate authorities for
issuing valid certificates that secure communications.
Chapter 11 | 11. Securely Connecting Components
with TLS| Q&A

Scan to Download
1.Question
Why is it important to have secure connections between
components in a distributed system?
Answer:Secure connections are critical in a
distributed system to protect communication
between components from interception or tampering
by malicious entities. Ensuring the confidentiality
and integrity of the messages exchanged helps
maintain trust and security in operations, especially
for sensitive data like credentials, financial
information, or personal data.

2.Question
What role do X.509 certificates play in establishing secure
connections?
Answer:X.509 certificates authenticate the identity of the
parties involved in a connection. They provide the public key
necessary for encryption and allow components to verify that
they are communicating with trusted entities, preventing
impersonation and ensuring secure data exchange.

Scan to Download
3.Question
What is mutual TLS (mTLS) and when is it used?
Answer:Mutual TLS (mTLS) is an extension of the TLS
protocol that requires both the client and server to
authenticate each other using their respective certificates. It is
used in scenarios where both parties need to establish trust,
enhancing security in communication, particularly in
microservices architectures.

4.Question
How does a Certificate Signing Request (CSR) function in
the process of obtaining an X.509 certificate?
Answer:A Certificate Signing Request (CSR) contains the
public key of an entity, domain names, and identity
information. It is sent to a Certificate Authority (CA) to
request the issuance of an X.509 certificate. The CA verifies
the request and, if everything checks out, signs the
certificate, thus validating the entity's identity.

5.Question
Why is certificate revocation necessary, and how can it be
achieved?

Scan to Download
Answer:Certificate revocation is necessary to invalidate
certificates that are no longer trusted, such as those
compromised by unauthorized access. This can be achieved
by maintaining a Certificate Revocation List (CRL) that
contains identifiers of revoked certificates, ensuring that
parties can verify the status of certificates before trusting
them.

6.Question
What are the disadvantages of passing secrets as
environment variables?
Answer:Passing secrets as environment variables can lead to
security risks since environment settings can be exposed
through crash dumps, logs, or simply by inspecting container
configurations. If an attacker gains access to the host, they
can easily access these environment variables, including
sensitive information.

7.Question
What advantages does Kubernetes Secrets provide
compared to traditional methods of secret management?

Scan to Download
Answer:Kubernetes Secrets allow for the management of
sensitive information as independent resources. They support
encryption at rest and in transit, can be mounted as files or
environment variables without exposing them, and permit
fine-grained access controls through RBAC, enhancing
security compared to traditional methods.

8.Question
How can secrets be compromised even if they are
encrypted?
Answer:Secrets can be compromised if access controls are
poor, such as if a malicious actor gains root access to the host
machine, allowing them to access both encrypted secrets and
decryption keys. Once they can access the system, they can
often retrieve the plaintext secrets if the application needs to
use them.

9.Question
What steps can be taken to mitigate the risks associated
with handling secrets?
Answer:To mitigate risks, secrets should be managed by

Scan to Download
centralized secret management systems, encrypted during
transit and at rest, only passed to components that need them,
and rotated regularly. Access controls should be
implemented so that only designated entities can manage or
access sensitive information.

10.Question
Why is it advisable to avoid hardcoding secrets in
application source code?
Answer:Hardcoding secrets in source code exposes them to
anyone who can access the repository or inspect the
codebase. This increases the risk of unintended disclosure
and makes it challenging to manage and rotate secrets
without rebuilding the entire application, leading to potential
security vulnerabilities.
Chapter 12 | 12. Passing Secrets to Containers| Q&A
1.Question
What is the most important thing to ensure when
handling secrets in containers?
Answer:The most important thing to ensure when

Scan to Download
handling secrets in containers is that they stay
"secret" and are only accessible to components or
individuals who really need them, adhering to the
principle of least privilege. This involves encrypting
secrets both at rest and in transit, and ideally
keeping unencrypted secrets in memory only.

2.Question
What are the preferred methods for passing secrets to
applications running in containers?
Answer:The preferred method for passing secrets to
applications running in containers is to use files stored in a
mounted volume, ideally in a temporary in-memory
filesystem. This allows for easy updates without restarting
the container. Environment variables and including secrets
directly in the container image are generally discouraged due
to security risks.

3.Question
How does Kubernetes support the management of
secrets?

Scan to Download
Answer:Kubernetes provides native support for managing
secrets, which can be created as independent resources, thus
decoupling them from the lifecycle of the application code.
Kubernetes secrets can be encrypted at rest and in transit, and
the system supports mounting secrets as files in memory and
setting role-based access controls (RBAC).

4.Question
What risks are involved with passing secrets through
environment variables?
Answer:Passing secrets through environment variables can
expose them to risks such as being dumped in debug
information after crashes, potentially appearing in logs, and
being visible through commands like 'docker inspect'. This
makes them vulnerable to unauthorized access.

5.Question
Why is it important to revoke and rotate secrets?
Answer:Revoking and rotating secrets is crucial to maintain
security, as it ensures that compromised credentials are
invalidated and that any potential attacker is only able to use

Scan to Download
a secret until it is changed. Regularly changing secrets can
also mitigate risks by limiting the time an attacker has access
to a compromised secret.

6.Question
How can the principle of immutability in containers
enhance security?
Answer:The principle of immutability in containers enhances
security by ensuring that the contents of a container, once
deployed, do not change. This limits the potential for
unauthorized modifications or vulnerabilities being
introduced post-deployment, and allows for more robust
monitoring, profiling, and enforcement of security policies.

7.Question
What is eBPF and how does it relate to container
security?
Answer:eBPF, or extended Berkeley Packet Filter, is a
technology that allows the execution of sandboxed programs
in the Linux kernel. It is used in container security tools like
Tracee to observe and monitor the behavior of containers,

Scan to Download
such as tracking running executables or system calls to detect
anomalies and security breaches.

8.Question
What should security tools do when they detect
anomalous behavior in containers?
Answer:When security tools detect anomalous behavior in
containers, they should ideally prevent the unexpected
actions from occurring, providing robust enforcement of
security policies. However, they should also generate alerts
or logs for investigation, allowing for a balance between
real-time protection and incident response.

9.Question
What is drift prevention in the context of container
security?
Answer:Drift prevention refers to the practice of ensuring
that the state of a container remains consistent with its
original image, preventing unauthorized changes. Security
solutions achieve this by comparing running processes and
files against a baseline fingerprint established during the

Scan to Download
scanning of the container image.

10.Question
Why is it considered a bad practice to allow developers
root access within containers?
Answer:Allowing developers root access within containers is
considered a bad practice because it can lead to privilege
escalation, where an attacker could exploit such access to
compromise the host system. Since root access within a
container gives equivalent control over the host, it poses
significant security risks.

11.Question
How can secrets be made inaccessible to unauthorized
users within an organization?
Answer:Secrets can be made inaccessible to unauthorized
users by implementing strong role-based access control
(RBAC), ensuring that only necessary personnel or software
components have access to specific secrets needed for their
operation, while employing encryption and secure storage
methods.

Scan to Download
Chapter 13 | 13. Container Runtime Protection|
Q&A
1.Question
How can container images improve security in
microservice architectures?
Answer:Container images allow developers to break
down complex applications into smaller,
self-contained microservices, each with a defined
runtime profile. This modularity simplifies the
design, coding, and testing process, while also
enhancing security by enabling tailored protections
for each service.

2.Question
What role do container image profiles play in runtime
protection?
Answer:Container image profiles define the expected
behavior and permissions of a microservice, allowing
security tools to monitor and restrict the traffic and actions of
containers instantiated from that image.

3.Question

Scan to Download
How does eBPF contribute to security within containers?
Answer:eBPF enables the observation of executables running
inside containers, allowing for real-time monitoring. It can
detect when unauthorized processes are started, thus helping
to prevent attacks like cryptocurrency mining within a
container.

4.Question
What should be monitored to ensure proper security for
containerized applications?
Answer:Security for containerized applications requires
monitoring network traffic, user IDs, executable processes,
and file access, with alerts to identify any deviations from the
established behavior profile.

5.Question
What is drift prevention in the context of container
security?
Answer:Drift prevention involves ensuring that the contents
of a container remain unchanged from its image, which can
be enforced through file fingerprinting. If an executable

Scan to Download
doesn't match the expected fingerprint, execution is denied,
preventing unauthorized changes.

6.Question
Why is proper logging considered crucial in container
security?
Answer:Adequate logging allows for tracking of container
events and anomalies, which can help identify and respond to
security breaches quickly. Monitoring should include actions
like access to secrets, privilege modifications, and network
traffic.

7.Question
How can organizations respond to anomalous behavior in
containers?
Answer:Organizations must decide whether to prevent
anomalous behavior outright or alert administrators. Ideal
solutions would prevent unauthorized actions while still
logging details for investigation.

8.Question
What can be done to secure sensitive data in containers?
Answer:Sensitive data should be encrypted both at rest and in

Scan to Download
transit, and access must be limited to only those containers
that absolutely need it. Best practices include secure
management of secrets and regular image scanning for
vulnerabilities.

9.Question
What is the significance of the OWASP Top 10 in
container security?
Answer:The OWASP Top 10 outlines the most prevalent
security risks for web applications, serving as a guideline for
organizations to secure containerized deployments against
common vulnerabilities.

10.Question
How can organizations mitigate the risk of broken access
control in containers?
Answer:Organizations can implement least privilege access,
avoid running containers as root, and utilize security features
like seccomp and AppArmor to limit container capabilities.
Chapter 14 | 14. Containers and the OWASP Top 10|
Q&A
1.Question

Scan to Download
What are the key principles of securing containerized
applications against the OWASP Top 10 vulnerabilities?
Answer:The key principles include: 1. **Injection
Defenses**: Implement thorough input validation
and utilize container image scanning to check for
known vulnerabilities in dependencies. 2. **Broken
Authentication**: Treat container credentials as
secrets, passing them securely into containers at
runtime and ensuring secure communication. 3.
**Sensitive Data Exposure**: Encrypt sensitive data
both at rest and in transit using strong algorithms,
applying least privilege principles on access to
sensitive data. 4. **XML External Entities**:
Analyze application code for XXE vulnerabilities
and scan images for vulnerabilities in dependencies.
5. **Broken Access Control**: Apply least privilege
to containers by not running as root, limiting
capabilities, and utilizing tools like AppArmor or
SELinux. 6. **Security Misconfiguration**: Follow

Scan to Download
security benchmarks and guidelines for
configurations, particularly in cloud environments.
7. **Cross-Site Scripting (XSS)**: Implement
secure coding practices, including input validation
and using image scanners to identify vulnerabilities.
8. **Insecure Deserialization**: Isolate
deserialization processes in low-privilege
environments and restrict network traffic
accordingly. 9. **Using Components with Known
Vulnerabilities**: Regularly update container
images and replace vulnerable instances. 10.
**Insufficient Logging and Monitoring**: Log
critical events, integrate with SIEM systems and
establish alerting on unusual behaviors.

2.Question
How should sensitive data be handled in container
environments to ensure security?
Answer:Sensitive data should always be encrypted at rest and
in transit. Use strong cryptographic algorithms and follow

Scan to Download
the principle of least privilege by providing access only to
the containers that require it. Additionally, regularly scan
container images for embedded keys and passwords, and
consider using dedicated tools for managing secrets.

3.Question
What are some specific practices to mitigate broken
access control in containerized environments?
Answer:To mitigate broken access control, do not run
containers as root, limit the capabilities granted to each
container, and use isolation tools such as seccomp,
AppArmor, or SELinux. Additionally, apply user-level
permissions and ensure containers communicate securely
using certificates.

4.Question
Why is logging and monitoring important in container
security?
Answer:Logging and monitoring are crucial for detecting
security breaches promptly. They facilitate tracking events
like container start/stop actions, access to secrets, and

Scan to Download
modifications to privileges. This helps identify and respond
to malicious activities before they lead to significant
breaches.

5.Question
How can organizations use the OWASP Top 10 as a
resource for their container security strategy?
Answer:Organizations can use the OWASP Top 10 as a
framework to assess potential vulnerabilities in their
containerized applications. By implementing best practices
associated with each vulnerability listed, organizations can
prioritize their security efforts and make informed decisions
about risk management.

6.Question
What role do container image scanners play in container
security?
Answer:Container image scanners play a critical role in
identifying known vulnerabilities within container images,
including those in third-party dependencies. They help
ensure that outdated or vulnerable packages are either

Scan to Download
updated or removed from a deployment, thereby reducing the
attack surface.

7.Question
What are the consequences of insufficient logging and
monitoring during a breach?
Answer:Insufficient logging and monitoring can result in
breaches taking longer to detect, with the average breach
lasting almost 200 days before discovery. This prolonged
exposure increases damage potential, complicates incident
response, and can lead to more significant data loss.

8.Question
What steps should be undertaken to manage secrets in
containerized applications effectively?
Answer:Secrets should be treated as confidential data, stored
securely using secret management services, and passed to
containers at runtime through environment variables or
secrets management tools. Ensure that secrets are never
hardcoded or exposed in logs.

9.Question
What is a recommended practice for ensuring secure

Scan to Download
configurations in container deployments?
Answer:Organizations should follow guidelines such as the
Center for Internet Security (CIS) Benchmarks for Docker
and Kubernetes to assess and enforce secure configurations.
This ensures that their environments are consistent with
industry best practices and reduces potential vulnerabilities.

10.Question
How does isolating deserialization processes enhance
security in containers?
Answer:Isolating deserialization processes in low-privilege
environments helps prevent unauthorized privilege escalation
or malicious object injections from impacting other
components of the application. By confining these processes,
organizations can limit the attack surface and better manage
risks.
Chapter 15 | Conclusions| Q&A
1.Question
What is the most crucial takeaway regarding the
communication of containers with the outside world?

Scan to Download
Answer:Containers serve as units of both
deployment and security. It’s essential to restrict
traffic flow to only what is expected, ensuring secure
communication between containers and external
systems.

2.Question
How do layered defenses enhance the security of
container deployments?
Answer:Layered defenses add multiple barriers for attackers
to breach. If one layer is compromised due to a vulnerability,
the attacker still faces additional defenses, making it
significantly less likely for them to succeed in their attack.

3.Question
What are some unique prevention measures specific to
containers?
Answer:Container-specific prevention measures include
scanning images for vulnerabilities, using seccomp or
AppArmor profiles, enforcing immutable containers, and
implementing network policies to restrict traffic.

Scan to Download
4.Question
How can one assess the vulnerabilities in their container
deployment?
Answer:Review the list of attack vectors in the 'Container
Threat Model' and use the questions in the appendix to
evaluate where your deployment might be vulnerable.

5.Question
What should you do if you experience a security breach?
Answer:It is encouraged to provide feedback, comments, and
share your attack experiences with the author or raise issues
at containersecurity.tech, fostering a community of learning
from incidents.

6.Question
Why is it important to run all containers as a non-root
user?
Answer:Running containers as a non-root user minimizes the
risk of privilege escalation attacks, as root access can provide
attackers with a powerful foothold within the system.

7.Question
What considerations should be made regarding container

Scan to Download
images to enhance security?
Answer:Choose minimal base images, enforce the use of
immutable containers by including all code at build time, and
regularly monitor for vulnerabilities in your images.

8.Question
What role do secrets management systems play in
container security?
Answer:Secrets management systems help in securely storing
and rotating sensitive information, ensuring that secrets are
encrypted both at rest and in transit, preventing unauthorized
access.

9.Question
How can technology like mTLS contribute to the security
of container applications?
Answer:mTLS (mutual TLS) can secure communications
between container components by ensuring that only
authorized components communicate with each other,
verifying both client and server identities.

10.Question
What is the significance of using a runtime protection tool

Scan to Download
in containers?
Answer:A runtime protection tool ensures that only expected
executables are running inside containers, offering an extra
layer of security against unauthorized modifications or
intrusions.

Scan to Download
Chapter 16 | Security Checklist| Q&A
1.Question
How can running containers as a non-root user improve
security?
Answer:Running containers as a non-root user
minimizes the risk of privilege escalation and
potential damage. If a container is compromised, the
attacker has no root access to the host system,
limiting their ability to cause harm.

2.Question
What are the risks associated with using the --privileged
flag when running containers?
Answer:The --privileged flag grants a container extended
permissions, effectively giving it capabilities akin to a root
user on the host. This can lead to severe security
vulnerabilities, such as allowing malicious containers to
access the host's kernel and manipulate system levels.

3.Question
What does it mean to run containers as read-only?
Answer:Running containers as read-only ensures that no

Scan to Download
changes can be made to the file system after the container is
started. This approach, part of making containers immutable,
enhances security by preventing unauthorized changes to the
application or the system.

4.Question
Why is it important to scan container images for
vulnerabilities?
Answer:Scanning container images for vulnerabilities is
crucial to uncover security flaws before deployment. This
proactive measure helps in identifying issues that could be
exploited by attackers, thereby allowing teams to address
security risks early.

5.Question
What is a seccomp profile and why should it be used?
Answer:A seccomp profile limits the system calls that a
container can make, restricting its capabilities to those
necessary for its operations. This greatly reduces the attack
surface and the risk of system exploitation.

6.Question
What role does SELinux play in container security?

Scan to Download
Answer:SELinux enforces mandatory access controls on
containers, restricting how applications within containers
interact with each other and the host system. By
implementing SELinux, you can help prevent unauthorized
data access and potential breaches.

7.Question
How can implementing mTLS connections enhance
security in a microservices architecture?
Answer:Using mutual TLS (mTLS) connections ensures that
both the client and server authenticate each other before
exchanging data. This process mitigates risks such as
man-in-the-middle attacks and ensures secure
communication between services.

8.Question
Why is admission control critical in a container
deployment environment?
Answer:Admission control helps ensure that only approved,
secure images are used in production environments. This
prevents the deployment of potentially vulnerable or

Scan to Download
malicious containers, thus protecting the overall application
ecosystem.

9.Question
What are the benefits of using immutable containers?
Answer:Immutable containers reinforce security by ensuring
that all executable code is packaged and defined at build
time, thus preventing runtime modifications. This reduces the
chances of introducing vulnerabilities through unsanctioned
changes or updates.

10.Question
How does enforcing resource limits on containers
contribute to security?
Answer:Setting resource limits on containers helps to prevent
denial-of-service attacks by constraining resource usage,
which can mitigate the impact of a compromised container
attempting to monopolize CPU and memory resources.

Scan to Download
Container Security Quiz and Test
Check the Correct Answer on Bookey Website

Chapter 1 | 1. Container Security Threats| Quiz and

Test
1.The release of Docker in 2013 had a significant
impact on the popularity of container technology.
2.Containerized applications cannot run simultaneously on
the same machine without conflicts due to their
architecture.
3.Linux capabilities provide broader permission control than
traditional setuid, thus enhancing container security.
Chapter 2 | 2. Linux System Calls, Permissions, and
Capabilities| Quiz and Test
1.Containers primarily run on Windows, making
Linux system calls irrelevant for container
security.
2.File permissions in Linux dictate which users can access
files and what actions they can perform.
3.The setuid bit allows processes to run with non-elevated

Scan to Download
 privileges, posing no security concerns.
Chapter 3 | 3. Control Groups| Quiz and Test
1.Control groups (cgroups) are used to limit the
memory, CPU, and network I/O for individual
processes in Linux containers.
2.Cgroups v2 allows processes to join different groups for
different resource controllers without any restrictions.
3.Linux namespaces are utilized to provide visibility and
access control among containerized applications,
preventing them from interfering with one another.

Scan to Download
Chapter 4 | 4. Container Isolation| Quiz and Test
1.Containers rely on unique Linux features for their
security boundaries, which differ from virtual
machines.
2.The User Namespace feature allows users running
containers to have root privileges on the host system,
compromising security.
3.Cgroups can control the network interfaces available to a
container.
Chapter 5 | 5. Virtual Machines| Quiz and Test
1.Virtual Machine Monitors (VMMs) provide an
abstraction over hardware resources by allocating
memory and CPU, setting up virtual devices, and
ensuring resource boundaries are maintained.
2.Containers provide stronger isolation guarantees than
virtual machines due to their architecture and functionality.
3.The Open Container Initiative (OCI) sets standards for
container images, ensuring compatibility and consistent
user experiences.

Scan to Download
Chapter 6 | 6. Container Images| Quiz and Test
1.A container image consists of three main parts: the
root filesystem, configuration settings, and
metadata.
2.Users with access to the Docker socket can execute
commands which may pose a security risk.
3.Docker images should always be pushed to untrusted
registries to ensure maximum exposure and accessibility.

Scan to Download
Chapter 7 | 7. Software Vulnerabilities in Images|
Quiz and Test
1.Patching vulnerabilities is an essential part of
maintaining secure deployments in container
technology.
2.Vulnerabilities in software are only found in operating
system packages and not in application-level libraries.
3.Regular rescanning of vulnerabilities is unnecessary due to
the isolated nature of container images.
Chapter 8 | 8. Strengthening Container Isolation|
Quiz and Test
1.Sandboxing involves isolating applications to limit
their access to resources, enhancing security.
2.AppArmor works on a per-user basis to enforce mandatory
access controls through profiles associated with
executables.
3.Firecracker is a lightweight virtual machine designed for
rapid startup and is optimized for running multiple
microVMs efficiently on shared resources.

Scan to Download
Chapter 9 | 9. Breaking Container Isolation| Quiz
and Test
1.Containers run as the root user by default, which
poses security risks.
2.Rootless containers eliminate all functionalities and
behaviors of traditional container images.
3.Mounting the Docker socket is safe and recommended in
production environments.

Scan to Download
Chapter 10 | 10. Container Network Security| Quiz
and Test
1.Container firewalls provide granular control over
network traffic in microservice architectures.
2.In Kubernetes, network policies are optional and do not
play a role in container firewalling.
3.Each pod in Kubernetes receives its own IP address,
allowing for direct communication without using NAT.
Chapter 11 | 11. Securely Connecting Components
with TLS| Quiz and Test
1.Transport Layer Security (TLS) is primarily used
for secure communication between container
components in distributed systems.
2.X.509 certificates do not contain information about the
identity of the owner or their public key.
3.In Kubernetes, the preferred method for passing secrets into
containers is including them in the container image.
Chapter 12 | 12. Passing Secrets to Containers| Quiz
and Test
1.Secrets must remain confidential and are typically

Scan to Download
 ensured by encryption.
2.Hardcoding secrets in images is a secure practice when
building container images.
3.Role-based access control (RBAC) in Kubernetes can
restrict access to secrets.

Scan to Download
Chapter 13 | 13. Container Runtime Protection|
Quiz and Test
1.In container security, runtime profiles help govern
the expected behaviors of instantiated containers.
2.Containers should operate under multiple user identities to
allow various operations without restriction.
3.Regularly scanning and updating dependencies is not
necessary for containers as they are isolated from known
vulnerabilities.
Chapter 14 | 14. Containers and the OWASP Top 10|
Quiz and Test
1.The OWASP Top 10 only lists vulnerabilities that
are specific to web applications, not applicable to
containerized applications.
2.Sensitive data in containerized applications should be
protected through strong encryption and proper access
controls.
3.Running containers as root is considered a best practice for
maintaining security in container environments.

Scan to Download
Chapter 15 | Conclusions| Quiz and Test
1.Containers provide a unit of deployment but not
security.
2.Implementing layered defenses increases the chances of
thwarting attacks in container environments.
3.You should not run containers as a non-root user to ensure
better security.

Scan to Download
Chapter 16 | Security Checklist| Quiz and Test
1.All containers should be run as a root user to
ensure they have necessary permissions.
2.Container images should be regularly scanned for
vulnerabilities to maintain security integrity.
3.Using the --privileged flag for containers is a recommended
security practice.

Scan to Download