Key Takeaways

  • RBAC is fundamental—implement least privilege access.
  • Never run containers as root.
  • Network policies control pod-to-pod traffic.
  • Use Pod Security Standards/Admission.
  • Secrets should be encrypted at rest.
  • Scan images for vulnerabilities before deployment.

1. Kubernetes Security Overview

Kubernetes orchestrates containers at scale, but its complexity introduces security challenges. The "4 C's" of cloud-native security apply: Cloud, Cluster, Container, and Code. Each layer requires attention; security at one layer doesn't compensate for weakness at another.

Common Kubernetes security issues include misconfigured RBAC, containers running as root, exposed dashboards, secrets in plain text, and lack of network policies. These are preventable with proper configuration.

The 4 C's of Cloud-Native Security

Cloud: Secure the underlying infrastructure (AWS, Azure, GCP)
Cluster: Kubernetes control plane and node security
Container: Image and runtime security
Code: Application-level security

2. RBAC & Authentication

2.1 RBAC Fundamentals

Role-Based Access Control defines who can do what in the cluster. Use Roles/ClusterRoles to define permissions and RoleBindings/ClusterRoleBindings to assign them.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

2.2 RBAC Best Practices

3. Pod Security

3.1 Pod Security Standards

Kubernetes defines three security profiles: Privileged (unrestricted), Baseline (minimally restrictive), and Restricted (heavily restricted). Apply these via Pod Security Admission.

# Label namespace for restricted policy
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted

3.2 Security Context

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
Dangerous Settings

privileged: true - Full host access
hostNetwork: true - Access host network namespace
hostPID: true - See host processes
capabilities: SYS_ADMIN - Near-root privileges
Avoid these unless absolutely necessary and understood.

4. Network Policies

By default, all pods can communicate with all other pods. Network Policies implement micro-segmentation.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

5. Secrets Management

5.1 Basic Secret Creation

# Create secret
kubectl create secret generic db-creds \
  --from-literal=username=admin \
  --from-literal=password=supersecret

# Use in pod
env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-creds
      key: password

5.2 Secrets Best Practices

6. Image Security

# Scan with Trivy
trivy image myapp:1.0

# Use image digest instead of tag
image: myapp@sha256:abc123...

7. Monitoring & Auditing

7.1 Kubernetes Audit Logs

# Audit policy example
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: RequestResponse
  resources:
  - group: ""
    resources: ["pods/exec", "pods/attach"]

7.2 Runtime Security

CIS Kubernetes Benchmark

Use the CIS Kubernetes Benchmark as a security baseline. Tools like kube-bench can automatically check your cluster against these standards and identify misconfigurations.

8. Frequently Asked Questions

Should I use managed Kubernetes (EKS, GKE, AKS)?
For most organizations, yes. Managed services handle control plane security and updates. You're still responsible for workload security, but the attack surface is reduced. Self-managed Kubernetes requires significant expertise to secure properly.
What about service mesh security?
Service meshes like Istio add mTLS between pods, fine-grained access control, and observability. They add complexity but provide strong security for environments requiring zero-trust networking between services.

Conclusion

Kubernetes security requires attention across multiple layers: RBAC for access control, Pod Security Standards for container hardening, Network Policies for traffic control, and proper secrets management. Use security scanning, enable auditing, and regularly assess your configuration against benchmarks like CIS.

Continue Learning:
Docker Security Cloud Security