Container Security Basics
Security is a shared responsibility across the container lifecycle. The KCNA tests your understanding of security concepts at the image, runtime, and cluster levels.
The 4C’s of Cloud Native Security
┌──────────────────────────────┐
│ Code │ ← Application security
│ ┌────────────────────────┐ │
│ │ Container │ │ ← Image & runtime security
│ │ ┌──────────────────┐ │ │
│ │ │ Cluster │ │ │ ← Kubernetes security
│ │ │ ┌────────────┐ │ │ │
│ │ │ │ Cloud │ │ │ │ ← Infrastructure security
│ │ │ └────────────┘ │ │ │
│ │ └──────────────────┘ │ │
│ └────────────────────────┘ │
└──────────────────────────────┘
Each layer must be secured — security at one layer can’t compensate for weaknesses at another.
| Layer |
What It Covers |
| Cloud |
Infrastructure security (IAM, network ACLs, encryption at rest) |
| Cluster |
Kubernetes configuration (RBAC, network policies, admission control) |
| Container |
Image security, runtime security, security contexts |
| Code |
Application vulnerabilities, dependency scanning, secure coding |
Image Security
Best Practices
| Practice |
Why |
| Use minimal base images (Alpine, distroless) |
Fewer packages = fewer vulnerabilities |
Pin image versions (use nginx:1.25, not nginx:latest) |
Predictable, auditable deployments |
| Scan images for vulnerabilities |
Catch CVEs before deployment |
| Use trusted registries |
Docker Hub, ECR, GCR, Harbor |
| Don’t include secrets in images |
Use ConfigMaps/Secrets at runtime instead |
| Multi-stage builds |
Keep build tools out of production images |
| Tool |
What It Does |
Type |
| Trivy |
Scans images for CVEs |
Open-source (Aqua Security) |
| Snyk |
Scans images and code |
Commercial |
| Grype |
Vulnerability scanner for container images |
Open-source (Anchore) |
Runtime Security
Security Contexts
Security contexts define security settings for pods and containers:
| Setting |
What It Does |
runAsNonRoot: true |
Container must run as a non-root user |
readOnlyRootFilesystem: true |
Container filesystem is read-only |
allowPrivilegeEscalation: false |
Prevents gaining more privileges than the parent process |
capabilities.drop: ["ALL"] |
Removes all Linux capabilities |
Principle of Least Privilege
Always run containers with the minimum permissions required. Don’t run as root unless absolutely necessary.
Cluster Security
RBAC (Role-Based Access Control)
| Concept |
What It Does |
| Role |
Defines permissions within a namespace |
| ClusterRole |
Defines permissions cluster-wide |
| RoleBinding |
Grants a Role to a user/group/service account in a namespace |
| ClusterRoleBinding |
Grants a ClusterRole to a user/group/service account cluster-wide |
User → RoleBinding → Role → Permissions (get pods, create services, etc.)
Service Accounts
| Aspect |
Details |
| What they are |
Identities for pods (not humans) |
| Default behavior |
Every namespace gets a default service account |
| Best practice |
Create specific service accounts with minimal permissions per workload |
Admission Controllers
| Controller |
What It Does |
| Pod Security Admission |
Enforces pod security standards (restricted, baseline, privileged) |
| OPA/Gatekeeper |
Custom policy enforcement |
| Kyverno |
Kubernetes-native policy engine |
Network Security
| Mechanism |
What It Does |
| Network Policies |
Control pod-to-pod traffic (ingress/egress) |
| mTLS (Service Mesh) |
Encrypt all service-to-service communication |
| Ingress TLS |
Encrypt external traffic entering the cluster |
Supply Chain Security
| Concept |
What It Does |
| Image signing |
Verify that images haven’t been tampered with (cosign, Notary) |
| SBOM |
Software Bill of Materials — list all components in an image |
| Admission control |
Only allow verified/signed images to run |
Key Takeaways for the Exam
- The 4C’s of cloud native security: Cloud, Cluster, Container, Code
- Use minimal base images and scan for vulnerabilities (Trivy, Snyk)
- Pin image versions — never use
:latest in production
- Use security contexts: run as non-root, read-only filesystem, drop capabilities
- RBAC controls who can do what in a cluster (Role + RoleBinding)
- Service accounts are pod identities — each workload should have its own with minimal permissions
- Network Policies control pod-to-pod traffic
- Admission controllers enforce policies at deploy time
What’s Next?
Test your understanding of container orchestration with practice questions.
Orchestration Practice Questions →
