Cloud Notes
Comprehensive guide to container security covering image scanning, runtime security, Kubernetes security contexts, network policies, and best practices.
Container security encompasses protecting containerized applications throughout their lifecycle — from image building to runtime. As containers become the standard deployment unit in cloud-native environments, understanding security at every layer is essential.
Container Security Layers
| Layer 5: RUNTIME SECURITY | ||
|---|---|---|
| • Process monitoring, behavior detection | ||
| • Falco, Sysdig, Aqua Security | ||
| Layer 4: NETWORK SECURITY | ||
| • Network Policies, Service Mesh (mTLS) | ||
| • Ingress controls, micro-segmentation | ||
| Layer 3: ORCHESTRATION SECURITY (Kubernetes) | ||
| • RBAC, Pod Security Standards, Admission Control | ||
| • Secret management, resource quotas | ||
| Layer 2: IMAGE SECURITY | ||
| • Vulnerability scanning, image signing | ||
| • Minimal base images, no secrets in images | ||
| Layer 1: HOST SECURITY | ||
| • OS hardening, kernel security, SELinux | ||
| • Container runtime updates, CIS benchmarks |
Image Security
# Scan images for vulnerabilities
# Using Trivy (free, popular)
trivy image myapp:latest
trivy image --severity HIGH,CRITICAL myapp:latest
# Using Docker Scout
docker scout cves myapp:latest
# Using Snyk
snyk container test myapp:latest
# Sign images with cosign
cosign sign --key cosign.key myregistry.com/myapp:v1.0
cosign verify --key cosign.pub myregistry.com/myapp:v1.0Secure Dockerfile
Kubernetes Security
Pod Security Context
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: myapp:v1.0
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}Network Policies
# Deny all ingress by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-binding
namespace: development
subjects:
- kind: User
name: developer@company.com
roleRef:
kind: Role
name: developer-role
apiGroup: rbac.authorization.k8s.ioContainer Security Best Practices
| Category | Best Practice |
|---|---|
| Images | Use minimal base images (distroless, alpine) |
| Images | Scan for vulnerabilities in CI/CD pipeline |
| Images | Never include secrets or credentials |
| Runtime | Run as non-root user |
| Runtime | Use read-only filesystem |
| Runtime | Drop all capabilities, add only needed |
| Network | Default deny all, whitelist allowed |
| Orchestration | Enable RBAC, principle of least privilege |
| Secrets | Use external secret managers (Vault, AWS SM) |
| Monitoring | Runtime threat detection (Falco, Sysdig) |
Interview Questions
- What are the main security concerns with containers?
Vulnerable base images, running as root, excessive privileges, exposed secrets, unrestricted network access, compromised supply chain (untrusted images), kernel exploits (shared kernel), and insufficient runtime monitoring.
- How do you secure a Docker image?
Use minimal base images, scan for vulnerabilities, don't include secrets, use multi-stage builds, run as non-root user, sign images, use specific tags (not :latest), and implement image policies that prevent deploying unsigned or vulnerable images.
- Explain Kubernetes Network Policies.
Network Policies control pod-to-pod traffic using label selectors. By default, all pods can communicate. Policies specify which ingress/egress is allowed. Best practice: default deny all, then whitelist specific allowed communication paths (zero-trust networking).
- What is the principle of least privilege in container security?
Give containers only the permissions they absolutely need: non-root user, dropped capabilities, read-only filesystem, restricted network access, limited RBAC, specific resource quotas. This minimizes the blast radius if a container is compromised.
- How do you manage secrets securely in Kubernetes?
Use external secret managers (HashiCorp Vault, AWS Secrets Manager), Kubernetes External Secrets Operator, or sealed-secrets. Avoid committing secrets to git, rotate regularly, encrypt etcd at rest, and limit secret access via RBAC to specific service accounts.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Container Security — Cloud Computing.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Cloud Computing topic.
Search Terms
cloud-computing, cloud computing, cloud, computing, containers, and, orchestration, container
Related Cloud Computing Topics