Container Hardening: ডকার এবং কুবারনেটিস পরিবেশের নিরাপত্তা শক্তিশালী করার গাইড!
Docker ও Kubernetes container hardening-এর সর্বোত্তম অনুশীলন, CIS Benchmark এবং production-ready security configuration।
Container প্রযুক্তি আধুনিক software delivery-কে আমূল পরিবর্তন করে দিয়েছে। কিন্তু "It works on my machine" থেকে "It works in production" পর্যন্ত পথে নিরাপত্তা প্রায়শই overlook হয়ে যায়। CNCF-এর ২০২৩ Cloud Native Security Report অনুসারে ৬০ শতাংশ-এর বেশি প্রতিষ্ঠান গত বছরে container-related security incident face করেছে। বেশিরভাগ ক্ষেত্রেই attack ছিল avoidable—সঠিক hardening practice থাকলে। Container hardening মানে কনটেইনার এবং orchestration platform-কে এমনভাবে কনফিগার করা যাতে attack surface ন্যূনতম থাকে এবং কোনো breach হলেও impact সীমিত থাকে। আজকের আলোচনায় আমরা Docker এবং Kubernetes hardening-এর comprehensive guide দেখবো।
Container Hardening কেন গুরুত্বপূর্ণ
Container default configuration প্রায়ই production-grade security-র জন্য পর্যাপ্ত নয়। Docker ও Kubernetes-এর default setting developer convenience-এর জন্য optimized, security-র জন্য নয়। উদাহরণস্বরূপ:
- Container by default root user-এ চলে
- ServiceAccount token automatically mount হয়
- Network policy ডিফল্টভাবে নেই—pod-to-pod traffic unrestricted
- API server অনেক time anonymous access allow করে
CIS Docker Benchmark ও CIS Kubernetes Benchmark এই default-গুলোকে nilai দেয় না। Industry standard হিসেবে এই benchmark-গুলো follow করলে major vulnerability avoid করা যায়।
Hardening-এর Layered Approach
Container hardening একটি multi-layer process:
- Image Layer: Base image, dependency, Dockerfile
- Container Runtime Layer: Docker daemon, containerd configuration
- Host Layer: Kernel, OS hardening
- Orchestration Layer: Kubernetes API server, kubelet
- Network Layer: Service mesh, network policy
- Application Layer: Runtime configuration, secrets
প্রতিটি layer-এ আলাদা hardening practice আছে।
Image Hardening
Container security শুরু হয় image থেকে।
Minimal Base Image: Ubuntu বা CentOS-এর পরিবর্তে Alpine, Distroless, বা scratch image use করুন। কম surface area মানে কম vulnerability।
# Bad
FROM ubuntu:latest
# Good
FROM gcr.io/distroless/static-debian12
Multi-stage Build: Build dependency final image-এ পাঠাবেন না।
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp
FROM gcr.io/distroless/static
COPY --from=builder /app/myapp /
USER 1000
ENTRYPOINT ["/myapp"]
Non-root User: Always create and use non-root user।
RUN addgroup -S app && adduser -S app -G app
USER app
Specific Version Tag: latest tag use করবেন না। Specific version দিয়ে reproducible build।
Image Signing: Cosign বা Notary দিয়ে image sign করুন। Sigstore ecosystem use করুন।
Vulnerability Scanning: CI/CD pipeline-এ Trivy, Snyk, Grype দিয়ে scan করুন।
No Secrets in Image: ENV variable বা ARG-এ secret pass করবেন না। Runtime-এ inject করুন।
Minimize Layers: Fewer layer মানে faster build, smaller image।
Read-only Root Filesystem: Application-এর জন্য necessary writable directory tmpfs-এ mount।
Dockerfile Best Practices
# Specific version
FROM node:20.10-alpine
# Create non-root user
RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
# Working directory
WORKDIR /app
# Copy dependency files first (cache optimization)
COPY package*.json ./
# Install only production dependencies
RUN npm ci --only=production && npm cache clean --force
# Copy application code
COPY --chown=nextjs:nodejs . .
# Switch to non-root user
USER nextjs
# Expose specific port
EXPOSE 3000
# Healthcheck
HEALTHCHECK --interval=30s --timeout=3s \
CMD wget --quiet --tries=1 --spider http://localhost:3000/health || exit 1
# Use exec form for proper signal handling
CMD ["node", "server.js"]
Container Runtime Hardening
Container চালানোর সময় বিভিন্ন security flag use করুন।
docker run \
--read-only \
--tmpfs /tmp:rw,size=64m \
--cap-drop=ALL \
--cap-add=NET_BIND_SERVICE \
--security-opt no-new-privileges \
--security-opt seccomp=default.json \
--security-opt apparmor=docker-default \
--memory=512m \
--cpus=1 \
--pids-limit=100 \
--user=1000:1000 \
--network=mynet \
--restart=on-failure:3 \
myapp:1.0
Key Flags Explained:
--read-only: Root filesystem read-only--cap-drop=ALL: All capability drop, তারপর specific add--security-opt no-new-privileges: SUID binary প্রভাব নেই--memory,--cpus,--pids-limit: Resource limit (DoS prevention)--user: Non-root UID--network: Custom network, default bridge না
Docker Daemon Hardening
Docker daemon-এর security configuration /etc/docker/daemon.json-এ:
{
"icc": false,
"userns-remap": "default",
"no-new-privileges": true,
"live-restore": true,
"userland-proxy": false,
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
},
"default-ulimits": {
"nofile": {
"Name": "nofile",
"Hard": 65535,
"Soft": 65535
}
},
"seccomp-profile": "/etc/docker/seccomp-default.json"
}
icc: false: Inter-container communication disabled by defaultuserns-remap: User namespace—container root host-এ unprivilegedlive-restore: Daemon restart-এ container running থাকে
Kubernetes Hardening
Kubernetes hardening Docker-এর চেয়ে অনেক বেশি জটিল।
API Server Security
- Anonymous auth disable:
--anonymous-auth=false - AlwaysAllow authorization বন্ধ, RBAC use করুন
- Audit logging enable:
--audit-log-path=/var/log/k8s/audit.log - TLS minimum version 1.2
- Encryption at rest enable for secrets
kubelet Security
--anonymous-auth=false--authorization-mode=Webhook--read-only-port=0(disable read-only API)--protect-kernel-defaults=true
Pod Security Standards (PSS)
Kubernetes 1.25+ এ Pod Security Admission আছে তিনটি profile-এর সাথে:
Privileged: No restriction Baseline: Common privilege escalation block Restricted: Hardened pod security best practice
Namespace-এ enforce করুন:
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
Secure Pod Specification
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
automountServiceAccountToken: false
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: myapp:1.0@sha256:abc123...
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
resources:
limits:
memory: "256Mi"
cpu: "500m"
requests:
memory: "128Mi"
cpu: "250m"
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
Network Policies
ডিফল্টভাবে Kubernetes-এ all pod can talk to all pod। Network Policy দিয়ে এটি restrict করুন।
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
তারপর specific policy দিয়ে allow করুন।
RBAC Best Practices
- Default ServiceAccount use করবেন না
- প্রতিটি workload-এর জন্য dedicated ServiceAccount
- Least privilege role
cluster-adminকেবল emergency-তে- Regular RBAC audit (kubectl-who-can, rbac-lookup)
Secrets Management
- Kubernetes Secret base64 encoded, encrypted না by default
- etcd encryption at rest enable করুন
- External secret manager use: Vault, AWS Secrets Manager, Azure Key Vault
- Sealed Secrets, External Secrets Operator
- Secret never log করুন
CIS Benchmark অনুসরণ
CIS Docker Benchmark এবং CIS Kubernetes Benchmark industry-standard hardening guide।
Docker Benchmark Highlights:
- Section 1: Host Configuration (Docker user namespace, separate partition)
- Section 2: Docker Daemon Configuration
- Section 3: Docker Daemon Configuration Files
- Section 4: Container Images & Build File
- Section 5: Container Runtime
- Section 6: Docker Security Operations
- Section 7: Docker Swarm Configuration
Tools to Check:
- docker-bench-security: Automated CIS Docker Benchmark checker
- kube-bench: CIS Kubernetes Benchmark
- kubescape: Multi-framework Kubernetes security posture
# docker-bench-security
docker run --rm --net host --pid host --userns host --cap-add audit_control \
-v /etc:/etc:ro -v /usr/bin/containerd:/usr/bin/containerd:ro \
-v /var/lib:/var/lib:ro -v /var/run/docker.sock:/var/run/docker.sock:ro \
--label docker_bench_security \
docker/docker-bench-security
Service Mesh ও Zero Trust
Production-grade Kubernetes deployment-এ service mesh integrate করুন।
Istio/Linkerd benefits:
- mTLS automatic
- Fine-grained authorization policy
- Observability
- Traffic encryption
Zero Trust Principles:
- Never trust, always verify
- Mutual authentication
- Continuous verification
- Microsegmentation
Runtime Security ও Monitoring
Configuration হার্ডেনিং যথেষ্ট নয়—runtime monitoring অপরিহার্য।
Falco: Cloud-native runtime security
- rule: Terminal shell in container
desc: A shell was used as the entrypoint/exec point into a container
condition: container.id != host and proc.name = bash
output: Shell spawned in container (user=%user.name container_id=%container.id)
priority: WARNING
Tetragon (eBPF): Deep observability Kubescape: Continuous security posture Sysdig Secure, Prisma Cloud, Aqua: Commercial CWPP
CI/CD Pipeline Security
Image Scanning:
- Trivy in CI
- Block on critical vulnerability
- SBOM generation (Syft)
Policy as Code:
- OPA Gatekeeper
- Kyverno
- Validate manifest before apply
GitOps:
- ArgoCD, FluxCD
- Declarative, version-controlled
- Drift detection
প্রতিরোধ ও সর্বোত্তম অনুশীলন
Container hardening checklist:
- Minimal base image (Alpine, Distroless)
- Non-root user inside container
- Read-only root filesystem
- All capability drop, minimum add
- No privileged container
- No Docker socket mount
- Resource limit (memory, CPU, PID)
- Seccomp default profile
- AppArmor/SELinux enabled
- Image vulnerability scanning in CI/CD
- Image signing & verification
- Pod Security Standards: Restricted
- Network Policy: default deny
- RBAC least privilege
- ServiceAccount token: automount disabled
- Secret encryption at rest
- External secret manager
- etcd encryption enabled
- Audit logging enabled
- kubelet hardened
- mTLS via service mesh
- Runtime security (Falco)
- Regular CIS Benchmark assessment
- Patch kernel, runtime, k8s timely
- Disaster recovery & backup
- Security training for DevOps team
Container Hardening আধুনিক DevSecOps culture-এর একটি অপরিহার্য অঙ্গ। Docker ও Kubernetes-এর default configuration কখনোই production-grade নিরাপত্তার জন্য পর্যাপ্ত নয়—এটি একটি foundation, যার উপর আপনাকে নির্মাণ করতে হবে। Image থেকে runtime, host থেকে orchestration—প্রতিটি layer-এ deliberate hardening decision নিতে হবে। CIS Benchmark-এর মতো প্রমাণিত standard follow করুন, automated tool দিয়ে continuous compliance বজায় রাখুন, এবং security-কে CI/CD pipeline-এর প্রতিটি stage-এ integrate করুন। মনে রাখবেন, container security shared responsibility। Developer image build করেন, DevOps deploy করেন, Security team monitor করেন—সবার coordination ছাড়া hardening অসম্ভব। আজই আপনার container infrastructure-এ এই hardening practice apply করা শুরু করুন এবং ধীরে ধীরে আপনার security posture পরিবর্তিত হতে দেখুন।
আপনার জ্ঞান যাচাই করতে প্রস্তুত? আজই HackCert-এ Container Hardening MCQ Quiz-টি দিন!

