> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Kubernetes Security Essentials
> Practical Kubernetes security guidance for platform engineering covering authentication, authorization, admission control, secrets management, network policies, policy as code, and observability to enable secure multi-tenant platforms
Welcome back, students.
This lesson covers practical Kubernetes security essentials for platform engineering. When your platform supports many teams and environments, design for isolation, zero-trust principles, automated governance, and compliance — while preserving developer productivity. Balance protecting the cluster with enabling developers: too much restriction stifles velocity; too little invites risk.
Adopt a defense-in-depth strategy: combine authentication, authorization, admission control, secrets protection, network segmentation, and observability to reduce blast radius while enabling safe developer workflows.
Common areas to address
* Secrets management and encryption at rest
* Network policies and pod-to-pod communication
* Admission control (what requests get modified or validated)
* Authorization and authentication (who is the caller and what can they do)
* Policy-as-code and automated governance (OPA Gatekeeper, Kyverno)
* Observability, audit logs, and compliance reporting
Authentication (authn) vs Authorization (authz)
Authentication establishes identity; authorization determines allowed actions. Kubernetes supports several authentication methods — integrate with federated identity providers and PKI where possible.
Authorization determines what an authenticated subject may do. Kubernetes supports RBAC, legacy ABAC, and external webhook-based authorization.
RBAC essentials
Role-Based Access Control (RBAC) maps subjects (users, groups, service accounts) to Roles or ClusterRoles. RoleBindings (namespace-scoped) or ClusterRoleBindings (cluster-scoped) attach subjects to roles. Remember:
* Role and RoleBinding are namespace-scoped and must be created inside the same namespace.
* ClusterRole and ClusterRoleBinding are cluster-scoped and can grant permissions across namespaces.
* Follow least-privilege: grant the minimal verbs and resources required.
Example RoleBinding (namespace-scoped):
```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pony-dev-binding
namespace: pony-dev
subjects:
- kind: User
name: phuong@sparkleponyranch.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pony-developer
apiGroup: rbac.authorization.k8s.io
```
Service accounts and pod identity
Pods run as a ServiceAccount by default. Bind ServiceAccounts to Roles (or ClusterRoles) to grant pods permissions while minimizing privileges.
Example ServiceAccount and RoleBinding that grants a service account permissions in the `pony-production` namespace:
```yaml theme={null}
apiVersion: v1
kind: ServiceAccount
metadata:
name: pony-spawner-sa
namespace: pony-production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pony-spawner-binding
namespace: pony-production
subjects:
- kind: ServiceAccount
name: pony-spawner-sa
namespace: pony-production
roleRef:
kind: Role
name: pony-app-role
apiGroup: rbac.authorization.k8s.io
```
Platform RBAC strategy
Namespaces can be organized per application, per team, or by environment (dev/prod). The critical controls are least privilege, separation of duties, and periodic permission audits.
Admission controllers
Every Kubernetes API request flows through stages: authentication, authorization, mutating admission controllers, validating admission controllers, then persistence to etcd. Mutating admission controllers run before validating ones and can modify requests (e.g., inject sidecars, add labels).
Built-in admission controllers you should know
| Admission Controller | Purpose | Notes |
| - | - | - |
| `PodSecurity` | Enforces Pod Security Standards (replace PSP) | Supports `audit`, `warn`, and `enforce` modes |
| `ResourceQuota` | Limits resource consumption per namespace | Prevents noisy neighbors and resource exhaustion |
| `LimitRanger` | Applies default resource requests/limits | Helps ensure pods specify sensible resources |
| `NodeRestriction` | Limits kubelet access to node and pod info | Reduces privilege of kubelets to modify unrelated resources |
| `ValidatingAdmissionWebhook` / `MutatingAdmissionWebhook` | External webhook-based validation/mutation | Integrate policy engines like Gatekeeper or Kyverno |
Pod security
PodSecurityPolicy (PSP) has been deprecated; use the Pod Security admission controller and policy-as-code tools (OPA Gatekeeper, Kyverno) for richer enforcement. Teams commonly use `audit`, `warn`, and `enforce` modes to progressively tighten policies.
OPA Gatekeeper example
Gatekeeper provides ConstraintTemplates and Constraints to enforce organization-wide rules via admission webhooks. Below is a simplified ConstraintTemplate that requires specific labels on resources; the Rego snippet checks `metadata.labels` and emits violations for missing labels.
```yaml theme={null}
# Require labels on all pony services
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: requirelabels
spec:
crd:
spec:
validation:
properties:
labels:
type: array
items:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package requirelabels
violation[{"msg": msg}] {
required := input.parameters.labels
provided := input.review.object.metadata.labels
missing := required[_]
not provided[missing]
msg := sprintf("Missing required label: %v", [missing])
}
```
Gatekeeper produces clear violation messages and lets you enforce consistent policy-as-code across clusters. See the official docs: [https://open-policy-agent.github.io/gatekeeper/](https://open-policy-agent.github.io/gatekeeper/)
Secrets and data at rest
Kubernetes Secrets are Base64-encoded by default — Base64 is an encoding, not encryption. Protect secret data by enabling etcd encryption at rest and by using external secret stores for rotation, access control, and auditing.
Default Kubernetes Secrets are Base64-encoded (not encrypted). Always enable etcd encryption at rest and consider external secret managers (Vault, cloud KMS, Sealed Secrets, ExternalSecrets) for stronger protection and rotation.
External secret solutions — quick comparison
| Solution | Use case | Key features / links |
| - | - | - |
| HashiCorp Vault | Enterprise secret management | Dynamic secrets, rotation, strong audit: [https://www.vaultproject.io](https://www.vaultproject.io) |
| Sealed Secrets (Bitnami) | Storing secrets safely in Git | Encrypts secret into a SealedSecret that only the controller can decrypt: [https://github.com/bitnami-labs/sealed-secrets](https://github.com/bitnami-labs/sealed-secrets) |
| External Secrets Operator | Sync external secrets into Kubernetes | Integrates cloud KMS and secret stores: [https://external-secrets.io](https://external-secrets.io) |
Good secrets management includes least-privilege access to secrets, automated rotation, auditing, and encrypting at rest.
Network security and CNI
Network security includes wire-level encryption (TLS/mTLS) and network isolation. Use NetworkPolicies (enforced by the CNI) to control pod-to-pod traffic and implement a default-deny posture with explicit allows for required communication.
Popular CNIs and service mesh technologies:
| Technology | Use case |
| - | - |
| Cilium | eBPF-based CNI for performance, policy, and observability: [https://cilium.io](https://cilium.io) |
| Calico | Policy-rich networking with network policy enforcement: [https://projectcalico.org](https://projectcalico.org) |
| Istio | Service mesh providing mTLS, traffic management, and observability: [https://istio.io/latest](https://istio.io/latest) |
| eBPF | Kernel-level observability and networking capabilities: [https://ebpf.io](https://ebpf.io) |
Example: default-deny with an explicit egress allow
```yaml theme={null}
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: pony-production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-pony-spawner-to-db
namespace: pony-production
spec:
podSelector:
matchLabels:
app: pony-spawner
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
app: postgres
ports:
- protocol: TCP
port: 5432
```
A default-deny posture with targeted allows is a practical path toward zero-trust networking in Kubernetes.
Key takeaways
* RBAC with least privilege is the baseline. Use Namespaces, Roles, and RoleBindings consistently and audit permissions regularly.
* Enforce policies via admission controllers (PodSecurity admission controller, builtin controllers, and policy-as-code engines like OPA Gatekeeper or Kyverno).
* Kubernetes Secrets are Base64-encoded by default — not encrypted. Enable etcd encryption at rest and prefer external secret stores for rotation and auditing:
* Vault: [https://www.vaultproject.io](https://www.vaultproject.io)
* Sealed Secrets: [https://github.com/bitnami-labs/sealed-secrets](https://github.com/bitnami-labs/sealed-secrets)
* ExternalSecrets: [https://external-secrets.io](https://external-secrets.io)
* Network security requires CNI-enforced NetworkPolicies and micro-segmentation. Consider eBPF CNIs (e.g., Cilium) or a service mesh (e.g., Istio) for mTLS and flow-level observability.
TLS, mutual TLS, service meshes, and observability tools are enhancements layered on Kubernetes’ core controls. A practical platform security posture combines authentication, authorization, admission controls, strong secrets management, and network policies to minimize risk while enabling teams to deliver value.
Thanks — this is the end of this lesson.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.