Kubernetes Security Essentials

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.

A presentation slide titled "Kubernetes Security – Foundation of Platform Engineering" showing four pillars: Multi-Tenant Clusters, Zero-Trust Architecture, Policy as Code, and Compliance Requirements, each with an icon and short caption.

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.

A presentation slide titled "Identity and Permissions – Authentication vs Authorization" showing an "Authentication" icon and three methods: 1) Service Accounts (pod identities), 2) OIDC Integration (human users via corporate identity providers), and 3) X.509 Certificates (client certificate authentication).

Authorization determines what an authenticated subject may do. Kubernetes supports RBAC, legacy ABAC, and external webhook-based authorization.

A presentation slide titled "Identity and Permissions – Authentication vs Authorization" showing an "Authorization" icon and listing three authorization approaches: 1) RBAC: Role-Based Access Control, 2) ABAC: Attribute-Based Access Control, and 3) Webhook: External authorization services.

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):

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:

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

A presentation slide titled "Service Accounts – Pod Identity and Permissions" showing three colored user icons labeled Swati, Alan, and Phuong with brief role descriptions and a "Sparkle Pony Ranch" tag. Each entry summarizes responsibilities for creating and securing service accounts for microservices.

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.

A presentation slide titled "Platform RBAC Strategy – Team-Based Permissions" with four numbered boxes outlining: Team Namespaces, Least Privilege, Separation of Duties, and Regular Audits, each with a short description. It summarizes access-control best practices for development teams.

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).

An infographic titled "Admission Controllers — Request Validation and Mutation" showing a vertical flow of Kubernetes API request handling stages with icons. It lists API Request, Authentication, Authorization (RBAC), Mutating Admission, Validating Admission, and Persistence with short notes like "kubectl/API call," "modify request (add labels, inject sidecars)," and "store in etcd."

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.

A slide titled "Essential Built-in Admission Controllers" showing a numbered list of Kubernetes admission controllers. It lists PodSecurityPolicy (noting it's deprecated), PodSecurity, ResourceQuota, LimitRanger, and NetworkPolicy with brief descriptions of each.

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.

# 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/ 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.

A presentation slide titled "Kubernetes Secrets — Secure Data Management." It lists four secret types: Opaque (API keys/passwords), docker-registry (container registry credentials), tls (TLS certificates and private keys), and service-account-token (service account tokens for API authentication).

A slide titled "Kubernetes Secrets – Secure Data Management" showing three points: "Not Encryption" (Base64 is encoding, not encryption), "Encryption at Rest" (enable etcd encryption), and "Encryption in Transit" (TLS for API communication). Copyright KodeKloud is noted at the bottom.

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
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
External Secrets Operator	Sync external secrets into Kubernetes	Integrates cloud KMS and secret stores: https://external-secrets.io

Good secrets management includes least-privilege access to secrets, automated rotation, auditing, and encrypting at rest.

Slide titled "Secure Secrets Management – Platform Engineering Practices." Four panels list External Secrets, Least Privilege, Rotation, and Auditing with icons and short notes about using external secret stores, limiting access, automating rotation, and tracking access.

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
Calico	Policy-rich networking with network policy enforcement: https://projectcalico.org
Istio	Service mesh providing mTLS, traffic management, and observability: https://istio.io/latest
eBPF	Kernel-level observability and networking capabilities: https://ebpf.io

A presentation slide titled "CNI Security – Network Isolation and Policy Enforcement" showing four colored cards: Network Policies, Encryption, Micro-Segmentation, and Observability, each with a short description (e.g., pod-to-pod traffic control, wire-level encryption, fine-grained security, and network flow monitoring).

Example: default-deny with an explicit egress allow

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
- Sealed Secrets: https://github.com/bitnami-labs/sealed-secrets
- ExternalSecrets: 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.

Pre-requisites

Domain 1 - Platform Engineering Core Fundamentals

Domain 2 - Platform Observability, Security, and Conformance

Domain 3 - Continuous Delivery & Platform Engineering

Domain 4 - Platform APIs and Provisioning Infrastructure

Domain 5 - Internal Developer Platforms & Developer Experience

Domain 6 - Measuring Your Platform

Mock Exams & Final Prep

Kubernetes Security Essentials

Watch Video