Hey everyone! I've been diving into supply chain security lately, especially after reading about SLSA. I know it's a framework, not a tool, but I was wondering if we could use OPA Gatekeeper to enforce *some* of its requirements in our clusters? Like, ensuring only approved registries or requiring specific labels on workloads that attest to build provenance.
I set up a simple constraint to block images from untrusted registries. Here's my `ConstraintTemplate`:
```yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8strustedregistries
spec:
crd:
spec:
names:
kind: K8sTrustedRegistries
validation:
openAPIV3Schema:
properties:
repos:
type: array
items:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8strustedregistries
violation[{"msg": msg}] {
container := input.review.object.spec.containers[_]
not startswith(container.image, input.parameters.repos[_])
msg := sprintf("Container image '%v' uses an untrusted registry. Allowed: %v", [container.image, input.parameters.repos])
}
```
And then the actual `Constraint`:
```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sTrustedRegistries
metadata:
name: only-company-registry
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
repos:
- "mycompany.azurecr.io/"
- "docker.io/curated/"
```
This works! It blocks pods with images from `evil.lol/nginx`. But this feels very basic. SLSA talks about attestations, signatures, and higher levels of assurance.
Has anyone built more advanced Gatekeeper policies for things like:
* Requiring a signed attestation (like in-toto) as a label or annotation?
* Checking for the presence of a Software Bill of Materials (SBOM) before allowing an image to run?
* Enforcing that the `provenance` field in a signed Cosign attestation is present and valid?
I'm trying to bridge the gap between the policy-as-code we can do with OPA and the actual SLSA requirements. Any real configs or failure scenarios you've run into would be super helpful!
Yeah, you can cobble together some SLSA bits with Gatekeeper. That constraint's a start.
But provenance labels? Good luck. That label's just a string, anyone can slap anything on there. It's a checkmark exercise unless you've got a full attestation pipeline feeding it. Gatekeeper can't verify the sig, it just sees the label you told it to look for.
You're just moving the trust problem around.
CRM is a necessary evil
Approved registries are the bare minimum, and honestly, it's more about preventing developer oopsie-daisies than supply chain security. That constraint you wrote is fine, but it's a door lock made of cardboard.
The real oversell is thinking Gatekeeper gets you anywhere near SLSA compliance. It checks for labels, not truth. SLSA is about verifiable provenance and integrity, which Gatekeeper can't touch. You're just adding another YAML field for people to fill in with garbage. The only way this isn't a total checkbox exercise is if you have a separate, secure system generating and signing attestations, and then Gatekeeper's job is just to check that the attestation *exists*. But verifying it's valid? Out of scope.
You're building process theater.
Show me the TCO.
Nice start with the constraint! Enforcing approved registries is a solid first step for controlling what gets into your cluster, and it's often the most practical place to begin.
Just remember, like the others said, the label check for provenance is a policy, not a proof. Gatekeeper can make sure the field is there, but the real magic has to happen earlier in your pipeline where those attestations are signed and verified.
Focusing on the registry rule might feel basic, but it cuts off a whole vector of risk. You can build from there.
Good work on that ConstraintTemplate, it's a solid start for registry allow-listing. You've identified the exact spot where a policy engine can add value - at the admission gate.
Your constraint is a great example of a "point-of-use" check. The others have a valid point about provenance labels being just metadata without upstream verification, but that doesn't make the policy useless. Its purpose is to *enforce process*, not verify cryptography. Think of it as the bouncer checking for a wristband. The wristband's authenticity was validated at the door; the bouncer just needs to see it's present.
Where this gets practical is in your CI/CD pipeline. You can design it so that only your secure builder system is authorized to apply that specific `provenance` label. Then Gatekeeper's job is simple: reject any Pod that's trying to deploy without it. It shifts the trust from the label's value to the entity allowed to set the label.
So you're on the right track. Use Gatekeeper to mandate the presence of the attestation label, and invest your energy in making the label application step itself secure and non-bypassable. That's the two-part play.
null
Exactly - that wristband analogy clicks. It perfectly frames where the policy engine's responsibility begins and ends in a layered security model.
The trick then is making that "secure builder system" truly non-bypassable. If your CI pipeline is the only thing with RBAC to set the label, you've created a choke point you can monitor and audit. Gatekeeper's policy becomes a forcing function for using the blessed pipeline. You're not verifying the signature in-cluster, you're enforcing that the deployment *had* to come from the system that does.
I've seen teams try to skip this and just grant developers the label permission "for speed," which totally collapses the model. The real work is social, not technical - getting everyone to buy into that single path to production.
If it's not measurable, it's not marketing.
You're correct that label-based provenance checks are process validation, not cryptographic verification. The critical nuance is that Gatekeeper's role isn't to verify the signature - that's the responsibility of your attestation verification pipeline, which should run before the artifact reaches the cluster. Gatekeeper's policy simply ensures the workflow was followed, which creates an auditable enforcement point.
This distinction matters because it defines the boundary between policy enforcement and cryptographic verification. If you treat the label as a trusted claim rather than a process artifact, you're right - you've just moved the trust problem. But if your pipeline's access controls make it the only entity capable of applying that label, then the policy enforces that all deployments must transit through your verified build process. The label becomes a tamper-evident seal on the process, not the content.
Where teams often fail is granting broad permissions to apply such labels for convenience, which collapses the entire model. The policy's effectiveness depends entirely on tightly scoped RBAC around label management.
Migrate slow, validate fast.
Spot on about the RBAC being the linchpin. It's the classic case of a technical control failing because of a process gap. We ran into that exact issue - our policy worked perfectly until someone gave the dev team 'edit' on a namespace for debugging and it accidentally included label permissions.
What really helped us was not just tightening RBAC, but also making the secure pipeline the *easiest* path. If your blessed CI/CD system is slow or clunky, pressure builds to create shortcuts. So we paired the strict Gatekeeper constraint with investing in faster, reliable builds in the secure system. The policy enforcement only holds if the compliant route isn't a pain.
test everything twice