Lesson 04 — Base Image Security
Learning Objectives
Section titled “Learning Objectives”By the end of this lesson, you will be able to:
- Understand what a base image is
- Learn why base image security is critical
- Compare different types of base images
- Understand the security risks of outdated images
- Learn how enterprise organizations manage approved base images
- Secure container images for Amazon EKS
- Apply enterprise best practices for base image governance
Why This Matters
Section titled “Why This Matters”Every container image begins with a base image.
The base image provides:
- Operating system libraries
- Package manager
- Runtime dependencies
- Core system utilities
- Default users and permissions
Every application built on top of that base image inherits its components and vulnerabilities.
If the base image contains outdated software or security flaws, every container built from it is also vulnerable.
Selecting a secure base image is one of the most important decisions in container security.
What is a Base Image?
Section titled “What is a Base Image?”A base image is the foundation upon which all other image layers are built.
Application Layer
↓
Dependencies
↓
Runtime
↓
Base ImageEverything above the base image depends on it.
Container Image Architecture
Section titled “Container Image Architecture”Application
↓
Libraries
↓
Runtime
↓
Operating System Components
↓
Base ImageThe base image is responsible for providing the core operating system environment.
Why Base Images Matter
Section titled “Why Base Images Matter”A vulnerable base image creates risk for every workload.
Example:
Outdated Base Image
↓
Known Vulnerability
↓
Application Image
↓
Production Container
↓
Security RiskEven if the application code is secure, inherited vulnerabilities can still be exploited.
Types of Base Images
Section titled “Types of Base Images”Enterprise environments commonly use several categories of base images.
| Type | Description |
|---|---|
| Official Images | Maintained by trusted vendors |
| Enterprise Images | Built and managed internally |
| Minimal Images | Contain only essential components |
| Distroless Images | Include only the application runtime |
| Community Images | Created by third parties |
The level of trust varies significantly between these image types.
Official Images
Section titled “Official Images”Official images are published by software vendors or trusted organizations.
Examples include:
- Amazon Linux
- Ubuntu
- Debian
- Alpine Linux
- Red Hat Universal Base Image (UBI)
Benefits:
- Regular security updates
- Vendor support
- Better documentation
- Predictable release cycles
Enterprise Base Images
Section titled “Enterprise Base Images”Many organizations build their own approved base images.
Example:
Amazon Linux
↓
Security Hardening
↓
Internal Packages
↓
Security Agents
↓
Enterprise Base ImageApplication teams must use these approved images instead of downloading public images.
Minimal Base Images
Section titled “Minimal Base Images”Minimal images remove unnecessary software.
Example:
Traditional Image
↓
500 Packages
↓
Larger Attack Surface
-------------------------
Minimal Image
↓
80 Packages
↓
Smaller Attack SurfaceFewer packages generally mean fewer vulnerabilities.
Distroless Images
Section titled “Distroless Images”Distroless images contain only:
- Application runtime
- Required libraries
They do not include:
- Shells
- Package managers
- Debugging tools
Benefits:
- Very small attack surface
- Fewer vulnerabilities
- Reduced exploitation opportunities
These images are well suited for production workloads where interactive debugging is not required.
Risks of Community Images
Section titled “Risks of Community Images”Public community images may contain:
- Malware
- Backdoors
- Cryptocurrency miners
- Unpatched software
- Unknown maintainers
- Weak security practices
Enterprise organizations should avoid deploying unverified community images into production.
Outdated Base Images
Section titled “Outdated Base Images”Old images often contain:
- Known CVEs
- Unsupported software
- Expired packages
- End-of-life operating systems
Example:
Old Base Image
↓
Unpatched Vulnerability
↓
Container CompromiseRegular updates are essential.
Base Image Lifecycle
Section titled “Base Image Lifecycle”Vendor
↓
Security Updates
↓
Enterprise Validation
↓
Image Scan
↓
Approved Base Image
↓
Application Image
↓
Amazon EKSEvery update should be validated before production use.
Base Image Hardening
Section titled “Base Image Hardening”Enterprise base images commonly include:
- Removed unnecessary packages
- Updated security patches
- Secure default configuration
- Non-root user support
- Security monitoring agents
- Approved certificates
- Logging configuration
These controls improve consistency across workloads.
Image Inheritance
Section titled “Image Inheritance”Every application inherits from its base image.
Base Image
↓
Application A
↓
Application B
↓
Application C
↓
Production ContainersA vulnerability in the base image affects every dependent application.
Base Image Security in Amazon EKS
Section titled “Base Image Security in Amazon EKS”Developer
↓
Enterprise Base Image
↓
Dockerfile
↓
CI/CD Pipeline
↓
Image Scan
↓
Amazon ECR
↓
Amazon EKSOnly approved base images should be allowed in production environments.
Enterprise Example
Section titled “Enterprise Example”A global insurance company supports more than 12,000 containers across multiple Amazon EKS clusters.
Its security policy requires:
- Only approved enterprise base images
- Weekly vulnerability scanning
- Monthly base image updates
- Image signing
- Private Amazon ECR repositories
- Automatic rebuilds when critical vulnerabilities are identified
When a new OpenSSL vulnerability is disclosed, the platform team updates the enterprise base image.
All application images are automatically rebuilt using the patched base image and redeployed after security validation.
This centralized approach significantly reduces remediation time.
Common Base Image Risks
Section titled “Common Base Image Risks”Cloud Security Engineers frequently identify:
- Outdated operating systems
- End-of-life distributions
- Public unverified images
- Excessive software packages
- Missing security patches
- Images running as root
- Embedded credentials
- Weak image governance
- Missing image signing
- Inconsistent image versions
These issues increase software supply chain risk.
Enterprise Monitoring
Section titled “Enterprise Monitoring”Security teams should continuously monitor:
- Base image versions
- New security advisories
- Vulnerability scan results
- Image age
- End-of-life operating systems
- Registry uploads
- Image signing validation
- Unauthorized image sources
- CI/CD build events
- Deployment compliance
Continuous monitoring helps ensure every workload uses approved and supported base images.
Enterprise Implementation Strategy
Section titled “Enterprise Implementation Strategy”A recommended roadmap:
Step 1
↓
Approve Base Images
↓
Step 2
↓
Build Enterprise Images
↓
Step 3
↓
Remove Unnecessary Packages
↓
Step 4
↓
Apply Security Hardening
↓
Step 5
↓
Scan Images
↓
Step 6
↓
Digitally Sign Images
↓
Step 7
↓
Store in Amazon ECR
↓
Step 8
↓
Deploy to Amazon EKS
↓
Step 9
↓
Continuously Monitor & UpdateThis approach standardizes image security across the organization.
Best Practices
Section titled “Best Practices”As a Kubernetes Security Engineer:
- Use only approved and trusted base images.
- Prefer minimal or distroless images for production workloads.
- Regularly update base images with the latest security patches.
- Remove unnecessary software and packages.
- Avoid unverified public community images.
- Scan every base image for vulnerabilities.
- Digitally sign approved images.
- Store production images in private registries such as Amazon ECR.
- Automate base image validation within CI/CD pipelines.
- Continuously monitor for newly disclosed vulnerabilities.
A secure base image reduces risk before application code is even added.
Real-World Scenario
Section titled “Real-World Scenario”A financial technology company builds hundreds of container images every week.
A newly disclosed vulnerability affects the version of OpenSSL included in the organization’s enterprise base image.
Because every application inherits from that base image:
- The platform team patches the enterprise base image.
- A new version is scanned and digitally signed.
- CI/CD automatically rebuilds all dependent application images.
- Updated images are pushed to Amazon ECR.
- Amazon EKS rolling updates deploy the patched containers.
Within hours, hundreds of applications are protected without requiring individual development teams to manually patch their Dockerfiles.
Key Takeaways
Section titled “Key Takeaways”After completing this lesson, you should understand:
- What a base image is
- Why base image selection affects container security
- Different categories of base images
- Risks of outdated and untrusted images
- Enterprise base image governance
- Amazon EKS image management
- Best practices for secure base image selection
Base Image Security forms the foundation of container security. By selecting trusted, minimal and regularly updated base images, organizations reduce inherited vulnerabilities, strengthen their software supply chain and build more secure Kubernetes workloads on Amazon EKS.
Knowledge Check
Section titled “Knowledge Check”Question 1
Section titled “Question 1”What is a base image?
- A. A running Kubernetes Pod
- B. The foundational image on which a container image is built
- C. A Kubernetes Deployment
- D. A Docker container
Answer: B
Question 2
Section titled “Question 2”Why are minimal base images recommended?
- A. They consume more CPU resources.
- B. They contain fewer packages, reducing the attack surface.
- C. They automatically encrypt application data.
- D. They replace runtime security controls.
Answer: B
Question 3
Section titled “Question 3”Which type of image typically has the smallest attack surface?
- A. Full desktop operating system image
- B. Distroless image
- C. Community image with debugging tools
- D. Development image
Answer: B
Question 4
Section titled “Question 4”Why should organizations avoid deploying unverified public community images into production?
- A. They are always larger than official images.
- B. They may contain malware, outdated software or untrusted modifications.
- C. They cannot run on Amazon EKS.
- D. They do not support Docker.
Answer: B
Question 5
Section titled “Question 5”Which combination represents enterprise best practice?
- A. Use approved minimal base images, regularly update and scan them, digitally sign images and store them in Amazon ECR.
- B. Build production workloads from random public images using the
latesttag. - C. Never update base images after deployment.
- D. Install every available package into the base image.
Answer: A
What’s Next?
Section titled “What’s Next?”In the next lesson, you will learn about Image Vulnerability Scanning, exploring how enterprise organizations identify known vulnerabilities (CVEs), prioritize remediation, automate image scanning within CI/CD pipelines and continuously protect Amazon EKS workloads from newly discovered security threats.
➡️ Next Lesson: Lesson 05 — Image Vulnerability Scanning