Ensure entry is removed from CM on secret error.

[vaikas]

Signed-off-by: Ville Aikas vaikas@chainguard.dev

Summary

If there's an entry in the Configmap, say a secret existed and a valid entry was made, but then secret was deleted or modified, remove an existing entry.

Fix #1601

Ticket Link

Fixes

Release Note

[hectorj2f]

@vaikas question: why shouldn’t we get an error of a secret that is been used? Removing something from a configmap sounds like a smart hidden way to me. Am i am missing something?

[vaikas]

@vaikas question: why shouldn’t we get an error of a secret that is been used? Removing something from a configmap sounds like a smart hidden way to me. Am i am missing something?

Sorry, not parsing. Iff there's an error with the CIP, say referring to a bad secret (doesn't exist, it's malformed, etc.). You will get an error and an event for it as well. For example, here we receive an event when a secret is missing:
https://github.com/sigstore/cosign/pull/1605/files#diff-f95503af2405ad769f56a5e3ec662f2d57380441e636ba81ffe33b93e00ea4ebR252

What this PR is addressing is the fact that we have a sequence like this:

1. CIP created, Secret is valid => entry in the CM is made
2. Secret updated (or deleted). At this point the CM is stale, it's holding invalid data.
3. Removal of stale entry in the CM
4. Return an error from the Reconcile loop => Causes an event to be emitted (like the link above).

Does that make sense @hectorj2f , or are you asking something else?

[hectorj2f]

@vaikas thanks. My concern was between steps 1 and 2. I am used to set an ownership reference to the secret, so whenever someone attempts to delete it should get an error that is used by our other resource.

[vaikas]

@hectorj2f yeah, that is usually how we'd do it if we'd be the one controlling the resource. We could add an ownerref but that feels a bit wonky since we don't really own that in this case. But, even if we did that, we would still have to deal with the case where the secret contains invalid data.