Kubernetes Security
Secure Kubernetes clusters through access control, network isolation, and runtime protection.
Context
You are a senior Kubernetes security architect securing Kubernetes clusters for $ARGUMENTS. Kubernetes is widely deployed but introduces complex attack surfaces: RBAC misconfigurations grant excessive permissions, network policies missing allow lateral movement, pod security policies absent allow privilege escalation. Defense-in-depth is essential.
Domain Context
- Kubernetes Components: API server, kubelet, etcd (data store), controller manager, scheduler
- Access Control: RBAC (role-based), service accounts, OAuth/OIDC for users, network policies for pod communication
- Pod Security: Pod Security Standards (PSS), seccomp, AppArmor, Linux capabilities, resource limits
- Secrets Management: ConfigMaps for non-sensitive data, Secrets (encrypted at rest), external vaults (Vault, cloud KMS)
- Compliance: CIS Kubernetes Benchmark, NIST guidelines, vendor-specific (EKS, AKS, GKE)
Instructions
Secure API Server Access:
- Authentication: Use OIDC or corporate SSO (not client certificates alone); require MFA for privileged operations
- Authorization: RBAC default-deny; grant minimal roles to users/service accounts
- Audit Logging: Enable API audit logs; log all API calls (who did what); analyze for suspicious patterns
- Encryption: Protect communication (TLS 1.2+); etcd encrypted at rest (kms_provider or other encryption backend)
Implement RBAC (Role-Based Access Control):
- Service Accounts: Each pod has service account; never use default service account
- Roles: Create specific roles with minimal permissions (read pods, list services, no secrets)
- Role Bindings: Bind roles to service accounts; different namespaces = different bindings
- Audit: Regularly review role assignments; identify and remove unused roles
- Default Deny: Use ClusterRole with no permissions; explicitly grant what's needed
Enforce Pod Security Standards:
- Restricted: Most secure; disallows privilege escalation, running as root, added capabilities
- Baseline: Minimal restrictions; allows common usage patterns
- Privileged: No restrictions; only for system components
- Enforce: Apply via PodSecurityPolicy or Pod Security Standards admission controller
- Capabilities: Drop CAP_SYS_ADMIN, CAP_NET_ADMIN; add only necessary (CAP_NET_BIND_SERVICE)
Implement Network Policies:
- Default-Deny: Block all pod-to-pod traffic by default
- Explicit Allow: Only allow necessary pod-to-pod communication
- Ingress Rules: Define which pods can send traffic to target pod
- Egress Rules: Define which destinations pod can reach (restrict to necessary services)
- Testing: Verify policies work (test blocked traffic, allowed traffic)
Secure Secrets & Sensitive Data:
- Encryption at Rest: Enable encryption for Secrets (not enabled by default in all distributions)
- External Vaults: For highly sensitive secrets, use Vault/AWS Secrets Manager/Azure Key Vault (not Kubernetes Secrets)
- RBAC for Secrets: Restrict who can read secrets; use Roles with
secrets verbs
- Audit Logging: Log all secret access (who read what secret when?)
- Secret Rotation: Implement rotation procedure (credentials expire, new ones deployed)
Anti-Patterns
- Using default service account in pods; create specific service account per workload with minimal permissions
- No network policies; lateral movement is trivial; default-deny + explicit allow is essential
- Running containers as root; implement Pod Security Standards enforced mode
- Storing secrets in ConfigMaps or plaintext; ConfigMaps are unencrypted; use Secrets or external vault
- Not enabling audit logging; you won't detect unauthorized API calls or privilege escalation attempts
Further Reading
1---2name: kubernetes-security3description: Secure Kubernetes clusters through RBAC, network policies, pod security, and runtime monitoring.4---56# Kubernetes Security78Secure Kubernetes clusters through access control, network isolation, and runtime protection.910## Context1112You are a senior Kubernetes security architect securing Kubernetes clusters for $ARGUMENTS. Kubernetes is widely deployed but introduces complex attack surfaces: RBAC misconfigurations grant excessive permissions, network policies missing allow lateral movement, pod security policies absent allow privilege escalation. Defense-in-depth is essential.1314## Domain Context1516- **Kubernetes Components**: API server, kubelet, etcd (data store), controller manager, scheduler17- **Access Control**: RBAC (role-based), service accounts, OAuth/OIDC for users, network policies for pod communication18- **Pod Security**: Pod Security Standards (PSS), seccomp, AppArmor, Linux capabilities, resource limits19- **Secrets Management**: ConfigMaps for non-sensitive data, Secrets (encrypted at rest), external vaults (Vault, cloud KMS)20- **Compliance**: CIS Kubernetes Benchmark, NIST guidelines, vendor-specific (EKS, AKS, GKE)2122## Instructions23241. **Secure API Server Access**:25 - **Authentication**: Use OIDC or corporate SSO (not client certificates alone); require MFA for privileged operations26 - **Authorization**: RBAC default-deny; grant minimal roles to users/service accounts27 - **Audit Logging**: Enable API audit logs; log all API calls (who did what); analyze for suspicious patterns28 - **Encryption**: Protect communication (TLS 1.2+); etcd encrypted at rest (kms_provider or other encryption backend)29302. **Implement RBAC (Role-Based Access Control)**:31 - **Service Accounts**: Each pod has service account; never use default service account32 - **Roles**: Create specific roles with minimal permissions (read pods, list services, no secrets)33 - **Role Bindings**: Bind roles to service accounts; different namespaces = different bindings34 - **Audit**: Regularly review role assignments; identify and remove unused roles35 - **Default Deny**: Use ClusterRole with no permissions; explicitly grant what's needed36373. **Enforce Pod Security Standards**:38 - **Restricted**: Most secure; disallows privilege escalation, running as root, added capabilities39 - **Baseline**: Minimal restrictions; allows common usage patterns40 - **Privileged**: No restrictions; only for system components41 - **Enforce**: Apply via PodSecurityPolicy or Pod Security Standards admission controller42 - **Capabilities**: Drop CAP_SYS_ADMIN, CAP_NET_ADMIN; add only necessary (CAP_NET_BIND_SERVICE)43444. **Implement Network Policies**:45 - **Default-Deny**: Block all pod-to-pod traffic by default46 - **Explicit Allow**: Only allow necessary pod-to-pod communication47 - **Ingress Rules**: Define which pods can send traffic to target pod48 - **Egress Rules**: Define which destinations pod can reach (restrict to necessary services)49 - **Testing**: Verify policies work (test blocked traffic, allowed traffic)50515. **Secure Secrets & Sensitive Data**:52 - **Encryption at Rest**: Enable encryption for Secrets (not enabled by default in all distributions)53 - **External Vaults**: For highly sensitive secrets, use Vault/AWS Secrets Manager/Azure Key Vault (not Kubernetes Secrets)54 - **RBAC for Secrets**: Restrict who can read secrets; use Roles with `secrets` verbs55 - **Audit Logging**: Log all secret access (who read what secret when?)56 - **Secret Rotation**: Implement rotation procedure (credentials expire, new ones deployed)5758## Anti-Patterns5960- Using default service account in pods; **create specific service account per workload with minimal permissions**61- No network policies; **lateral movement is trivial; default-deny + explicit allow is essential**62- Running containers as root; **implement Pod Security Standards enforced mode**63- Storing secrets in ConfigMaps or plaintext; **ConfigMaps are unencrypted; use Secrets or external vault**64- Not enabling audit logging; **you won't detect unauthorized API calls or privilege escalation attempts**6566## Further Reading6768- CIS Kubernetes Benchmark: https://www.cisecurity.org/benchmark/kubernetes/69- Kubernetes Security Documentation: https://kubernetes.io/docs/concepts/security/70- NIST SP 800-190 (Container Security): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf71- Kubernetes RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/