Key Takeaways
- ✓67% of Kubernetes incidents are due to configuration errors (CNCF 2025)
- ✓Strict RBAC and Network Policies form the first line of defense
- ✓Secrets encryption and audit logging are essential in production
TL;DR: Kubernetes cluster security best practices rely on defense in depth: strict RBAC, Network Policies, Pod Security Standards, Secrets encryption, and audit logging. According to the CNCF 2025 report, 67% of Kubernetes incidents stem from security misconfigurations. This guide presents the 10 essential practices to protect your production clusters.
To master these skills in depth, discover the LFS460 Kubernetes Security Fundamentals training.
Why is Kubernetes Security with Network Policies and Pod Security Critical in 2026?
Kubernetes is not secure by default. When you deploy a vanilla cluster, all pods communicate with each other, containers run as root, and the API server accepts anonymous requests. This permissive configuration facilitates development but exposes your infrastructure to major risks.
According to Aqua Security (2025), 89% of analyzed clusters have at least one critical vulnerability. Lateral movement attacks, privilege escalation, and data exfiltration remain the primary threats.
Key takeaway: Securing a Kubernetes cluster requires a multi-layered approach. You must protect each level: infrastructure, cluster, workloads, and supply chain.
The good news: if you apply the practices described here, you will reduce your attack surface by 80% according to CIS benchmarks.
1. How to Configure RBAC to Limit Access to Your Cluster?
Role-Based Access Control (RBAC) is your first line of defense. You must enable and configure it correctly from day one.
Why it's essential: Without RBAC, any authenticated user gets administrator privileges. A developer could delete production namespaces or read sensitive Secrets.
How to implement it:
# Role limiting access to pods in a namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
# Binding associating the role to a group
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: production
subjects:
- kind: Group
name: developers
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Check your permissions with this command:
kubectl auth can-i --list --namespace=production --as=developer@company.com
Consult our detailed guide on RBAC Kubernetes: Understanding and Configuring Access Management to explore this topic further.
Key takeaway: Apply the principle of least privilege. You should never grant more rights than necessary. Regularly audit your ClusterRoleBindings.
2. Which Network Policies to Deploy to Isolate Your Workloads?
Network Policies segment network traffic between your pods. Without them, a compromised container can scan and attack all services in your cluster.
Why it's essential: By default, Kubernetes allows all pod-to-pod communication. An attacker exploiting an application vulnerability can pivot to your databases or internal services.
How to implement it:
# Default deny-all policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
# Allow only necessary traffic
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
According to Isovalent (2025), clusters using a default deny-all policy reduce network security incidents by 73%.
Test your policies:
kubectl run test-pod --image=busybox --rm -it -- wget -O- http://backend:8080
3. How to Enable Pod Security Standards for Your Namespaces?
Pod Security Standards (PSS) replaced PodSecurityPolicies since Kubernetes 1.25. You must configure them to prevent privileged container execution.
Why it's essential: A container in privileged mode can access the host system, mount arbitrary volumes, and compromise the entire node.
How to implement it:
# Apply the "restricted" profile to a namespace
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
The three available profiles:
- Privileged: no restrictions (avoid in production)
- Baseline: minimal restrictions blocking obvious escalations
- Restricted: maximum security, recommended for production
When deploying your applications, ensure they comply with these constraints:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
readOnlyRootFilesystem: true
Key takeaway: Enable the "restricted" profile on all your production namespaces. This will block 90% of privilege escalation vectors.
4. What Strategy to Adopt for Securing Your Kubernetes Secrets?
Kubernetes Secrets are not encrypted by default in etcd. You must enable at-rest encryption and consider an external solution.
Why it's essential: Unauthorized access to etcd exposes all your passwords, API tokens, and certificates in plain text.
How to implement it:
Create an encryption configuration:
# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: <base64-encoded-32-byte-key>
- identity: {}
Configure the API server:
kube-apiserver --encryption-provider-config=/etc/kubernetes/encryption-config.yaml
For critical environments, you should integrate an external secrets manager:
# Example with External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: db-secret
data:
- secretKey: password
remoteRef:
key: secret/data/production/database
property: password
Consult the Kubernetes Cluster Administration page to understand the overall security architecture.
5. How to Secure Your Container Image Supply Chain?
Supply chain security starts with your images. You must scan, sign, and restrict authorized registries.
Why it's essential: According to Sysdig (2025), 62% of public images contain critical vulnerabilities. A compromised image can inject malicious code into your cluster.
How to implement it:
Integrate scanning into your CI/CD:
# Scan with Trivy
trivy image --severity HIGH,CRITICAL --exit-code 1 myregistry/myapp:v1.2.0
Sign your images with Cosign:
cosign sign --key cosign.key myregistry/myapp:v1.2.0
Configure an Admission Controller to verify signatures:
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: image-signature-verification
webhooks:
- name: verify.images.example.com
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
Key takeaway: Never deploy images without scanning them. You must automatically block images containing critical CVEs.
6. How to Harden the API Server Configuration?
The API server is the central entry point to your cluster. You must configure it with the appropriate security flags.
Why it's essential: A misconfigured API server exposes your cluster to authentication attacks, anonymous requests, and information leaks.
How to implement it:
Check these critical configurations:
# Disable anonymous authentication
--anonymous-auth=false
# Enable audit logging
--audit-log-path=/var/log/kubernetes/audit.log
--audit-policy-file=/etc/kubernetes/audit-policy.yaml
# Restrict NodePorts
--service-node-port-range=30000-32767
# Enable RBAC
--authorization-mode=Node,RBAC
If you configure your cluster with kubeadm, consult our Complete Guide: Install a Multi-Node Kubernetes Cluster for security options.
7. Why Enable Audit Logging on Your Cluster?
Audit logging records all requests to the API server. You get complete traceability of actions in your cluster.
Why it's essential: Without audit logs, you cannot detect intrusions, investigate incidents, or prove compliance.
How to implement it:
# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Log secret modifications at RequestResponse level
- level: RequestResponse
resources:
- group: ""
resources: ["secrets"]
# Log admin actions at Metadata level
- level: Metadata
users: ["system:admin"]
# Minimal logging for other requests
- level: Metadata
omitStages:
- RequestReceived
Centralize your logs with Fluentd or Vector:
kubectl logs -n kube-system -l component=kube-apiserver --tail=100
To diagnose common issues, refer to Solve the 10 Most Common Kubernetes Cluster Problems.
8. Which Runtime Security Tools to Deploy in 2026?
Runtime security detects abnormal behaviors during execution. You must monitor syscalls, file access, and suspicious network connections.
Why it's essential: Zero-day vulnerabilities bypass static scanners. Only runtime detection can identify an active compromise.
How to implement it:
Deploy Falco for anomaly detection:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: falco
namespace: falco
spec:
selector:
matchLabels:
app: falco
template:
spec:
containers:
- name: falco
image: falcosecurity/falco:0.37.0
securityContext:
privileged: true
volumeMounts:
- name: proc
mountPath: /host/proc
readOnly: true
Example Falco rule detecting a shell in a container:
- rule: Shell spawned in container
desc: Detect shell execution in containers
condition: >
container.id != host and
proc.name in (bash, sh, zsh) and
spawned_process
output: "Shell spawned (user=%user.name container=%container.name)"
priority: WARNING
Key takeaway: Deploy Falco on all your production nodes. You will detect malicious behaviors in real-time.
9. How to Secure Your Worker Nodes?
Node security protects the underlying infrastructure. You must harden the OS, restrict SSH access, and isolate sensitive workloads.
Why it's essential: A compromised node gives access to all pods it hosts, mounted secrets, and potentially other nodes in the cluster.
How to implement it:
Apply CIS recommendations:
# Check kubelet permissions
chmod 600 /etc/kubernetes/kubelet.conf
chmod 644 /etc/kubernetes/pki/ca.crt
# Disable swap
swapoff -a
sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
# Configure system limits
cat >> /etc/sysctl.d/kubernetes.conf << EOF
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
kernel.panic = 10
EOF
For high-security environments, you should consider dedicated nodes with taints:
kubectl taint nodes secure-node-1 security=high:NoSchedule
kubectl label nodes secure-node-1 security-tier=high
Consult Kubernetes High Availability: Configure a Resilient Cluster to combine security and resilience.
10. How to Automate Security Audits with kube-bench?
Kube-bench automatically checks your cluster's compliance with CIS benchmarks. You must run it regularly.
How to implement it:
# Run kube-bench on a master node
kubectl run kube-bench --image=aquasec/kube-bench:v0.7.0 \
--restart=Never \
--overrides='{"spec":{"nodeName":"master-1"}}' \
-- master
# Retrieve the results
kubectl logs kube-bench
Example output:
[PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 644
[FAIL] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root
[WARN] 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644
Integrate kube-bench into your CI/CD pipeline to block non-compliant deployments.
Anti-Patterns to Absolutely Avoid
| Anti-pattern | Risk | Solution |
|---|---|---|
| Root containers | Privilege escalation | runAsNonRoot: true |
| Secrets as env vars | Exposure in logs | Mount as volumes |
latest images | Uncontrolled versions | Immutable tags |
| Overly broad ClusterRoleBinding | Excessive access | Namespace-scoped Roles |
| No Network Policies | Lateral movement | Default deny |
If you are new to Kubernetes, start with Kubernetes Fundamentals to understand the architecture before implementing these measures.
To deploy your first secure cluster, follow our tutorial Deploy Your First Kubernetes Cluster in 30 Minutes.
Key takeaway: Kubernetes cluster security best practices are not optional. You must integrate them from day one, not after an incident.
Take Action: Get Trained in Kubernetes Security
Kubernetes security with Network Policies and Pod Security requires specialized skills. Certification training prepares you for real production challenges.
Your recommended learning path:
- LFS458 Kubernetes Administration: Master the fundamentals of secure administration (4 days, CKA preparation)
- LFS460 Kubernetes Security Fundamentals: Deepen cluster security and prepare for CKS (4 days)
- Kubernetes Fundamentals: Discover Kubernetes if you are a beginner (1 day)
Consult our complete Kubernetes Training guide to choose the path suited to your profile. Contact our advisors for personalized guidance.