Skip to content

Lesson 02 — Container Image Architecture

By the end of this lesson, you will be able to:

  • Understand what a container image is
  • Learn how container images are built
  • Understand image layers and Union File Systems
  • Explore Dockerfile architecture
  • Learn how container images are stored and distributed
  • Understand how image architecture impacts security
  • Apply enterprise container image best practices for Amazon EKS

Every container running in Kubernetes starts from a container image.

The image contains everything required to run an application, including:

  • Operating system libraries
  • Runtime environment
  • Application code
  • Configuration
  • Dependencies
  • Startup commands

If the image is poorly designed or contains vulnerabilities, every container created from it inherits those security weaknesses.

Understanding container image architecture is the first step toward building secure Kubernetes workloads.


A container image is an immutable package that contains everything an application needs to execute.

Unlike a virtual machine, a container image does not contain an entire operating system.

Instead, it shares the host kernel while packaging only the components required by the application.

Container Image
├── Base Operating System
├── Runtime
├── Libraries
├── Dependencies
├── Application Code
└── Startup Configuration

Once built, the image should never be modified.


A container image is a template.

A running container is an instance of that template.

Container Image
Container
Running Application

Think of it like this:

  • Image = Blueprint
  • Container = Building constructed from the blueprint

One image can create thousands of identical containers.


Developer
Source Code
Dockerfile
Build Image
Image Scan
Container Registry
Deploy
Amazon EKS
Running Container

Every stage should include security validation.


A typical image contains several components.

Container Image
├── Base Image
├── Package Manager
├── Runtime
├── Application Dependencies
├── Application Files
├── Configuration
└── Metadata

Each component contributes to the overall security posture.


Container images are built using layers.

Each instruction in a Dockerfile creates a new layer.

Application Layer
──────────────
Dependencies
──────────────
Runtime
──────────────
Base Image

When Kubernetes starts a container, these layers are combined into a single filesystem.


Layering provides several advantages.

  • Faster image builds
  • Efficient storage
  • Layer reuse
  • Faster downloads
  • Reduced network usage
  • Improved caching

If only the application code changes, Kubernetes reuses the existing lower layers.


Container runtimes use a Union File System (UnionFS) to combine multiple layers into one virtual filesystem.

Application Layer
Dependencies
Runtime
Base Image
Unified Filesystem
Running Container

Applications see a single filesystem even though it is built from multiple layers.


Image layers are read-only.

When a container starts:

Read-Only Image
Writable Container Layer
Running Application

The writable layer exists only while the container is running.

Once the container is deleted, any changes in the writable layer are lost unless external storage is used.


Every container image starts with a base image.

Examples include:

  • Amazon Linux
  • Alpine Linux
  • Ubuntu
  • Debian
  • Distroless Images

The security of the base image directly affects every application built on top of it.


Enterprise organizations prefer base images that are:

  • Officially maintained
  • Frequently updated
  • Minimal
  • Vulnerability scanned
  • Digitally signed
  • Supported by the vendor

Smaller images generally contain fewer packages and therefore a smaller attack surface.


A Dockerfile defines how a container image is built.

Typical workflow:

Base Image
Install Packages
Copy Application
Configure Runtime
Define Startup Command
Build Image

Every instruction creates a new image layer.


FROM amazonlinux:2023
WORKDIR /app
COPY . .
RUN yum install -y python3
RUN pip install -r requirements.txt
USER 1000
CMD ["python3", "app.py"]

Notice that the application runs as a non-root user rather than the default root account.


Every container image includes metadata such as:

  • Image ID
  • Digest
  • Tags
  • Labels
  • Architecture
  • Build information

Example:

Image
Digest
sha256:xxxxxxxx

The image digest uniquely identifies the exact image contents.


Image Tag Image Digest
Human-readable Cryptographic identifier
Can change Immutable
Example: v1.2 Example: sha256:abc123...
Convenient for developers Best for production deployments

Enterprise deployments often reference image digests to ensure the exact approved image is deployed.


After an image is built, it is stored in a registry.

Developer
Build Image
Amazon ECR
Amazon EKS
Container

Amazon Elastic Container Registry (Amazon ECR) is the recommended private registry for Amazon EKS.


Modern container images can support multiple CPU architectures.

Example:

Image Manifest
├── AMD64
├── ARM64
└── Other Architectures

The container runtime automatically pulls the correct image for the target node.


Every additional package increases the attack surface.

Example:

Large Image
More Packages
More Vulnerabilities
Higher Risk

Instead:

Minimal Image
Fewer Packages
Smaller Attack Surface
Lower Risk

This is why minimal base images are recommended for production workloads.


Developer
Git Repository
Dockerfile
Build Pipeline
Image Scan
Amazon ECR
Amazon EKS
Running Container

Container image architecture forms the foundation of every Kubernetes deployment.


A global banking organization builds all production workloads using an enterprise image pipeline.

The pipeline automatically:

  • Builds images from approved base images
  • Removes unnecessary packages
  • Scans for vulnerabilities
  • Signs images
  • Pushes approved images to Amazon ECR
  • Rejects images that fail security policies

Application teams are prohibited from deploying public container images directly into production.

Every workload originates from an approved enterprise image.


Cloud Security Engineers frequently identify:

  • Large container images
  • Outdated base images
  • Unnecessary packages
  • Images built as root
  • Hardcoded secrets
  • Missing metadata
  • Public images without verification
  • Excessive image layers
  • Unpatched software
  • Untrusted image sources

These weaknesses increase the likelihood of software supply chain attacks.


Security teams should monitor:

  • Base image updates
  • Image build failures
  • Image vulnerabilities
  • Image digest changes
  • Registry access logs
  • Image signing validation
  • Unauthorized image uploads
  • CI/CD build events
  • Image age
  • Deployment source

Monitoring helps ensure only trusted images reach production.


A recommended implementation roadmap:

Step 1
Choose Approved Base Images
Step 2
Build Minimal Images
Step 3
Remove Unnecessary Packages
Step 4
Configure Non-Root User
Step 5
Scan Images
Step 6
Sign Images
Step 7
Store in Amazon ECR
Step 8
Deploy to Amazon EKS
Step 9
Continuously Monitor

This process reduces the attack surface while improving operational consistency.


As a Kubernetes Security Engineer:

  • Use trusted and officially maintained base images.
  • Prefer minimal or distroless images where appropriate.
  • Keep images small to reduce vulnerabilities.
  • Avoid installing unnecessary packages.
  • Configure images to run as non-root users.
  • Reference images by digest in production.
  • Store production images in private registries such as Amazon ECR.
  • Scan and sign every image before deployment.
  • Continuously update base images with security patches.
  • Automate image validation within CI/CD pipelines.

Secure image architecture is the foundation of a secure software supply chain.


A software company develops a new customer portal for Amazon EKS.

Initially, developers build the application using a large public Ubuntu image containing hundreds of unused packages.

During security scanning, the pipeline identifies multiple critical vulnerabilities inherited from the base image.

The team rebuilds the application using an approved minimal enterprise base image.

The new image:

  • Removes unnecessary software
  • Reduces the image size by more than half
  • Contains significantly fewer vulnerabilities
  • Runs as a non-root user
  • Is digitally signed before being stored in Amazon ECR

When deployed, the application provides the same functionality while presenting a much smaller attack surface.


After completing this lesson, you should understand:

  • What a container image is
  • How container images are built
  • Image layers and Union File Systems
  • Dockerfile architecture
  • Image metadata, tags and digests
  • Secure base image selection
  • Amazon ECR image management
  • Enterprise container image best practices

Container image architecture is the foundation of Kubernetes supply chain security. Well-designed images reduce vulnerabilities, improve consistency and support secure, repeatable deployments across Amazon EKS environments.


What is a container image?

  • A. A running application
  • B. An immutable package containing everything required to run an application
  • C. A Kubernetes Pod
  • D. A virtual machine

Answer: B


What creates a new layer in a container image?

  • A. Every Kubernetes Pod
  • B. Every Dockerfile instruction
  • C. Every Namespace
  • D. Every Deployment

Answer: B


Which identifier is immutable and uniquely identifies a container image?

  • A. Image Tag
  • B. Container Name
  • C. Image Digest
  • D. Pod UID

Answer: C


Which AWS service is the recommended private container registry for Amazon EKS?

  • A. Amazon S3
  • B. Amazon ECR
  • C. Amazon EC2
  • D. Amazon ECS

Answer: B


Which combination represents enterprise best practice?

  • A. Build large images from untrusted public sources and reference them by tag.
  • B. Use approved minimal base images, remove unnecessary packages, run as non-root, scan and sign images, and store them in Amazon ECR.
  • C. Install all available packages during image creation.
  • D. Modify running containers instead of rebuilding images.

Answer: B


In the next lesson, you will learn about Dockerfile Security Best Practices, where you’ll explore how secure Dockerfile design reduces vulnerabilities, minimizes image size, prevents privilege escalation and builds production-ready container images for Amazon EKS.

➡️ Next Lesson: Lesson 03 — Dockerfile Security Best Practices