Securing the Supply Chain and Secrets

A container image is built from base images, OS packages, and application dependencies, then pushed through a registry into the cluster. Each step is an opportunity for compromise. Supply-chain attacks insert malicious code before it ever reaches production.

• Compromised base images or dependencies.
• Tampered images in the registry.
• Malicious CI/CD pipeline steps.

Images frequently ship with known-vulnerable packages. Scanning catches these before deployment.

• Old base images accumulate CVEs.
• Bloated images expand the attack surface.
• Embedded secrets in image layers leak credentials.

Reduce the surface by starting small and known-good.

• Use distroless or minimal base images (no shell, no package manager).
• Pin base images by digest, not floating tags.
• Prefer official or internally vetted bases.

A smaller image means fewer CVEs and fewer tools for an attacker to abuse post-compromise.

Signing proves an image came from your pipeline and was not tampered with. Provenance (SLSA) records how it was built.

• Cosign signs and verifies images.
• Generate an SBOM to track every component.
• Attach build provenance attestations.

Enforce that only signed, scanned images run. An admission controller rejects unsigned or vulnerable images at deploy time.

The CI/CD system itself is high-value: it holds credentials and can push to production.

• Scope pipeline credentials with least privilege and short lifetimes.
• Pin and verify third-party CI actions/plugins.
• Isolate build runners; do not reuse them across trust levels.
• Protect the registry with auth and immutability.

Kubernetes Secrets are base64-encoded, not encrypted, by default. Anyone who can read them, or read etcd, sees plaintext.

Protect etcd contents so a stolen backup or etcd access does not leak everything.

• Enable encryption at rest with an EncryptionConfiguration.
• Back it with a cloud KMS provider for envelope encryption.
• Restrict and audit direct etcd access.

The strongest pattern keeps secrets out of the cluster store entirely.

• HashiCorp Vault or cloud secret managers hold the source of truth.
• The External Secrets Operator or CSI driver injects them at runtime.
• Use workload identity so pods fetch secrets via short-lived cloud tokens, not static keys.

Operational practices reduce secret exposure.

• Never bake secrets into images or commit them to Git.
• Scan repos and images for leaked credentials.
• Rotate secrets regularly and on suspected exposure.
• Restrict RBAC get/list secrets to the minimum.

When assessing, verify that unsigned or vulnerable images are actually blocked, that Secrets are encrypted at rest, and that no plaintext credentials sit in images or Git. Demonstrate findings without exfiltrating real secrets beyond proof.

Report each gap with the concrete control (signing policy, KMS encryption, external manager) that closes it.

Confirm your supply-chain and secrets knowledge.

You hardened the image supply chain and secret handling.

• Scan images, use minimal pinned bases, and sign with cosign.
• Enforce signed/scanned images and trusted registries at admission.
• Kubernetes Secrets are base64 only; enable KMS encryption at rest.
• Prefer external secret managers and workload identity; practice secret hygiene.

This completes the Kubernetes Security course and this lesson set.