Securing your supply chain: DevSecOps and Kubernetes
Most Kubernetes security work happens too late — inside the running cluster, after the risky artifact is already there. The higher-leverage move is to push security left, into the pipeline, so that what reaches the cluster has already been checked, signed, and constrained.
The container image running in your cluster right now is the end of a long supply chain: base images, third-party libraries, your own code, a build system, a registry, and a deployment pipeline. Any link can be compromised, and by the time a bad artifact is running, your options are all bad ones. DevSecOps is the discipline of moving the checks upstream — treating the pipeline, not the cluster, as the place security is decided. NIST's container-security guidance frames the whole lifecycle this way, from image build to runtime.1
01RBAC is necessary, and not sufficient
Kubernetes' Role-Based Access Control governs who can do what to the API: which subjects can read secrets, create pods, or modify deployments, scoped by namespace or cluster-wide.2 It is essential, and you should apply it with least privilege — no default cluster-admin handed out casually. But notice what RBAC does not do: it says nothing about whether the image you are allowed to deploy is safe, whether the code inside it was tampered with, or whether the container will try to escalate privileges once running. RBAC controls the who; the supply chain is about the what. You need both, and RBAC is only the first.
02Scan the image before the cluster ever sees it
The cheapest place to catch a known vulnerability is in the pipeline, before the image is ever admitted. Automated scanners inspect an image's operating-system packages and application dependencies against public vulnerability databases and flag known CVEs; open-source tools such as Trivy do this in a single CI step and can fail the build on severities you choose.9 The rule that makes this real: the scan gates the pipeline. A critical vulnerability should stop the build, not file a ticket someone reads next quarter. Scanning that only warns is theatre; scanning that blocks is a control.
Pair scanning with slim, current base images — fewer packages mean fewer CVEs to triage — and re-scan on a schedule, because an image that was clean when built accumulates newly-disclosed vulnerabilities while it sits in the registry.
03Secrets: base64 is not encryption
Here is the mistake almost everyone makes once. A Kubernetes Secret stores its data base64-encoded, and base64 is an encoding, not encryption — anyone who can read the Secret object can trivially decode it, and by default Secret data is stored in etcd unencrypted at rest.5 Putting a password in a Secret is not, by itself, protecting it.
Two things close the gap. First, enable encryption at rest for Secret data in etcd, ideally backed by a key-management service, so a stolen etcd snapshot does not hand over every credential.6 Second — and this is the cardinal rule of GitOps-era security — never commit plaintext secrets to Git. Reference them from an external secret manager via a tool like the External Secrets Operator, which syncs values from a vault into the cluster at runtime, so the credential never lives in your repository or your image.10 The manifest in Git should point at a secret; it should never be one.
# base64 is encoding, not encryption -- do NOT treat this as secure,
# and never commit a real value like this to Git.
apiVersion: v1
kind: Secret
metadata: { name: db-credentials }
data:
password: c3VwZXItc2VjcmV0 # trivially decodable04Sign what you ship, run only what you signed
Scanning tells you an image is free of known flaws. It does not tell you the image is the one you built — that no one swapped it in the registry or slipped a malicious layer in during the build. That is the province of artifact signing and provenance. Sigstore's cosign lets your pipeline cryptographically sign every image it produces, and lets the cluster verify that signature at admission, so only artifacts your pipeline actually built are allowed to run.8
Above signing sits the broader question of provenance: a verifiable record of how an artifact was built and from what sources. The SLSA framework defines graduated levels for exactly this, giving teams a ladder from "we sign our releases" up to "the build is tamper-evident and independently verifiable."7 You do not need the top rung on day one. You do need to know which rung you are on.
05Pod Security Standards and immutable infrastructure
Even a clean, signed image can be deployed dangerously — as root, with host mounts, or with the ability to escalate privileges. Kubernetes ships Pod Security Standards (Privileged, Baseline, Restricted) and a built-in Pod Security Admission controller that enforces them per namespace, so a workload requesting dangerous capabilities is rejected at admission rather than discovered later.34 Default your namespaces to Restricted and relax deliberately, per workload, with a reason.
Finally, treat what runs as immutable: the exact artifact you tested is the exact artifact you deploy, identified by content digest rather than a mutable tag like latest. Pinning images by digest guarantees every node pulls the identical bytes you scanned and signed, closing the gap where :latest silently points at something new.12 Immutable images plus disposable nodes (the subject of part four) mean a compromised container is not patched in place — it is replaced by a known-good one.
Shift-left is not a slogan; it is arithmetic. A vulnerability caught in CI costs a build. The same vulnerability caught in production costs an incident. Move the check to where the fix is cheapest.
06Where OcxlyDev lands
Our stance is that a cluster's security is mostly decided before anything reaches the cluster. Give subjects least-privilege RBAC, scan and gate on images, keep real secrets out of Git and encrypt them at rest, sign what you build and verify it at admission, and enforce Pod Security Standards with immutable, digest-pinned images. None of this is exotic — every piece is documented and open-source — and taken together it is the difference between hoping your supply chain is clean and being able to prove it. For teams handling regulated or sensitive data, treat NIST SP 800-190 and the OWASP Kubernetes Top Ten as your checklist, not your reading list.111