sigstore / cosign-gatekeeper-provider

🔮 ✈️ to integrate OPA Gatekeeper's new ExternalData feature with cosign to determine whether the images are valid by verifying their signatures

sigstore framework

sigstore/sigstore contains common Sigstore code: that is, code shared by infrastructure (e.g., Fulcio and Rekor) and Go language clients (e.g., Cosign and Gitsign).

This library currently provides:

• A signing interface (support for ecdsa, ed25519, rsa, DSSE (in-toto))
• OpenID Connect fulcio client code

The following KMS systems are available:

• AWS Key Management Service
• Azure Key Vault
• HashiCorp Vault
• Google Cloud Platform Key Management Service

For example code, look at the relevant test code for each main code file.

Fuzzing

The fuzzing tests are within https://github.com/sigstore/sigstore/tree/main/test/fuzz

Security

Should you discover any security issues, please refer to sigstores security process

For container signing, you want cosign

cosign-gatekeeper-provider's Issues

Not able to verify container image in my k8s cluster

Hi Team

I would like to verify my container images before deploying to pod in my k8s cluster.
I am trying to achieve this with cosign-gatekeeper-provider i.e https://github.com/sigstore/cosign-gatekeeper-provider
I have signed the image using cosign but I am not able to verify images when I try to deploy pod using manifest in my cluster.

I am getting following error:-
error when creating “policy/examples/valid.yaml”: admission webhook “validation.gatekeeper.sh” denied the request: [cosign-gatekeeper-provider] invalid response: {“errors”: [], “responses”: [], “status_code”: 200, “system_error”: “VerifyImageSignatures: one of verifier or root certs is required”}

I am able to verify container images using commands on my local command line i.e cosign verify .(But not inside k8s cluster). Looks like keys/cert information are not propagated to cluster

Anything else you would like to add:
I am not sure whether I should put this issue here or on cosign.

Environment:

Gatekeeper version:3.8.1

Security Policy violation Branch Protection

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch main

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Verifying images using a generated public key

Description

Hi!

We'd like to have an opportunity to pass our own Cosign public key generated with cosign generate-key-pair to the provider. To use it the same way as 'cosign verify --key ...’

Expectations:

1. Generate a key pair using cosign generate-key-pair
2. Sign an image
3. Create a k8s secret/configmap for cosign.pub
4. Pass the secret/configmap to cosign-gatekeeper-provider deployment
5. Verify the images using the public key

Change `go` base image in `Dockerfile`

As per the discussion in there: #24 (review).

Instead of using go:1.20 as the base image in the Dockerfile, the proposal is to use cgr.dev/chainguard/go.

If there is an agreement with that, let's have a dedicated PR opened for that.

Additionally, some questions top of mind with that:

1. Why rekor or fulcio are using golang:1.20 and not
2. Based on 1., do we want to have this current project not doing like the other projects?
3. In the Dockerfile, the base image is in an ARG, which will prevent dependabot (#21) to update any update of this base image, do we also want to change that?
4. In the other projects, sha is used for the go:1.20 image, not here, should we do that here too?

How to provide a cosign public key for verification?

Question
Dear community,
could somebody guide me how to provide the cosign public key for image verification for cosign-gatekeeper-provider?
My public key is available with http schema. (http url file)

As I can see from the source code, the only available method is keyless:
https://github.com/sigstore/cosign-gatekeeper-provider/blob/main/provider.go#L85

But I might miss something, that's why gentle requesting for help.

Thank you,
Pasha.

`golangci-lint` issues: `G114: Use of net/http serve function that has no support for setting timeouts (gosec)`

In the current state of this repo, any new PR will fail because of this error below in the golangci-lint job:

G114: Use of net/http serve function that has no support for setting timeouts (gosec)

Cache for verification results

Description

One issue that may arise as we start using this provider in production is that if the provider can't reach the registry or KMS it will fail. It would be like if we used imagePullPolicy: true.

Results (at least successful) should be possible to cache and have a TTL.

Maybe a CRD could be used to store the cache results as well?

What's the status on the project?

Question

Hi there! This project looks awesome, but I am wondering what the short to midterm roadmap on it is. I see it is marked as not production ready. Are there any production ready projects that could help us check image signatures on admission with gatekeeper at this point?

What would you say are the main barriers to this project becoming ready for production. I noticed also that it currently can only verify images signed and logged on Reko; is there scope for adding PRs to also support regular private / public key signed images?

We are interested in the prospect of helping out here, so we can agree on some areas for us contribute 😄

Additional verification methods

Description

Hi again! Thanks for the really awesome job you are doing!

I'm looking into using this together with Azure Key Vault and Azure Container Registry. In my case, each namespace will have a separate key in Key Vault and the identity used by the provider will have verify access to each key.

My idea is to add some config parameters to the provider to be able to configure how the verification is done and configured, but before starting anything I'd like to understand what plans you already have to make sure I align with them in the best possible way.

Would you like some kind of formal proposal from me or something like that? Or maybe you don't want to provide those kinds of features with the provider and only use it as an example?

Keep up the great work! 🚀👍🥇

How to set a public key to provider cache?

When I have deployed the provider, template and constraint, but I encounter an error (response: {"errors": null, "responses": null, "status_code": 400, "system_error": "key is not found in provider cache"}) when trying to deploy the example yaml file. How can I set the public key in the cache? thanks..

Add support for verifying attestations

Description

Currently the provider only checks for Image Signatures. It would be nice if the provider could also check attestations. This could be mutually exclusive, both at the same time, or perhaps optional flags for attestation/signatures.

release process: make goreleaser work again

Description

We already have a .goreleaser.yaml config, but I think GitHub workflow action is missing. Let's fix this! So we can release the initial version of v0.1.0 after some of the PRs have been tackled.

Cache KMS and registry credentials

Description

Right now, if I'm not mistaken, new credentials will be configured for each time we reach out to the KMS or registry.

To make sure that we don't get rate limited, these credentials should be cached.

Allow the Rekor URL to be configured

Currently the cosign.VerifyImageSignatures call will try to use either bring-your-own PKI chain if specified via environment variable SIGSTORE_ROOT_FILE or use the public Fulcio chain; as instructed by the cosign.CheckOpts provided. A signature verifier is created with these details and used to verify the OCI signature.

As the Rekor Client in the cosign.CheckOpts is not nil, the code will (in the absence of a prior error), reach out to the default public Rekor to VerifyBundle and tlogValidateCertificate. The only way to use cosign-gatekeeper-provider currently requires using the public good Rekor transparency log.

Please allow the Rekor URL to be configurable so that the provider is usable in circumstances where reaching out to a public Rekor instance is not viable.

I am happy to create a PR if this suggestion is accepted.

Release job process and image push

Question
What are the plans for the release job for this project?
will we use:

• github actions to ruin the release?
• cloudbuild?

and to where we will push the images?

• to ghcr.io
• or to the project sigstore google project?

to sign the images/blobs

• we will use keyless
• or we will generate a public/private key?

when we agree on those I will setup the project to match what we agree

Support Gatekeeper v3.11 External Data Beta API

Description

The provider is not compatible with Gatekeeper v3.11+:

$ k apply -f https://raw.githubusercontent.com/sigstore/cosign-gatekeeper-provider/main/manifest/provider.yaml
Warning: externaldata.gatekeeper.sh/v1alpha1 is deprecated. Use externaldata.gatekeeper.sh/v1beta1 instead.
Error from server: error when creating "https://raw.githubusercontent.com/sigstore/cosign-gatekeeper-provider/main/manifest/provider.yaml": admission webhook "validation.gatekeeper.sh" denied the request: only HTTPS scheme is supported for Providers

From here:

starting with Gatekeeper v3.11.0, TLS or mutual TLS (mTLS) via HTTPS protocol are required between Gatekeeper and external data providers with a minimum TLS version of 1.3.

Would need to figure out the best way to supply the provider with rotating certs. They could just be mounted from a Secret. The caBundle field in the Provider spec will also need to updated with the CA cert chain that signed the provider's server cert.

From here:

To verify the authenticity of the Gatekeeper certificate, the external data provider must have access to Gatekeeper's CA certificate.

It should be the recommendation to run the provider in the gatekeeper-system namespace so the provider can access the Gatekeeper CA in the gatekeeper-webhook-server-cert Secret.

imagePullSecret support

Looking at the examples, there is not imagePullSecret support currently? This is needed for things such as gitlab repo's where each project is protected.

Broken link in README

Description
The first cosign link in the README.md leads to: https://github.com/sigstore/cosign-gatekeeper-provider/blob/main/github.com/sigstore/cosign, however this is a 404.

I assume the link should go to: https://github.com/sigstore/cosign ?