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. It is more effective to move the checks earlier, into the pipeline, so that what reaches the cluster has already been scanned, signed, and constrained.
The container image running in your cluster 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 once a bad artifact is running your options are limited. DevSecOps is the practice of moving the checks upstream, treating the pipeline rather than 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 but not sufficient
Kubernetes' Role-Based Access Control governs who can do what to the API: which subjects can read secrets, create pods, or change deployments, scoped by namespace or cluster-wide.2 It is essential, and you should apply it with least privilege, without handing out cluster-admin casually. But RBAC says nothing about whether the image you are allowed to deploy is safe, whether its contents were tampered with, or whether the container will try to escalate privileges once running. RBAC controls who can act; the supply chain is about what you are running. You need both, and RBAC is only the first part.
02Scan the image before the cluster sees it
The cheapest place to catch a known vulnerability is in the pipeline, before the image is admitted. Automated scanners check 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 the severities you choose.9 The point that makes this work is that the scan gates the pipeline: a critical vulnerability should stop the build, not create a ticket for next quarter. A scan that only warns does little; a scan that blocks is a control.
Combine scanning with small, current base images, since fewer packages mean fewer CVEs to handle, 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
This is a common early mistake. A Kubernetes Secret stores its data base64-encoded, and base64 is an encoding, not encryption: anyone who can read the Secret object can decode it, and by default Secret data is stored in etcd unencrypted at rest.5 Putting a password in a Secret does not, on its own, protect 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 expose every credential.6 Second, and this is the main rule in GitOps-era security, never commit plaintext secrets to Git. Reference them from an external secret manager using 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, not contain 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, and 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, or that no one swapped it in the registry or added a malicious layer during the build. That is what artifact signing and provenance are for. 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 built are allowed to run.8
Above signing is 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 this, from "we sign our releases" up to "the build is tamper-evident and independently verifiable."7 You do not need the top level on day one, but you should know which level you are at.
05Pod Security Standards and immutable images
Even a clean, signed image can be deployed in a dangerous way: as root, with host mounts, or able 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 found 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 one you deploy, identified by content digest rather than a moving tag like latest. Pinning images by digest means every node pulls the identical bytes you scanned and signed, and closes the gap where :latest quietly points at something new.12 Immutable images plus disposable nodes (the subject of part four) mean a compromised container is replaced with a known-good one rather than patched in place.
Shift-left is mostly arithmetic. A vulnerability caught in CI costs a build; the same one caught in production costs an incident. Move the check to where the fix is cheapest.
06Where OcxlyDev lands
Our view is that most of a cluster's security is 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 together it is the difference between assuming your supply chain is clean and being able to show it. For regulated or sensitive data, use NIST SP 800-190 and the OWASP Kubernetes Top Ten as a checklist.111