Can someone please provide details on how these secrets are getting populated? I my case its not showing. webhook-certs are working fine

policy-webhook-certs :

kubectl describe secret policy-webhook-certs
Name:         policy-webhook-certs
Namespace:    genesys-system
Labels:       app.kubernetes.io/instance=policy-controller
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=policy-controller
              app.kubernetes.io/version=1.9.0
              control-plane=policy-controller-policy-webhook
              helm.sh/chart=policy-controller-0.1.25
Annotations:  meta.helm.sh/release-name: policy-controller
              meta.helm.sh/release-namespace: genesys-system

Type:  Opaque

Data
====

webhook-certs :

kubectl describe secret webhook-certs
Name:         webhook-certs
Namespace:    genesys-system
Labels:       app.kubernetes.io/instance=policy-controller
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=policy-controller
              app.kubernetes.io/version=1.9.0
              control-plane=policy-controller-webhook
              helm.sh/chart=policy-controller-0.1.25
Annotations:  meta.helm.sh/release-name: policy-controller
              meta.helm.sh/release-namespace: genesys-system

Type:  Opaque

Data
====
server-cert.pem:  794 bytes
server-key.pem:   241 bytes
ca-cert.pem:      855 bytes

cosign:
  secretKeyRef:
    name: ""
  cosignPub:  I have mentioned my public key here in base64 encoded format

Without mentioning secretKeyRef getting the below exception. But I am mentioning the public key in encoded format

Error from server (BadRequest): error when creating ".\statefulset.yaml": admission webhook "policy.sigstore.dev" denied the request: validation failed: secret "" not found: spec.template.spec

Description

Upgrade cosigned chart to install the webhook and the policy webhook.

Hi we are using AKS and configuration has been made to pull the image from ACR by default so that we don't need to create the docker secrets in the namespace

I am getting the below exception when policy controller tries to do that validation. I am sure the image exists and the image is being pulled when I removed the label from the namespace.

Unable to figure out at what place the error is happening

Error from server (BadRequest): error when creating ".\\deployment.yaml": admission webhook "policy.sigstore.dev" denied the request: 
validation failed: GET https://<REPOSITORY>/oauth2/token?scope=repository%3Acosign%2Ftest%3Apull&service=<REPOSITORY>: 
UNAUTHORIZED: authentication required, visit https://aka.ms/acr/authorization for more information.: spec.template.spec.containers[0].image
<REPOSITORY>//cosign/test@sha256:e5de6a1c8ad98d6e6410299f705ae92b7a0e630781f4838c1d25322341e54717

This is related to the open bug: #24

As a workaround for secretKeyRef not resolving, one has to provide following parameters:
--set cosign.cosignKey=‘base64 encode’ --set cosign.cosignPassword='base64 encode' --set cosign.cosignPub='base64 encode'

Even if the secretkeyRef works, I do not want to keep my private key and password in the cluster.
So why in this chart cosignKey and cosignPassword are required. Currently this command complain if all 3 parameters are not provided.

$k get secrets cosigned-cosign-key -o yaml
 data: 
  cosign.key: <>
  cosign.password: <>
  cosign.pub: <>

Ideally shouldn't the webhook only look for public key to validate the signed images?

Trying to deploy the helm chart based on the steps in the README. I keep hitting the following situation.

kubectl run nginx --image nginx -n my-namespace
Error from server (BadRequest): admission webhook "cosigned.sigstore.dev" denied the request: validation failed: secret "\"mysecret\"" not found: spec

I deployed a fresh KIND cluster to verify as well. Here are my steps.

kind create cluster
export COSIGN_PASSWORD=GITHUB_ISSUE
cosign generate-key-pair
kubectl create namespace cosign-system
kubectl create secret generic mysecret -n cosign-system --from-file=cosign.pub=./cosign.pub
helm repo add sigstore https://sigstore.github.io/helm-charts
helm repo update
helm install cosigned -n cosign-system sigstore/cosigned --devel --set cosign.secretKeyRef.name=mysecret
kubectl create -f /tmp/namespace.yaml

Secret exists in the cosign-system ns

kubectl get secret -n cosign-system mysecret
NAME       TYPE     DATA   AGE
mysecret   Opaque   1      4m47s

Cosigned Helm Chart Docs Improperly Use Label/Annotation Interchangeably

In the docs the words "annotation" and "label" are used interchangeably, but are two different constructs in Kubernetes.

From testing, it appears as though to enable the cosigned admission webhook, you need to add cosigned.sigstore.dev/include: "true" as a label, not as an annotation.

Wrong chart name in policy-controller readme.md example
Is
helm install policy-controller -n cosign-system sigstore/policy --devel --set cosign.secretKeyRef.name=mysecret
should be:
helm install policy-controller -n cosign-system sigstore/policy-controller --devel --set cosign.secretKeyRef.name=mysecret

Description

It would be nice when, the sigstore artifacthub helm charts would be marked with a verified publisher flag. Sounds just right for a project like the cosign and rekor.

Description

When deploying cosigned with the current version of the Helm chart (0.1.13) the filesystem is readonly and no volumes are mounted. Therefore errors are generated at run-time when the webhook tries to download artifacts and store them in a local cache

Sample error output

http: panic serving 192.168.172.222:43852: creating root cert pool: retrieving trusted root; local cache may be corrupt: creating cached local store: mkdir /.sigstore: read-only file system\n

http: panic serving 192.168.172.222:44176: initializing tuf: updating local metadata and targets: creating targets dir: mkdir /.sigstore: read-only file system

level=info msg=\"Could not save cache\" error=\"open /.ecr/.config.json.tmp1353667686: no such file or directory

Expected behavior
The Helm chart should mount emptyDir volumes to allow writing to the local cache folders

• /.sigstore
• /.ecr

Note: the /.ecr folder is specific to retrieving images from ECR, we should check if other repositories need different directories.

Getting this error when I deploy my changes into AKS cluster. Unable to understand what's the issue is

Error :

{"level":"warn","ts":"2022-06-09T12:33:10.994Z","logger":"clusterimagepolicy","caller":"webhook/webhook.go:154","msg":"server key missing"}
2022/06/09 12:33:10 http: TLS handshake error from 10.204.8.4:57656: tls: no certificates configured

Note : 10.204.8.4 This is the IP of the node in which the pods is running

Below is the manifest of ValidatingWebhookConfiguration cosigned.sigstore.dev in the cluster

I don't see the CA bundle in the manifest. How it will get attached?

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  annotations:
    meta.helm.sh/release-name: cosigned
    meta.helm.sh/release-namespace: test
  creationTimestamp: "2022-06-09T10:10:02Z"
  generation: 2
  labels:
    app.kubernetes.io/managed-by: Helm
  name: cosigned.sigstore.dev
  resourceVersion: "764086314"
  uid: 72206218-6b23-4e31-88b6-c4e86e46ee83
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: webhook
      namespace: test
      port: 443
  failurePolicy: Fail
  matchPolicy: Equivalent
  name: cosigned.sigstore.dev
  namespaceSelector:
    matchExpressions:
    - key: cosigned.sigstore.dev/include
      operator: In
      values:
      - "true"
    - key: control-plane
      operator: DoesNotExist
  objectSelector: {}
  sideEffects: None
  timeoutSeconds: 10

Question

Curious what people are using to generate the JSON schema, as I'm not sure what I'm doing is the best way.
I've been using

• YAML to JSON from https://jsonformatter.org/yaml-to-json, with the values.yaml
  and
• JSON Schema from https://www.jsonschema.net/app/schemas/0, with the output above to generate the schema

Do other people have better tooling for this?

Description

For the Rekor chart, neither of the two storageClass parameters can be set to non-null values due to the schema specifying the type as null.

The two values in question are:

1. mysql.persistence.storageClass
2. server.attestation_storage.persistence.storageClass

These can be fixed by modifying the schema file to set both types as string.

Description

We can use sigstore's helm-sigstore plugin, or GPG key to sign/verify Helm Chart, wouldn't be nice if we support that?

• https://github.com/sigstore/helm-sigstore
• https://helm.sh/docs/topics/provenance/

Add support for signing charts

Update Helm Install Instructions

• The cosigned helm install instructions make reference to an env value COSING_PASSWORD which looks like a typo.

We publish and sign container images in AWS ECR using cosign and use latest version of policy controller for validation.

We are running AWS EKS version v1.22.9-eks-a64ea69 with nodes v1.22.6-eks-7d68063.

Images are signed using AWS KMS keys and verified using public key stored in ClusterImagePolicy.

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  annotations:
spec:
  authorities:
  - key:
      data: |
        -----BEGIN PUBLIC KEY-----
        ...
        -----END PUBLIC KEY-----
    name: authority-0
  images:
  - glob: '**'

When deploying large helm charts such as kube-prometheus-stack we often get errors like:

Error: Internal error occurred: failed calling webhook "policy.sigstore.dev": Post "https://webhook.cosign-system.svc:443/validations?timeout=10s": context deadline exceeded

and issues with fetching digests:

invalid value: [<AWS_ACCOUNT_ID>.dkr.ecr.eu-north-1.amazonaws.com/prometheus/node-exporter:v1.3.1](http://<AWS_ACCOUNT_ID>.dkr.ecr.eu-north-1.amazonaws.com/prometheus/node-exporter:v1.3.1) must be an image digest: spec.containers[0].image

Both issues happen at random.

Some tests done:

• tried sha256 sum image pining
• tried publishing and signing just platform linux/amd64 container image to reduce size of digest
• tried scaling to multiple replicas and increasing cpu/memory limits for webhooks but didn't change a thing
• checked cloudwatch for performance issues and it looks ok
• tried running images manually with kubectl run and worked ok

Any debugging tips much appreciated.

My key is passwordless (as cosign lets me create as such).

But helm chart doesn't accept that.
If I drop cosign.password field or set it to empty string, it still fails.

helm install cosigned -n cosign-system sigstore/cosigned --devel --set webhook.secretKeyRef.name=mysecret
Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in Secret.data.cosign.key, unknown object type "nil" in Secret.data.cosign.password, unknown object type "nil" in Secret.data.cosign.pub]

Publish Chart releases to Rekor using the Helm Sigstore plugin

{"level":"error","ts":"2022-06-17T10:44:39.559Z","logger":"clusterimagepolicy.ConversionWebhook","caller":"controller/controller.go:566","msg":"Reconcile error","knative.dev/traceid":"65c9274c-9590-4148-a43d-f106ec0dbd37","knative.dev/key":"clusterimagepolicies.policy.sigstore.dev","duration":0.000220403,"error":"custom resource "clusterimagepolicies.policy.sigstore.dev" isn't configured for webhook conversion","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:566\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]/controller/controller.go:543\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:491"}

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.

Description

allow specifying ctlog log prefix via helm chart

the log prefix is passed into the createctconfig job, and we need to plumb through the value to a flag in the ctlog helm chart

Description

logserver takes the database name from a secret
https://github.com/sigstore/helm-charts/blob/main/charts/trillian/templates/trillian-log-server/deployment.yaml#L84

logsigner takes the database name a plaintext
https://github.com/sigstore/helm-charts/blob/main/charts/trillian/templates/trillian-log-signer/deployment.yaml#L79

The two should read in the database name the same way, as otherwise, there is no reason to hide the database name in a secret

Description

I installed cosigned admission webhook from helm chart, it works for public registry like docker hub public repo, but doesn't work for private registry, in my case is artifactory registry. Even I already put cosign public key in cosign-system namespace secret.

Matt Moore gave me a full stack yaml file, I uninstall helm chart and install from the yaml file fixed the issue.
https://gist.github.com/mattmoor/7efb317d3ffedf697ba422f81de31d4e

Description

You defined duplicated keys in deployment_policy_webhook.yaml for the cosigned helm chart which results in an error while using fluxcd HelmRelease.

If you just use Helm, helm will ignore duplicated keys but fluxcd yaml parser is sensitive and exit with

Helm install failed: error while running post render on files: map[string]interface {}(nil): yaml: unmarshal errors: line 43: mapping key "serviceAccountName" already defined at line 31 line 113: mapping key "terminationGracePeriodSeconds" already defined at line 32

fluxcd/flux2#1522

Description
Hi,
I've been trialling policy-controller on a small k8s cluster on digitalocean, trying to validate an image with a keyless signature, built and signed on github and hosted in a private registry (digitalocean registry).

Basing it on the instructions from the chart's readme and the documentation, I installed the controller with:

helm upgrade --install --create-namespace -n cosign-system --version 0.2.1 policy-controller sigstore/policy-controller --set policywebhook.resources.requests.cpu="50m" --set webhook.resources.requests.cpu="50m"

(pin version instead of devel, skip the secret that as far as I understand it's optional fallback behaviour, change limits b/c my worker nodes are really small).

Once the pods are available I add a policy like so:

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: image-policy
spec:
  images:
  - glob: "**"
  authorities:
    - keyless:
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subjectRegExp: https://github.com/MYORG/\S+/.github/workflows/\S+@refs/heads/main

and enable on a namespace adding label as per docs.
I then test by applying a deployment which pod image is keyless-signed via GH workflow (and stored in private registry). I would expect a pass, but instead the error I get back is:

Error from server (BadRequest): error when creating "test-deploy.yml": admission webhook "policy.sigstore.dev" denied the request: validation failed: failed policy: image-policy: spec.template.spec.containers[0].image
registry.digitalocean.com/guanciale/servatrice@sha256:REDACTED signature keyless validation failed for authority authority-0 for registry.digitalocean.com/MYORG/MYIMAGE@sha256:REDACTED: no matching signatures:
creating cached local store: mkdir /.sigstore: read-only file system
 creating cached local store: mkdir /.sigstore: read-only file system

I would have expected a reasonably plain setup with the latest version to only fail with errors that suggest my config changes might be at fault - but I can't see how this one is related.

I'm not sure what I might be doing wrong here or where to look for, any suggestion welcome.

Version

policy-controller chart 0.2.1

The current cosigned chart does not declare a valid semver version. When retrieving the chart as an OCI artifact, non valid semver tags are ignored and thus can never be retrieved

Rekor helm chart would become lighter and easier to maintain if you can use helm chart dependencies for redis and mysql.

Is there any reason why redis and mysql are baked into the rekor chart ? Perhaps there is any specific configuration for those dependencies, as I saw you are not using the bitnami charts.

Hi,

When trying to run an image in a namespace that is "cosigned enabled" , the webhook throws an error :

Error from server (BadRequest): admission webhook "cosigned.sigstore.dev" denied the request: validation failed: invalid value: signed-image:master must be an image digest: spec.containers[0].image

The image is signed with cosign and verified with cosign using the same public key that is used for cosigned on K0s.

The same also applies when trying to deploy an unsigned image.

Any suggestion on what is wrong?

I followed this sigstore tutorial to produce my ClusterImagePolicy yaml. I received the following error:

cosign % kubectl apply -f cluster-image-policy-1.yaml
error: error validating "cluster-image-policy-1.yaml": error validating data: ValidationError(ClusterImagePolicy.spec.authorities[0]): unknown field "attestations" in dev.sigstore.cosigned.v1alpha1.ClusterImagePolicy.spec.authorities; if you choose to ignore these errors, turn validation off with --validate=false

My clusterimagepolicy yaml is also provided to help reproduced this error.

apiVersion: cosigned.sigstore.dev/v1alpha1
kind: ClusterImagePolicy
metadata:
  name: image-policy-1
spec:
  images:
  - regex: ".*"
  authorities:
  - attestations:
    - predicateType: custom
      name: customkey
      policy:
        type: cue
        data: |
          import "time"
          before: time.Parse(time.RFC3339, "2023-01-01T00:00:00Z")
          predicateType: "cosign.sigstore.dev/attestation/v1"
          predicate: {
            Data: "Vulnerability\n"
            Timestamp: <before
          }
    key:
      data: |
        -----BEGIN PUBLIC KEY-----
        MFkwEwYHKoZIzj0CAQYIKoZIzj0ABQcDQgAE4rMj/48jzxvqn2NQeNyr97go3YVm
        rnu1GUmsJDoAhbmurg5xMBxMIUBDGiiIfD8S2VvQ7MRVXKyXxipGartSng==
        -----END PUBLIC KEY-----

My installation used helm chart and the version is 1.8.0 and my installation script is also shown below

cosign % helm list -n cosign-system
NAME    	NAMESPACE    	REVISION	UPDATED                             	STATUS  	CHART          	APP VERSION
cosigned	cosign-system	1       	2022-05-09 01:17:36.318565 +0800 CST	deployed	cosigned-0.1.18	1.8.0

# installation script
kubectl create namespace cosign-system
kubectl create secret generic mysecret -n cosign-system \
--from-file=cosign.pub=./cosign.pub \
--from-file=cosign.key=./cosign.key \
--from-literal=cosign.password=${COSIGN_PASSWORD}

I also checked the the source clusterimagepolicy_type.go and I don't think the yaml file is wrong. Any advice is highly appreciated. I also opened a bug in sigstore/cosign

Description

@k4leung4 and I noticed the image tag default for the Fulcio chart is out of date. We should do a pass on all charts and make sure image tags are set to the most recent release.

Question
Hi guys.

1. I've created AWS KMS key.
2. I've run cosign generate-key-pair --kms awskms:///alias/mykey
3. I've gotten Public key written to cosign.pub

During the deploying helm chart I see that I have to set not only cosign.pub but cosign.key too.

Question - What the cosign.key should I set If I'm using AWS KMS?

I am asking this because. We are trying to apply cosign to our enterprise application. Where there is a lot of namespaces and each namespace has a dozen apps running in them. So even if one app in the namespace has non singed image it will block the working of the apps. Will there be any feature to run cosign in passive mode, just logging issue without actively blocking it? So that we can slowly enable to active mode when we are ready

[Environment]

• GKE v1.21.10
• Helm CLI: v3.6.2
• cosigned helm chart version v1.8.0

1. Deploy GKE standard cluster v1.21.10-gke.2000
2. Deploy Cosigned's helm chart with the following script:

kubectl create namespace cosign-system

kubectl create secret generic mysecret -n cosign-system \
--from-file=cosign.pub=./cosign.pub \
--from-file=cosign.key=./cosign.key \
--from-literal=cosign.password=${COSIGN_PASSWORD}

helm install cosigned -n cosign-system sigstore/cosigned --devel \
--set cosign.secretKeyRef.name=mysecret 

3. Running logs command to check cosigned-webhook and we'll see repeated errors below.

kubectl logs -n cosign-system cosigned-webhook-6c68bfb587-6c7hb

{"level":"error","ts":"2022-05-08T17:18:08.942Z","logger":"cosigned.DefaultingWebhook","caller":"controller/controller.go:566","msg":"Reconcile error","commit":"9ef6b20","knative.dev/traceid":"00a8cb0b-180f-45a6-847c-6421a9eaa7b8","knative.dev/key":"cosign-system/webhook-certs","duration":0.000132104,"error":"error retrieving webhook: mutatingwebhookconfiguration.admissionregistration.k8s.io \"\\\"cosigned.sigstore.dev\\\"\" not found","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:566\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]/controller/controller.go:543\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:491"}
{"level":"error","ts":"2022-05-08T17:18:08.944Z","logger":"cosigned.ValidationWebhook","caller":"controller/controller.go:566","msg":"Reconcile error","commit":"9ef6b20","knative.dev/traceid":"76a39714-c3f6-4491-a99f-5548e0a50d38","knative.dev/key":"cosign-system/webhook-certs","duration":0.000152002,"error":"error retrieving webhook: validatingwebhookconfiguration.admissionregistration.k8s.io \"\\\"cosigned.sigstore.dev\\\"\" not found","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:566\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]/controller/controller.go:543\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:491"}

I tested under such error, even I enable cosign policy in my namespace. It is not working as expected. Any comment is highly appreciated.

Description

Currently Fulcio chart uses an object for the Fulcio config content (.Values.config.content). This means that values are merged with default instead of overriding defaults when applied. The result is that its impossible to remove the default OIDC issuer of https://kubernetes.default.svc using the Fulcio chart.

We should use a string for this field so that changes completely override the config. Eg

config:
+ content: |-
- content:
    { "foo": "bar" }

Without the ability to set this field, the default value for this command line flag rekor.sigstore.dev gets returned in the signed log info checkpoints.

@sabre1041 any guidance on where to add this?

Let's extract the templates under the rekor chart into their own charts, so that we can just include them as dependencies for both rekor and fulcio

cc @sabre1041

Question

hi. :)
I checked the Configuring static authorities function in the sigstore documentation, and I confirmed that the function is also included in the code of policy-controller.
This is a feature I really need.
However, it seems that this function is not reflected in this helm-charts yet.
When will this feature be reflected?

I hope that will be reflected soon.
thank you !!

Description

Having a Fulcio chart would really help in spinning up the whole sigstore project using Helm :D

admission webhook "policy.sigstore.dev" denied the request: validation failed: one of verifier or root certs is required

What does the below error mean? Does it have any impact on the working?

{"level":"error","ts":"2022-06-20T08:34:29.247Z","logger":"clusterimagepolicy.ConversionWebhook","caller":"controller/controller.go:566","msg":"Reconcile error","knative.dev/traceid":"2d5f13fe-d3ec-4ceb-943c-9aab83337bd4","knative.dev/key":"clusterimagepolicies.policy.sigstore.dev","duration":0.049818436,"error":"failed to update webhook: customresourcedefinitions.apiextensions.k8s.io "clusterimagepolicies.policy.sigstore.dev" is forbidden: User "system:serviceaccount:genesys-system:policy-controller-policy-webhook" cannot update resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:566\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]/controller/controller.go:543\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:491"}

Rename of the repository from sigstore-charts to helm-charts to make it more descriptive on the purpose and the content

Today Cosigned Admission Webhook can be used with generated keys and potentially with K8s secret

# generate a key-pair in Kubernetes Secret
cosign generate-key-pair k8s://[NAMESPACE]/[NAME]

but cosigned webhook can't use keys from persisted sources. Please add functionality to support keys from other sources like Azure Key Vault, AWS KMS, Google Cloud KMS, Hashicorp Vault. Thanks

Description

cosigned webhook was renamed to policy-controller, so we should rename the chart to reflect this here.
Also some of the variables were changed to reflect this, for example:
https://github.com/sigstore/helm-charts/tree/main/charts/cosigned#enabling-admission-control

is now policy.sigstore.dev/include instead of cosigned.sigstore.dev/include

There's probably others, but just jotting above down since it's not simply a matter of renaming the chart :)

Hello,

Thanks for your great work.

How to reproduce

I use a private registry as a proxy cache to pull container images. Authentication is enforced. When I configure the values.yaml for the policy-controller I faced an issue that it's not possible to reference the required docker secret.

Minimum example:

policywebhook:
  image:
    repository: registry.example.com/gcr.io/projectsigstore/policy-webhook
webhook:
  image:
    repository: registry.example.com/gcr.io/projectsigstore/policy-controller

Expected behavior

values.yaml:

imagePullSecrets:
  - name: my-secret
policywebhook:
  image:
    repository: registry.example.com/gcr.io/projectsigstore/policy-webhook
webhook:
  image:
    repository: registry.example.com/gcr.io/projectsigstore/policy-controller

This should set the required imagePullSecrets in both deployments of policy-webhook and webhook.

Actual behavior

There is no possibility to configure imagePullSecrets in both deployment template files.

Description

Add tests to ensure upgrades are smooth between versions. We should verify that breaking changes are not introduced when changing the charts, at least to avoid doing it as much as possible.

https://github.com/sigstore/helm-charts/tree/72bac9e947fba3bff31d59ad124a277d92348a5f/charts/cosigned#:~:text=kubectl%20create%20secret%20generic%20mysecret%20-n%20%5C%0Acosign-system%20--from-file%3Dcosign.pub%3D./cosign.pub%20%5C%0A--from-file%3Dcosign.key%3D./cosign.key%20%5C%0A--from-literal%3Dcosign.password%3D%24COSIGN_PASSWORD

I am trying to understand why the cosigned webhook requires my private key and password. I thought those should not leave my computer. It would be good to clarify in the instructions, I think.

Hello.

Description
I set it to pass without validation check for all image patterns, but it was not distributed due to validation failed.

This is the ClusterImagePolicy I used.

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
name: image-policy-default
spec:
images:
- glob: "**"
authorities:
- static:
action: pass

The image I want to deploy.

spec:
  - name: mysql
    image: mysql:latest
    imagePullPolicy: Always

Error message.
Error from server (BadRequest): error when creating "test.yaml": admission webhook "policy.sigstore.dev" denied the request: validation failed: invalid value: mysql:latest must be an image digest: spec.template.spec.containers[0].image
Can you tell me why this error occurs?

Version
policy-controller version: 0.2.1

Description

I'm making a bunch of minor changes to the helm charts and would like to be able to more easily bunch versions of the helm charts to pick up new dependent chart versions.
Would be nice to have permissions to assign reviewers and merge permissions.

@dlorenc @cpanato

Description
I follow the instruction on https://github.com/sigstore/helm-charts/tree/main/charts/cosigned to install cosigned admission webhook in eks cluster, got below error when I run "helm install cosigned -n cosign-system sigstore/cosigned --devel --set webhook.secretKeyRef.name=mysecret".

Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in Secret.data.cosign.key, unknown object type "nil" in Secret.data.cosign.password, unknown object type "nil" in Secret.data.cosign.pub]

And it works after pass below parameters value in the above command line:

--set cosign.cosignKey=‘base64 encode’ --set cosign.cosignPassword='base64 encode' --set cosign.cosignPub='base64 encode'