Secrets Provider Controller/MutatingAdmissionWebhook

[tomcruise81]

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: ...

2. 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]

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]

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

[tomcruise81]

https://github.com/external-secrets/kubernetes-external-secrets was deprecated in favor of it's re-write - https://github.com/external-secrets/external-secrets. That currently supports:

• AWS Secrets Manager
• AWS Parameter Store
• Akeyless
• Hashicorp Vault
• Google Cloud Secrets Manager
• Azure Key Vault
• IBM Cloud Secrets Manager
• Yandex Lockbox
• Gitlab Project Variables
• Alibaba Cloud KMS
• Oracle Vault
• Generic Webhook
• Kubernetes

Any plans on creating a provider there?

Thanks!

[szh]

We now support External Secrets Operator - see https://external-secrets.io/latest/provider/conjur/