The three previous lessons secured identity, the channel and the code. All of that runs on top of a platform — images, pods, secrets, cluster network, API server permissions, pipelines — and a flaw in that layer nullifies the others: an image with a vulnerable library, a container running as root that escapes to the node, a Secret readable by anyone in the namespace, a pod that can talk to whoever it likes, or a CI token with cluster-admin permissions. This lesson closes the module by hardening TechCorp's platform: threat model and the 4Cs, secure images (scanning with Trivy, signing with cosign, digests), a complete securityContext and Pod Security Admission, secrets (Kubernetes Secrets, External Secrets Operator, rotation, OIDC in CI), NetworkPolicy with deny-all by default (closing what 07-02 deferred here), RBAC and one ServiceAccount per service, auditing and detection, supply chain, and a checklist with TechCorp's real status. User authentication (07-01), TLS/mTLS (07-02) and OWASP/code (07-03) are only linked to.

Notice. The policies, versions and values in this lesson are for teaching purposes. Before applying them to a real cluster, review them with a platform security professional and with whoever is responsible for compliance; and test every restriction in staging, because many of them break workloads that used to work.

1. Platform threat model and the 4Cs
2. Secure images: minimal base, scanning, signing and digests
3. Pod security: complete securityContext and Pod Security Admission
4. Secrets: Kubernetes Secrets, External Secrets Operator and rotation
5. Secrets in CI: GitHub Environments and OIDC
6. Network: NetworkPolicy with deny-all by default
7. Kubernetes RBAC: one ServiceAccount per service and minimal roles
8. Auditing and detection
9. Supply chain: lockfile, SBOM and SLSA
10. Platform checklist for TechCorp

Before hardening anything, what can go wrong and in which layer:

The 4Cs of cloud native security (Cloud, Cluster, Container, Code) are a reminder that each layer inherits the security of the one outside it: the best securityContext does not save a cluster with its API server open to the Internet, and the best cluster does not save an orders-service with SQL injection. This lesson covers Container and Cluster; Code was 07-01/07-03; Cloud belongs to the provider and to Platform.

The Dockerfile from 05-01 already meets the essentials: node:20-alpine, multi-stage (no compilers or devDependencies in the final image), USER node, COPY --chown, HEALTHCHECK and npm ci --omit=dev with the .npmrc as a build secret. What gets added:

• Minimal base: alpine reduces the surface to a few MB; an even smaller alternative is distroless (gcr.io/distroless/nodejs20-debian12: no shell, no package manager; kubectl exec ... sh stops working, which is a security advantage and a debugging cost — solved with kubectl debug and ephemeral containers). TechCorp keeps alpine in phase 1 and evaluates distroless for Payments.
• Scanning in CI with Trivy, which 05-03 left configured with severity: CRITICAL. The final policy: fail on CRITICAL and HIGH that have a patch available, ignore those that do not but record them, and rescan the images already deployed every night (CVEs appear after the build):

• Image signing with cosign (Sigstore): after the push, the pipeline signs the image with the workflow's OIDC identity (no keys to store, keyless), and the cluster verifies the signature before starting a pod, with an admission controller (Kyverno or Sigstore's policy controller). Mention only, with the commands:

• imagePullPolicy and digest: a tag (1.0.1) can be re-pointed; a digest (@sha256:…) cannot. In production, the Kustomize overlay pins newTag and digest (kustomize edit set image ghcr.io/techcorp/orders-service@sha256:9f1c…), imagePullPolicy: IfNotPresent is safe because the digest is immutable, and the ghcr.io/techcorp registry is private with imagePullSecrets (or cloud identity) on the ServiceAccount. latest remains forbidden (05-01).

The Deployment from 05-02 had runAsNonRoot, runAsUser: 1000, allowPrivilegeEscalation: false and readOnlyRootFilesystem: true. The complete version, the one the restricted profile requires:

What each new line brings: seccompProfile: RuntimeDefault enables the runtime's (containerd) seccomp profile, which blocks dozens of syscalls that no normal application uses and that are the route of many container escapes; capabilities: drop: [ALL] removes even the capabilities Docker grants by default (NET_RAW, CHOWN...): if an attacker runs code inside, they cannot open raw sockets or change owners; emptyDir for /tmp makes readOnlyRootFilesystem compatible with libraries that write temporary files (with sizeLimit so it does not fill the node); fsGroup allows reading secrets mounted as files without being root.

Pod Security Admission (PSA) makes the cluster reject pods that do not meet a profile, instead of trusting that every Deployment writes it correctly. Three profiles: privileged (everything), baseline (without the worst: privileged, hostPath, hostNetwork), restricted (all of the above plus runAsNonRoot, drop ALL, seccomp, no escalation). It is enabled with labels on the namespace:

The migrations Job from 05-02, the gateway, RabbitMQ and Keycloak must comply too (or live in another namespace with a justified baseline). For finer rules than PSA's (requiring a digest, forbidding latest, requiring resources), a policy engine such as Kyverno or OPA Gatekeeper is used; mention only.

A Kubernetes Secret (05-02: orders-db, orders-rabbitmq, and since 07-01 orders-oidc; payments-provider in 07-02) is base64, not encryption: kubectl get secret orders-db -o jsonpath='{.data.ORDERS_DB_URL}' | base64 -d shows it to anyone with read permission. Three layers to make it secure:

1. Encryption at rest in etcd (the API server's EncryptionConfiguration with aescbc/kms): the responsibility of Platform or of the managed provider (enabled by default on the major ones). Without it, a copy of etcd is a copy of every secret.
2. Read RBAC (section 7): only the ServiceAccounts of the pods that mount them and a few Platform people can get secrets; the Orders developers cannot. And the Secret's manifest is never in techcorp/platform (GitOps is public inside the company).
3. External source of truth with the External Secrets Operator (ESO): the secret lives in a manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager...), and ESO creates and updates the Kubernetes Secret from it. That way git contains only the reference:

Credential rotation. A database password lives for years because rotating it is scary; with this architecture, the procedure is routine (and it runs at least every six months and always after a leak, 07-03):

A Reloader (Stakater) or the Argo CD annotation can automate step 3 when the Secret changes.

In 05-03 the pipeline had GITHUB_TOKEN, PACT_BROKER_TOKEN, PLATFORM_TOKEN and KUBECONFIG_STAGING, and the mention of OIDC was left pending. What gets closed here:

• GitHub Environments (staging, production): per-environment secrets, required reviewers for production, and deployment branches so that only main can use them. A workflow from a feature branch does not see KUBECONFIG_STAGING.
• OIDC instead of long-lived tokens: with permissions: id-token: write, the workflow obtains a JWT signed by GitHub that says "I am workflow X of repo Y on branch Z", and the cloud or the registry exchanges it for credentials that last minutes. It is the same client credentials from 07-01, with GitHub as the issuer. For the registry (ghcr.io) GITHUB_TOKEN already does this; for a managed cluster in the cloud:

With this, KUBECONFIG_STAGING disappears as a secret (the trust is "this repo, this branch, this workflow", configured in the cloud role's policy), and in production there is no credential at all: Argo CD pulls (05-03). PLATFORM_TOKEN (for opening the promotion PR) is replaced by a GitHub App with permissions bounded to the platform repository. PACT_BROKER_TOKEN stays as an environment secret, rotated on a schedule.

Files versus environment variables. Environment variables are visible in kubectl describe pod (not the values from secretRef, but those from env: value are), in /proc/<pid>/environ, and child processes inherit them; files mounted from a Secret (volumes: - secret: { secretName: orders-db } + ORDERS_DB_URL_FILE=/etc/secrets/ORDERS_DB_URL) can only be read by whoever has the right UID/fsGroup, and Kubernetes hot-updates them when the Secret changes. The <VARIABLE>_FILE convention from 04-03 is already implemented: TechCorp migrates the Payments secrets to files first (audit) and the rest as each service is touched.

Without NetworkPolicy, any pod in the cluster can open a connection to any other: a compromised pod in techcorp reaches inventory-service:3006 with X-User-Roles: admin (07-01) or postgres:5432 to try passwords. NetworkPolicy objects are a firewall by labels; they require a CNI that enforces them (Calico, Cilium; managed offerings usually ship one). Strategy: deny everything in the namespace and open explicitly.

And payments-service is the only one with egress to the Internet (the payment provider): ipBlock: { cidr: 0.0.0.0/0, except: [10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16] } on port 443, or better, if the CNI supports it (Cilium), a policy by FQDN (api.payment-provider.example). The rest of the services do not leave the cluster: a compromised catalog-service cannot exfiltrate data or download tools.

With the policies in place, the warning from 07-01 about X-User-* moves from "any pod" to "only the gateway and Prometheus can reach Orders" — and mTLS with a mesh (07-02) will add, when it arrives, cryptographic identity on top of the network. The policies live in techcorp/platform/k8s/network/ and Platform reviews them; every new service arrives with its own in the template.

Every pod runs with a ServiceAccount (SA); by default, default, with a token mounted at /var/run/secrets/kubernetes.io/serviceaccount that allows talking to the API server. orders-service does not need to talk to the API server, so: its own SA (a clear identity for NetworkPolicy in some CNIs, for mTLS with a mesh in 07-02, and for imagePullSecrets) and no token mounted:

Those who do talk to the API server, with the minimum:

• API server audit log: records who did what against the API (kubectl get secret orders-db by a person, a create of a Role, a pod that does not comply with PSA). It is configured with an audit Policy (Metadata level for everything, RequestResponse for secrets, roles and rolebindings) and sent to Loki (06-01) with long retention, separate from application logs (07-03). On managed clusters it is enabled from the provider.
• Runtime detection: Falco (mention) watches syscalls on the nodes and alerts on anomalous behavior — a shell opened in a production container, a process reading /etc/shadow, an outbound connection from a pod that should not go out — and integrates with Alertmanager (06-05). With readOnlyRootFilesystem, drop ALL and NetworkPolicies, most of those behaviors already fail; Falco reports the attempt.
• Hygiene: kube-bench (CIS Benchmark) for the cluster configuration and kubectl get events -A --field-selector reason=FailedCreate to see pods rejected by PSA.

The supply chain is everything between Luis's code and the pod in production, and every link can be replaced by something malicious. What TechCorp pins down: package-lock.json and npm ci (05-01/07-03: exactly what was tested is what gets deployed); dependencies and CI actions pinned by version (actions/checkout@v4, better by SHA for the critical ones) and the base image by digest (node:20-alpine@sha256:…, updated by Renovate); an SBOM per image with Syft (syft ghcr.io/techcorp/orders-service:1.0.1 -o spdx-json > sbom.json) attached to the image (cosign attest) to answer within minutes "which services ship libxml2 2.9.x?"; cosign signature and verification at admission (section 2); and SLSA (Supply-chain Levels for Software Artifacts) as the reference framework: TechCorp is at level 2 (build in CI with signed provenance) and aims for 3 (ephemeral, isolated runners). Mention only: the essential thing is that the pipeline from 05-03 is the only path to production, and that it produces verifiable artifacts.

Status at the close of module 7, kept in techcorp/platform/SECURITY.md:

• Applying deny-all without the DNS policy: nothing resolves anymore and it looks like "Kubernetes is broken". DNS first, always.
• Forgetting Prometheus scraping, Jaeger or Keycloak in the policies: metrics and traces disappear silently. Review every to/from against the diagrams from 06-01/06-02.
• readOnlyRootFilesystem without emptyDir on /tmp: the application fails at startup with EROFS on a dependency's first write.
• PSA enforce all at once in a namespace with RabbitMQ, Keycloak or the ingress controller: rejected pods. warn/audit first, then enforce.
• Secret in the GitOps repository "because it's base64": it is plain text. Reference with ExternalSecret, value in the manager.
• Rotating the password and not restarting the pods (environment variables): they fail on reconnect hours later, in the middle of the night. Rotation = change + sync + rollout restart (or hot-reloaded files).
• cluster-admin for the pipeline or Argo CD "for now": now lasts years. Role per namespace from day one.
• Tip: every new restriction is tested with a game day (06-03): try to do what is forbidden (kubectl run as root, curl to Inventory from another pod, kubectl get secret as a developer) and check that it fails and that it lands in the audit log.

Exercise 1. Write the NetworkPolicy for notifications-service (port 3005): it consumes from RabbitMQ (amqps), sends email to an external provider over HTTPS, exposes /metrics to Prometheus, and nobody in the cluster should be able to call its API except Prometheus. State the risk the external egress introduces and how to bound it.

Exercise 2. A Catalog developer asks to be able to run kubectl exec on the catalog-service pods in staging "to debug Mongo". Design the minimal Role/RoleBinding, say what it does not include and propose a better alternative consistent with this lesson.

Exercise 3. Walk through the threat model from section 1 for the scenario "an attacker manages to run code inside the catalog-service pod thanks to a compromised dependency" and list, layer by layer, which measures from this lesson limit the damage and what they could still do.

Solution 1.

(DNS is covered by allow-dns.) The risk: egress to "any public IP on 443" allows exfiltrating data (emails, names) if the pod is compromised. Bounding it: a policy by the email provider's FQDN with Cilium (toFQDNs: [{ matchName: api.email.example }]), or an outbound proxy (egress gateway) with a domain allowlist that also provides a single audit point; and the minimization from 07-03 (Notifications does not persist personal data) reduces what there is to exfiltrate.

Solution 2. Role catalog-debugger in techcorp with pods (get/list), pods/log (get), pods/exec (create) limited to the Catalog pods — RBAC does not filter by label, so it is done with resourceNames (fragile, names change) or, better, by granting the Role in a techcorp-catalog namespace if things are split by team; RoleBinding to the SSO group shopping-experience-team. It does not include secrets, exec on other pods, or anything write-related. Better alternatives: (1) kubectl debug with an ephemeral container (kubectl debug -it pod/catalog-service-xxx --image=mongo:7 --target=catalog-service) instead of exec into the application container, which also works with distroless; (2) a port-forward to MongoDB (pods/portforward) and the Mongo client locally with the read-only svc_catalog_ro user; (3) whatever needs to be seen should be in logs/metrics (06-01) so nobody ever enters production. And every exec/debug lands in the audit log (section 8).

Solution 3. With code running as the node user (uid 1000) in the Catalog pod: Container: it is not root, drop ALL and seccomp block most escape routes; readOnlyRootFilesystem prevents installing tools (only a 64 MB /tmp); resources.limits prevent taking down the node. Secrets: it sees the process's environment variables (Catalog's MONGO_URL) — with _FILE files it would still see them, it is its own secret —; it cannot read other Secrets (SA without token, and no RBAC). Network: it only reaches Catalog's MongoDB, Keycloak and whatever its policy allows; it does not reach Orders, Inventory, PostgreSQL or RabbitMQ, and it does not get out to the Internet (no external egress): it can read/modify the catalog (its real damage) but cannot easily exfiltrate it or pivot. Identity: no valid headers and no other service's token (the X-User-* headers are useless to it because it cannot reach other services; with a mesh, it would not have a certificate either). Detection: Falco would alert on the shell or the odd process; the audit log would see nothing because it does not touch the API. What it could still do: change prices or descriptions in MongoDB (mitigated by the auditing from 07-03 and the svc_catalog user without dropDatabase), serve fake responses to Orders (mitigated by zod validation in the ACL in Orders and prices frozen in the order) and consume CPU up to the limit. And the underlying lesson: the compromised dependency should have been caught by Trivy/npm audit/SBOM before it arrived (sections 2 and 9).

With this lesson the platform stops being the weak link beneath identity, the channel and the code. TechCorp has a layered threat model (4Cs); minimal images scanned with Trivy (CRITICAL/HIGH blocking) and referenced by digest, with cosign and verification at admission as the next step; pods with a complete securityContext (runAsNonRoot, drop ALL, seccompProfile: RuntimeDefault, readOnlyRootFilesystem with emptyDir on /tmp) and Pod Security Admission restricted in techcorp; secrets encrypted in etcd, restricted by RBAC and provided by the External Secrets Operator (ExternalSecret orders-db from the external manager) with a rotation procedure and rollout restart; CI with Environments and OIDC instead of kubeconfig and long-lived tokens, and secrets as _FILE files where it matters most; deny-all NetworkPolicy with DNS, gateway as the only entry from the Ingress, Orders toward Catalog/Customers/RabbitMQ/PostgreSQL/Keycloak, Inventory only from Orders — closing what 07-02 deferred here — and only Payments with outbound Internet access; one ServiceAccount per service without token, Role deployer and Argo CD bounded, no cluster-admin; API server audit log and Falco as detection; lockfile, pinned versions, SBOM and SLSA as the supply chain; and a checklist with what is done and what is pending. Module 7 thus ends where module 6 began: with a system that is observable, resilient, scalable, operable and now also secure in layers — authentication and authorization with Keycloak and JWT, an encrypted and signed channel, validated and audited code, a hardened platform — and with an honest list of what remains for phase 2 (mTLS with a mesh, cosign at admission, PSA enforce, ESO for every service). Module 8 gathers the whole journey: how the monolith migration was executed step by step, the complete implementation of the services, their end-to-end deployment and operation, and the lessons learned by Marta, Luis and TechCorp's four teams.