Kubernetes Security Best Practices: A Comprehensive Guide for 2024
Kubernetes has become the de facto standard for container orchestration, powering everything from startups to enterprise-scale applications. However, its distributed nature and complexity introduce unique security challenges that demand a proactive approach. This guide covers the essential security practices you need to implement to protect your Kubernetes clusters in 2024.
Understanding the Kubernetes Attack Surface
Before diving into specific practices, it's crucial to understand the components that need protection:
Get Our Weekly Cybersecurity Digest
Every Thursday: the threats that matter, what they mean for your business, and exactly what to do. Trusted by SMB owners across Australia.
No spam. No tracking. Unsubscribe anytime. Privacy
- Control Plane: API server, etcd, scheduler, controller manager
- Worker Nodes: Kubelet, kube-proxy, container runtime
- Network: Pod-to-pod communication, ingress/egress traffic
- Applications: Container images, secrets, workloads
- Data: Persistent volumes, configuration data
1. Implement Role-Based Access Control (RBAC)
RBAC is your first line of defense in Kubernetes security. It controls who can access what resources within your cluster.
Free Resource
Get the Free Cybersecurity Checklist
A practical, no-jargon security checklist for Australian businesses. Download free — no spam, unsubscribe anytime.
Send Me the Checklist →
Best Practices for RBAC:
Free Resource
Get the Free Cybersecurity Checklist
A practical, no-jargon security checklist for Australian businesses. Download free — no spam, unsubscribe anytime.
Send Me the Checklist →Principle of Least Privilege: Grant only the permissions users and services absolutely need.
# Example: Restricted role for developers
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: developer-role
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "create", "update"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "create", "update"]
Use Service Accounts Wisely: Create dedicated service accounts for each application rather than using the default service account.
Regular Audits: Periodically review RBAC configurations using tools like kubectl auth can-i or rback to identify overprivileged accounts.
Avoid Cluster-Admin for Daily Operations: The cluster-admin role should be reserved for infrastructure administrators only.
2. Secure the API Server
The Kubernetes API server is the central management entity—protecting it is paramount.
Key API Server Security Measures:
Enable Authentication: Use strong authentication mechanisms such as:
- OIDC (OpenID Connect) integration
- Client certificate authentication
- Webhook token authentication
Enable Authorization: Always enable RBAC and avoid using the AlwaysAllow authorization mode.
Enable Audit Logging: Configure comprehensive audit policies:
# Example audit policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
resources:
- group: ""
resources: ["pods", "secrets", "configmaps"]
- level: Metadata
resources:
- group: "rbac.authorization.k8s.io"
Restrict API Access: Use network policies and firewalls to limit API server access to authorized networks only.
3. Pod Security Standards
Kubernetes Pod Security Standards (replacing the deprecated Pod Security Policies) define three policy levels: Privileged, Baseline, and Restricted.
Implementing Pod Security:
Use the Restricted Profile where possible:
apiVersion: v1
kind: Namespace
metadata:
name: secure-namespace
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
Security Context Best Practices:
apiVersion: v1
kind: Pod
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
Key Pod Security Settings:
- Run containers as non-root users
- Use read-only root filesystems
- Drop unnecessary capabilities
- Disable privilege escalation
- Apply seccomp and AppArmor/SELinux profiles
4. Network Security
Kubernetes networks are flat by default—every pod can communicate with every other pod. This requires explicit security measures.
Implement Network Policies:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-allow-specific
spec:
podSelector:
matchLabels:
app: api-server
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
egress:
- to:
- podSelector:
matchLabels:
app: database
ports:
- protocol: TCP
port: 5432
Default Deny Strategy: Implement a default-deny network policy and explicitly allow required traffic.
Service Mesh for mTLS: Consider implementing a service mesh like Istio or Linkerd to enable mutual TLS between services automatically.
Ingress Security:
- Use TLS for all ingress traffic
- Implement rate limiting at the ingress controller
- Use Web Application Firewalls (WAF) where appropriate
- Keep ingress controllers updated
5. Container Image Security
Your security is only as strong as your container images.
Image Security Practices:
Use Minimal Base Images: Prefer distroless, Alpine, or scratch images over full OS distributions.
Scan Images for Vulnerabilities: Integrate scanning tools like Trivy, Clair, or Grype into your CI/CD pipeline.
Sign and Verify Images: Use Cosign (Sigstore) or Notary to sign images and enforce signature verification:
# Kyverno policy for image verification
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-image-signatures
spec:
validationFailureAction: enforce
rules:
- name: check-image-signature
match:
resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io/company/*"
attestors:
- entries:
- keys:
publicKeys: |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEXAMPLE
-----END PUBLIC KEY-----
Never Use 'latest' Tag: Always pin to specific image digests or semantic versions.
Private Registries: Use private container registries and enable authentication.
ISO 27001 SMB Starter Pack — $97
Everything you need to start your ISO 27001 journey: gap assessment templates, policy frameworks, and implementation roadmap built for Australian SMBs.
Get the Starter Pack →6. Secrets Management
Kubernetes Secrets require careful handling to prevent exposure.
Secrets Best Practices:
Use External Secrets Management: Integrate with external solutions like:
- HashiCorp Vault
- AWS Secrets Manager / Azure Key Vault / GCP Secret Manager
- External Secrets Operator
Enable Encryption at Rest: Configure encryption providers for etcd:
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
- configmaps
providers:
- aesgcm:
keys:
- name: key1
secret: <base64-encoded-key>
- identity: {}
Avoid Environment Variables for Secrets: Mount secrets as files rather than environment variables to prevent exposure through /proc.
Rotate Secrets Regularly: Implement automated secret rotation policies.
7. Runtime Security
Protecting running workloads is as important as securing the infrastructure.
Runtime Protection Measures:
Falco for Runtime Detection: Deploy Falco to detect anomalous behavior:
# Example Falco rule
- rule: Unauthorized K8s API Access
desc: Detect unauthorized access to Kubernetes API
condition: spawned_process and proc.name in (kubectl, helm) and not trusted_user
output: "Unauthorized K8s tool usage (user=%user.name command=%proc.cmdline)"
priority: WARNING
Container Sandboxing: Consider using gVisor or Kata Containers for additional isolation.
Resource Limits: Always set resource limits to prevent DoS attacks:
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "250m"
memory: "256Mi"
8. etcd Security
etcd stores all cluster state, including secrets. Compromising etcd means compromising the entire cluster.
etcd Protection:
- Enable TLS: Use TLS for all etcd communication
- Firewall etcd: Restrict etcd access to control plane nodes only
- Encrypt Backups: Always encrypt etcd backups
- Regular Backups: Implement automated backup procedures
- Monitor Access: Log and alert on all etcd access attempts
9. Supply Chain Security
Implement a defense-in-depth approach to supply chain security.
Supply Chain Measures:
SBOM (Software Bill of Materials): Generate and maintain SBOMs for all container images.
Policy as Code: Use OPA/Gatekeeper or Kyverno to enforce security policies:
# OPA Gatekeeper policy example
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: require-security-labels
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
labels:
- key: security-team
allowedRegex: "^[a-zA-Z0-9-]+$"
- key: data-classification
allowedRegex: "^(public|internal|confidential|restricted)$"
Admission Controllers: Enable and configure security-focused admission controllers:
- NodeRestriction
- ResourceQuota
- LimitRanger
- PodSecurity
10. Monitoring and Incident Response
Security without visibility is incomplete.
Monitoring Essentials:
Centralized Logging: Aggregate logs from all cluster components to a central SIEM.
Key Metrics to Monitor:
- Failed authentication attempts
- RBAC policy changes
- Privileged pod creations
- Network policy violations
- Image pull failures
- Resource quota exhaustion
Incident Response Planning:
- Document procedures for common scenarios
- Practice with tabletop exercises
- Maintain isolation capabilities (taints, cordons)
- Keep forensic tools ready
Security Checklist Summary
Use this checklist to evaluate your Kubernetes security posture:
- RBAC policies implemented with least privilege
- API server authentication and authorization enabled
- Audit logging configured and monitored
- Pod Security Standards applied
- Network policies implemented (default deny)
- Container images scanned and signed
- Secrets encrypted at rest and managed externally
- Runtime security monitoring deployed
- etcd secured with TLS and firewall rules
- Admission controllers enforcing policies
- Comprehensive monitoring and alerting in place
- Incident response procedures documented
Conclusion
Kubernetes security is not a one-time configuration but an ongoing process. As threats evolve and new vulnerabilities are discovered, your security practices must adapt. Implement these best practices as a foundation, then continuously improve through regular security assessments, penetration testing, and staying current with the latest security advisories.
Remember: security is everyone's responsibility. Enable your development teams with the tools and knowledge they need to build secure applications from the start.
For more information on Kubernetes security, visit the CNCF Security TAG and the official Kubernetes Security Documentation.
Work With Us
Ready to strengthen your security posture?
lilMONSTER assesses your risks, builds the tools, and stays with you after the engagement ends. No clipboard-and-leave consulting.
Book a Free Consultation →