Platform Security (16%)

Supply Chain Security

The software supply chain includes every step from source code to running container. An attacker can compromise any step — source code, build pipeline, registry, or deployment. Securing the supply chain means verifying integrity at every stage.

1. Source — Code review, branch protection, signed commits.
2. Build — Reproducible builds, isolated build environments.
3. Registry — Image scanning, access control, retention policies.
4. Deployment — Admission control, image signature verification.
5. Runtime — Minimal base images, no privilege escalation.

Image Security

Container images are the packaging format for applications. An insecure image can contain known vulnerabilities, malware, or secrets. Image security involves scanning, signing, and using minimal base images.

• Scan for CVEs — Use Trivy, Grype, or Snyk to scan images.
• Use minimal base images — distroless, alpine, or scratch.
• Do not run as root — Set runAsNonRoot in SecurityContext.
• Pin image tags — Use SHA digests, not mutable tags.
• Private registries — Do not pull from public registries in production.

Admission Control

Admission controllers intercept requests to the API server after authentication and authorization but before the object is stored in etcd. They can validate, mutate, or reject requests.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirelabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequireLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirelabels
        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Missing required labels: %v", [missing])
        }

PKI and Certificates

Kubernetes uses TLS certificates extensively — for API server communication, etcd encryption, webhook authentication, and ingress traffic. Understanding PKI is essential for cluster security.

• CA certificate — Root of trust for the cluster.
• API server certificate — Used by clients to verify the API server.
• Kubelet certificates — Used by the API server to communicate with kubelets.
• etcd certificates — Used by the API server to communicate with etcd.
• Service account tokens — Signed JWTs for service account authentication.

Secrets Management

Kubernetes Secrets store sensitive data like passwords, tokens, and keys. However, Secrets are only base64-encoded by default, not encrypted. For real security, enable etcd encryption at rest and use external secret stores.

kubectl create secret generic my-secret \
  --from-literal=password='s3cr3t' \
  --from-literal=username='admin'

kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d
echo ""

# External secret stores
# - HashiCorp Vault (via Vault Agent or CSI driver)
# - AWS Secrets Manager (via External Secrets Operator)
# - Azure Key Vault (via CSI driver)

Image Signing and Verification

Image signing uses cryptographic signatures to verify that an image was built by a trusted source and has not been tampered with. Sigstore and Cosign are the emerging standards for container image signing.

• Cosign — Sign and verify container images.
• Sigstore — Keyless signing with OIDC identity.
• Notary — Docker Content Trust for image signing.
• Admission controllers — Enforce image signature verification at deploy time.

Key Commands

kubectl get validatingwebhookconfigurations
kubectl get mutatingwebhookconfigurations
kubectl get certificates -A
kubectl get certificaterequests -A
kubectl describe secret -n kube-system
kubectl get events --field-selector type=Warning -A