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

[xoanmi]

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]

@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]

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]

It all makes sense, thanks for the PR