You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I would like to see a Secrets Provider MutatingAdmissionWebhook/Controller that processes all Secrets in a given Namespace. If the Secret contains Conjur-specific attributes/annotations, it could automatically handle retrieving those secret's values from Conjur. The Controller portion would be necessary to handle updates to those Secrets based on changes on the Conjur side. We're looking for this because creating CronJobs for potentially many Secrets (due to #236) in a given Namespace could become unruly very fast, and it allows for more of a single configuration point.
Describe the solution you would like
This is inspired by how the cert-managerIssuer works.
The idea would be to:
Have a CRD or configuration to enable a Namespace-level Secrets Provider. This would be where you'd configure:
The Namespace-level Secrets Provider would observe:
Existing Secrets - and periodically query Conjur (or register a webhook or something similar) for updated values that'd get propagated into the existing Secrets
Handle incomingSecrets as they are introduced into the Namespace, by processing them should they contain the conjur-map section, or potentially some additional attributes. Alternatively, this could be based on a new CRD that get's transformed through this process into a Kubernetes Secret
The text was updated successfully, but these errors were encountered:
Hi @tomcruise81
Thanks for submitting this enhancement!
We will take a look at this request. If you want to submit a PR for this, please see the Contributors Guild
Is your feature request related to a problem? Please describe.
I would like to see a Secrets Provider MutatingAdmissionWebhook/Controller that processes all
Secrets
in a givenNamespace
. If theSecret
contains Conjur-specific attributes/annotations, it could automatically handle retrieving those secret's values from Conjur. The Controller portion would be necessary to handle updates to thoseSecrets
based on changes on the Conjur side. We're looking for this because creatingCronJobs
for potentially manySecrets
(due to #236) in a givenNamespace
could become unruly very fast, and it allows for more of a single configuration point.Describe the solution you would like
This is inspired by how the cert-manager
Issuer
works.The idea would be to:
Namespace
-level Secrets Provider. This would be where you'd configure:Namespace
-level Secrets Provider would observe:Secrets
- and periodically query Conjur (or register a webhook or something similar) for updated values that'd get propagated into the existingSecrets
Secrets
as they are introduced into theNamespace
, by processing them should they contain theconjur-map
section, or potentially some additional attributes. Alternatively, this could be based on a new CRD that get's transformed through this process into a KubernetesSecret
The text was updated successfully, but these errors were encountered: