cyberark / conjur

CyberArk Conjur automatically secures secrets used by privileged users and machine identities
https://conjur.org
Other
762 stars 123 forks source link

Spike: research current secrets configuration modes - is there a common standard? #2031

Closed izgeri closed 3 years ago

izgeri commented 3 years ago

We currently support many different tools in Kubernetes to deliver secrets from Conjur to applications running in Kubernetes that need them. In particular, we have:

Each of these uses a different configuration to specify what secrets to retrieve from Conjur and how to use them. In this spike, we want to review the existing configuration mechanisms to understand whether they can be simplified to use a common standard, and whether there would be any benefit to doing so.

For example, if we ultimately end up with a single CyberArk Secrets Provider container image that can be run in any of the above modes:

  1. to "push to k8s secrets" (as init container or job) - uses secrets map
  2. to provide secretless access to targets (as sidecar) - uses secretless.yml
  3. to provide a Conjur access token that Summon uses to inject secrets at startup (as init container) - uses secrets.yml, or
  4. to provide a Conjur access token that a client library can use to retrieve secrets for the application - has no standard config

What would it look like to specify the secret configuration for an application using the single CyberArk Secrets Provider container? If we standardize on providing configuration for secrets in ConfigMap, is there a way to standardize on this regardless of configuration (Secretless, Secrets Provider, Authn-K8s + Summon, Authn-K8s + Client Libraries)?

AC:

diverdane commented 3 years ago

I've summarized all of the different mappings in a gist. I also included the proposed ConfigMap mapping for Secrets Provider for k8s with Write-to-File:

https://gist.github.com/diverdane/3a935d83d9f580e0e353d7015c513a67