feat: allow cross-namespace ConfigMap/Secret for GitRepositoryVerification #1854
Conversation
Signed-off-by: pranshul gupta <[email protected]>
…nfigMap/Secret Signed-off-by: pranshul gupta <[email protected]>
|
I might be mistaken about the intention of this PR, but we don't allow cross-namespace Secret references for a reason. |
Thanks for reviewing! My intention here was mainly to support referencing cosign public keys from a shared ConfigMap in a central namespace (as described in issue #1674), not to bypass any security constraints. Would you be okay with me updating this PR to allow only cross‑namespace ConfigMaps (and keep Secrets strictly namespace‑scoped)? |
To be honest I don't think this change would get through. The usual way to solve your problem is to duplicate the Secret/ConfigMap into the Namespaces where it's consumed. This is common practice with many Flux Secrets but also with Kubernetes Secrets, e.g. pull Secrets. |
|
Sorry but this can't be in Flux. You can't refer to a ConfigMap/Secret in a Kubernetes Deployment from a diffrent namespace, when Kubernetes will allows this then we'll also allow Flux to do the same. |
3 participants
This PR resolves issue #1674.
CrossNamespaceObjectReferencesupport was added inGitRepositoryVerificationto allow referencing public keys from a Secret or ConfigMap in another namespace.verifySignature) to fetch and verify keys from cross-namespace Secret/ConfigMap whenPublicKeyRefis provided.get,list,watch) so the controller can access them.Note: This allows users to store cosign public keys in a central namespace and reference them across multiple Git repositories, instead of duplicating keys in every namespace.