Kubernetes Security Best Practices: RBAC, Secrets, Pods, Images and Network Policies

Kubernetes Security Best Practices#

Kubernetes security is not one setting. It is a layered approach that protects users, workloads, containers, secrets, images, network traffic, cluster access and production deployments. This guide explains the practical controls DevOps teams should understand before running Kubernetes in real environments.

Animated mental model: Kubernetes security layers#

Table of contents#

• Quick answer
• Kubernetes security model
• RBAC and least privilege
• ServiceAccounts
• Secrets and sensitive data
• Pod securityContext
• Container image security
• NetworkPolicy
• Resource limits
• Ingress and TLS
• Admission controls
• Audit and monitoring
• Production checklist
• Practice lab

Quick answer#

Use RBAC#

Give users and applications only the permissions they need. Avoid broad cluster-admin access.

Secure Pods#

Run containers as non-root, drop Linux capabilities, set resource limits and avoid privileged containers.

Protect Secrets#

Do not commit secrets to Git. Use Kubernetes Secrets carefully and encrypt/rotate sensitive values.

Restrict traffic#

Use NetworkPolicies and TLS so workloads are not open to everything by default.

1. Kubernetes security model#

Kubernetes security has multiple layers. A safe cluster usually combines identity, authentication, authorization, admission controls, workload security, secret management, image security, network policy, logging and monitoring.

Think of Kubernetes security like a building: RBAC is the door lock, NetworkPolicy is the corridor control, Pod security is the room safety rule, Secrets are the vault, and audit logs are the CCTV footage.

2. RBAC and least privilege#

RBAC controls who can perform actions on Kubernetes resources. It answers questions like: can this user list pods? can this ServiceAccount create deployments? can this CI/CD pipeline update production resources?

kubectl auth can-i get pods kubectl auth can-i create deployments -n production kubectl auth can-i delete secrets --as system:serviceaccount:dev:app-sa

Example: read-only Role#

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: pod-reader rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"]

Bind the Role to a user or ServiceAccount#

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: dev subjects: - kind: ServiceAccount name: app-reader namespace: dev roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

3. ServiceAccounts for applications#

A ServiceAccount is an identity for a Pod or application inside the cluster. Do not let every Pod use the default ServiceAccount with unnecessary permissions.

apiVersion: v1 kind: ServiceAccount metadata: name: app-sa namespace: dev

Attach it to a Pod or Deployment:

spec: serviceAccountName: app-sa

4. Kubernetes Secrets and sensitive data#

Kubernetes Secrets store sensitive data such as passwords, tokens, and keys. But a Secret is not magic. It must be protected with RBAC, encryption at rest, limited access, rotation and safe Git practices.

Create a Secret from command line#

kubectl create secret generic db-secret \ --from-literal=username=appuser \ --from-literal=password='change-me' \ -n dev

Use Secret as environment variables#

env: - name: DB_USER valueFrom: secretKeyRef: name: db-secret key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

5. Pod securityContext#

Pod security settings reduce container risk. A secure Pod should avoid root, avoid privilege escalation, use read-only root filesystem where possible, and drop unnecessary Linux capabilities.

apiVersion: v1 kind: Pod metadata: name: secure-nginx spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: nginx image: nginx:1.27-alpine securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL ports: - containerPort: 80

Some images may need adjustment before they can run with strict security settings. That is normal. The goal is to reduce privileges gradually and intentionally.

6. Container image security#

Kubernetes runs container images, so image security starts before Kubernetes deployment. Use trusted images, pin versions, scan images, remove secrets from image layers, and avoid unnecessary packages.

kubectl set image deployment/web nginx=nginx:1.27-alpine kubectl rollout status deployment/web

• Use versioned tags instead of only latest .
• Scan images in CI/CD before deployment.
• Use private registries for internal applications.
• Use minimal base images where practical.
• Review Dockerfile changes before merging.

7. NetworkPolicy: restrict Pod-to-Pod traffic#

By default, many Kubernetes networking setups allow Pods to talk broadly. NetworkPolicy lets you restrict traffic between Pods and namespaces when your CNI plugin supports it.

Example: allow only frontend to reach backend#

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

8. Resource requests and limits#

Resource controls protect cluster stability. Without requests and limits, one bad workload can consume too much CPU or memory and affect other applications.

resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi"

Use kubectl top pods and monitoring data to tune values.

9. Ingress and TLS security#

Ingress exposes applications to users. Secure it with TLS, correct host rules, trusted certificates, limited admin endpoints and proper authentication at the application or gateway layer.

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress spec: tls: - hosts: - app.example.com secretName: app-tls rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: web port: number: 80

10. Admission controls and policy#

Admission controls check requests before they are stored in Kubernetes. They can block risky workloads, enforce image policies, require labels, prevent privileged containers and enforce resource limits.

Common policy ideas:

• Block privileged containers.
• Require non-root containers.
• Require resource requests and limits.
• Allow images only from trusted registries.
• Require team, app and environment labels.

11. Audit logs and monitoring#

Security is not complete without visibility. Audit logs and monitoring help you answer: who changed this deployment? who accessed a secret? why did a pod restart? what image is running now?

kubectl get events --sort-by=.metadata.creationTimestamp kubectl get pods -A kubectl describe pod POD_NAME -n NAMESPACE kubectl logs POD_NAME -n NAMESPACE

Common mistakes#

• Mistake — Risk — Better approach
• Using cluster-admin everywhere — One compromised token can control everything — Use least-privilege RBAC
• Committing Secrets to Git — Credentials leak — Use external secret management or protected workflows
• No resource limits — Cluster instability — Set requests and limits
• Using latest image tag — Unpredictable deployments — Use version or commit SHA tags
• No NetworkPolicy — Too much internal access — Restrict traffic by app/namespace

Production Kubernetes security checklist#

• Enable RBAC and use least privilege.
• Separate namespaces by application, team or environment.
• Use dedicated ServiceAccounts.
• Protect and rotate Secrets.
• Use image scanning in CI/CD.
• Use non-root containers where possible.
• Set resource requests and limits.
• Use NetworkPolicies for traffic control.
• Use TLS for external traffic.
• Review audit logs and cluster events.
• Patch nodes, Kubernetes components and base images.
• Protect kubeconfig files and CI/CD variables.

Mini practice lab#

1. Create a namespace called secure-demo .
2. Create a ServiceAccount called app-sa .
3. Create a read-only Role for Pods.
4. Bind the Role to the ServiceAccount.
5. Create a Pod that uses runAsNonRoot .
6. Create a Secret and mount it as an environment variable.
7. Use kubectl auth can-i to test access.

kubectl create ns secure-demo kubectl create sa app-sa -n secure-demo kubectl auth can-i get pods --as system:serviceaccount:secure-demo:app-sa -n secure-demo

Related Melochip guides#

• Kubernetes Learning Path
• Kubernetes Namespaces and RBAC Explained
• Kubernetes ConfigMaps and Secrets Explained
• Docker Security Best Practices
• GitLab CI/CD Security Scanning
• Terraform Kubernetes and Helm Deployments

Official references#

• Kubernetes security concepts
• Kubernetes RBAC documentation
• Kubernetes Secrets good practices
• Kubernetes NetworkPolicy documentation