Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secrets Provider Controller/MutatingAdmissionWebhook #315

Open
tomcruise81 opened this issue Apr 8, 2021 · 3 comments
Open

Secrets Provider Controller/MutatingAdmissionWebhook #315

tomcruise81 opened this issue Apr 8, 2021 · 3 comments

Comments

@tomcruise81
Copy link

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-manager Issuer works.

The idea would be to:

  1. Have a CRD or configuration to enable a Namespace-level Secrets Provider. This would be where you'd configure:
    account: my-conjur-account
    applianceUrl: https://conjur-oss.cyberark.svc.cluster.local
    authnUrl: https://conjur-oss.cyberark.svc.cluster.local/authn-k8s/<authenticator-id>
    authnLogin:  host/conjur/authn-k8s/<authenticator-id>/apps/secrets-provider-host
    sslCertificate: ...
  1. The Namespace-level Secrets Provider would observe:
    1. Existing Secrets - and periodically query Conjur (or register a webhook or something similar) for updated values that'd get propagated into the existing Secrets
    2. Handle incoming Secrets 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
@rpothier
Copy link
Contributor

rpothier commented Apr 9, 2021

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

@tomcruise81
Copy link
Author

An alternative might be to create a provider for https://github.com/external-secrets/kubernetes-external-secrets and allow it to do most if not all of what I've described above.

Presumably, during the namespaced-installation of that tool,

    account: my-conjur-account
    applianceUrl: https://conjur-oss.cyberark.svc.cluster.local
    authnUrl: https://conjur-oss.cyberark.svc.cluster.local/authn-k8s/<authenticator-id>
    authnLogin:  host/conjur/authn-k8s/<authenticator-id>/apps/secrets-provider-host
    sslCertificate: ...

could all be provided

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants