Kubernetes Security: RBAC, NetworkPolicy, and Best Practices

A misconfigured Kubernetes cluster is a critical attack surface. RBAC, NetworkPolicy, Pod Security Standards, encrypted Secrets: the complete guide to securing your clusters.

Kubernetes Is Not Secure by Default

A freshly installed Kubernetes cluster with default options is far from secure: pods running as root, unauthenticated API server access, no network policies, secrets stored as unencrypted base64 in etcd. Kubernetes security incidents are regularly documented, often linked to misconfigured clusters exposed on the Internet.

RBAC: Role-Based Access Control

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-readonly
  namespace: production
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-readonly-binding
  namespace: production
subjects:
  - kind: User
    name: alice@company.com
roleRef:
  kind: Role
  name: developer-readonly
  apiGroup: rbac.authorization.k8s.io

NetworkPolicy: Network Micro-Segmentation

By default, all pods in a cluster can communicate with each other. NetworkPolicies define allowed traffic rules — equivalent to AWS Security Groups but at the pod level. Recommended strategy: default-deny in each namespace, then explicitly allow necessary flows.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Pod Security Standards

Three levels: Privileged (no restrictions — avoid in production), Baseline (prevents obvious privilege escalations), Restricted (maximum best practices: non-root, read-only root filesystem, no privilege escalation).

kubectl label namespace production   pod-security.kubernetes.io/enforce=restricted   pod-security.kubernetes.io/enforce-version=latest

Secret Encryption

Kubernetes Secrets are base64-encoded in etcd — not encrypted. For real protection: enable AES-GCM encryption at rest for etcd, use External Secrets Operator to integrate with AWS Secrets Manager or Azure Key Vault (secrets never stored in Kubernetes), or use the CSI Secret Store Driver to mount secrets from an external provider directly as pod volumes.

Continuous Scanning Tools

Tool	Usage
Trivy	Docker image scanning (CVE), IaC, SBOM
Falco	Runtime anomaly detection (suspicious syscalls)
Kube-bench	CIS Kubernetes Benchmark audit
OPA/Gatekeeper	Policy-as-code: customisable admission controller
Kyverno	OPA alternative, native Kubernetes YAML policies

Conclusion

Securing Kubernetes is a continuous effort covering multiple layers: RBAC for human and machine access, NetworkPolicy for network segmentation, Pod Security Standards for container behaviour, and secret encryption. No single layer is sufficient — defence in depth is the only viable approach. Regular audits with kube-bench and Trivy are essential to maintain a compliant cluster over time.