GKE and DevSecOps Supply-Chain Hardening: From Commit to Runtime
No single scanner secures a Kubernetes delivery chain. The useful design question is which control prevents, detects or contains a specific failure between source code and a running workload.
Protect the source decision
Require reviewed pull requests, protected branches and short-lived CI credentials. Run secret, source and infrastructure scans before merge. Findings should fail on an agreed policy, with time-bounded exceptions that name an owner.
Build once and identify the artifact
Produce an image in an isolated build environment, generate an SBOM, scan dependencies and image layers, and publish by immutable digest. Promotion should reuse the same digest across environments instead of rebuilding potentially different artifacts.
Sign and verify before admission
Use an attestation or signing process tied to the trusted pipeline. Configure Binary Authorization or an admission policy so unverified images cannot run. Protect the attestor identity more strongly than a normal deployment identity.
Constrain workloads at admission
Enforce restricted pod-security settings, non-root execution, read-only filesystems, dropped capabilities, resource bounds and approved registries. Apply default-deny network policy and permit only required flows. Validate policies on representative workloads before enforcement.
Remove long-lived workload keys
Map Kubernetes service accounts to narrowly scoped Google service accounts through Workload Identity. Keep namespaces and service accounts aligned to trust boundaries. Review both Kubernetes RBAC and Google Cloud IAM because either can break least privilege.
Detect what prevention misses
Collect Kubernetes audit, workload, network and Cloud Audit logs centrally. Detect unexpected shells, privilege changes, unusual egress and image drift. Exercise containment: isolate a namespace, revoke an identity and roll back to a known digest.