search

sigstore / helm-charts

Helm charts for sigstore project
Apache License 2.0
65 stars 93 forks source link

tuf-secret-copy-job couldn't patch already existing secrets #728

Closed xoanmi closed 6 months ago

xoanmi commented 6 months ago

Description

The tuf-secret-copy-job could not patch the secrets that already exist.

Chart version: v0.6.46

Warning: resource secrets/fulcio-server-secret is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.Error from server (Forbidden): error when applying patch:{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"data\":{\"cert\":\"<MY_CERT>\"},\"kind\":\"Secret\",\"metadata\":{\"annotations\":{},\"creationTimestamp\":\"2024-03-21T15:14:02Z\",\"name\":\"fulcio-server-secret\",\"namespace\":\"sigstore\",\"resourceVersion\":\"18957114\",\"uid\":\"e7c113b3-9365-4b3f-aea0-046726ed52f3\"},\"type\":\"Opaque\"}\n"}}}to:Resource: "/v1, Resource=secrets", GroupVersionKind: "/v1, Kind=Secret"Name: "fulcio-server-secret", Namespace: "sigstore"for: "STDIN": secrets "fulcio-server-secret" is forbidden: User "system:serviceaccount:sigstore:tuf-secret-copy-job" cannot patch resource "secrets" in API group "" in the namespace "sigstore"
vipulagarwal commented 6 months ago

@xoanmi thanks for bringing this up. The scaffold secrets copy job can probably get rid of existing secrets via a check. This has definitely caused me a sheer amount of pain when re-deploy scaffold on existing namespaces.

There is also an expectation that if you are creating certain namespaces via scaffold helm release then an uninstall and re-install shall get rid of the secrets anyway.

I am assuming that has been the case in your situation?

xoanmi commented 6 months ago

thanks for bringing this up. The scaffold secrets copy job can probably get rid of existing secrets via a check. This has definitely caused me a sheer amount of pain when re-deploy scaffold on existing namespaces.

There is also an expectation that if you are creating certain namespaces via scaffold helm release then an uninstall and re-install shall get rid of the secrets anyway.

I am assuming that has been the case in your situation?

Not really. Our is a cosmetic issue. When redeploying the same helm with slightly different parameters, the job is recreated and tries to patch some of the secrets. As it can't, the job fails even if the secret is already present and the services are running correctly.

I've opened a PR to add the needed permissions on the cluster role --> #729

vipulagarwal commented 6 months ago

It all makes sense, thanks for the PR