There is a draft plan for improving Conjur sidecar automation in Kubernetes / OpenShift

[izgeri]

At current we have multiple sidecars that can be deployed with applications running in Kubernetes / OpenShift to facilitate connections to Conjur:

• Conjur Kubernetes Authenticator Client (sidecar or init container)
• Secretless Broker (sidecar)
• Secrets Provider for K8s (init container or standalone app)

Each sidecar / init container requires some standard pre-configuration, and usually requires changes to:

• Conjur policy
• Kubernetes role bindings
• Kubernetes config maps for Conjur SSL certificate
• Kubernetes config maps for additional configuration files (eg secretless.yml)
• Updated deployment manifests that includes the configuration for the sidecar/init container to communicate with Conjur

There are improvements that can be made to make the process of deploying applications in Kubernetes / OpenShift at scale that are set up to use the appropriate sidecar and communicate securely and with least privilege with Conjur. To that end, we developed the Conjur sidecar injector - a mutating admission webhook controller that can dynamically inject sidecars at application deploy time.

In this effort, we will explore modern options for best-practice management of sidecar automation, with the goal of coming up with a proposed plan for a path forward for the management of our Kubernetes integrations, with a desired end state and incremental stages to reach that end state. In developing this plan, we will likely spike out some options and develop some lightweight proofs-of-concept of some of the pieces we propose.

[diverdane]

@doodlesbykumbi and I have had some discussion on what can be done here. Here's a summary: https://gist.github.com/diverdane/e166deb3b88ebd36871a6844e828b4ae