Users deploying applications to Kubernetes or OpenShift that use our Conjur Kubernetes authenticator currently have to provide for each application detailed configuration information for the Conjur connection, even though most of the configuration details are shared by all applications within the cluster. Having to copy/paste so much boilerplate is laborious, makes it easy to make mistakes, and it’s difficult to discover misconfigurations until the very last minute when an application is deployed.
Additionally, the current methodology forces the persona that is deploying each application to have direct knowledge of Conjur configuration details.
In this effort, we’d like to make some small, concrete changes to how we manage Conjur configuration in our Kubernetes integrations so that:
The amount of copy/pasting of boilerplate configuration is drastically reduced; in particular, much of what is currently required to be added to CyberArk container definitions in Kubernetes manifests can be replaced by a reference to a common configuration file.
The persona that is deploying each Conjur-enabled application does not need to know Conjur connection details.
Setting up the cluster for Conjur integration fails fast, so any potential misconfigurations are caught and highlighted early. Adding input validation contributes to this.
jtuttle
commented
3 years ago
Simple Kubernetes Authenticator Client Configuration
Users deploying applications to Kubernetes or OpenShift that use our Conjur Kubernetes authenticator currently have to provide for each application detailed configuration information for the Conjur connection, even though most of the configuration details are shared by all applications within the cluster. Having to copy/paste so much boilerplate is laborious, makes it easy to make mistakes, and it’s difficult to discover misconfigurations until the very last minute when an application is deployed.
Additionally, the current methodology forces the persona that is deploying each application to have direct knowledge of Conjur configuration details.
In this effort, we’d like to make some small, concrete changes to how we manage Conjur configuration in our Kubernetes integrations so that:
The amount of copy/pasting of boilerplate configuration is drastically reduced; in particular, much of what is currently required to be added to CyberArk container definitions in Kubernetes manifests can be replaced by a reference to a common configuration file.
The persona that is deploying each Conjur-enabled application does not need to know Conjur connection details.
Setting up the cluster for Conjur integration fails fast, so any potential misconfigurations are caught and highlighted early. Adding input validation contributes to this.
References
Stories
227 - There is a helm chart to prepare a cluster for Conjur Kubernetes Authentication
228 - There is a helm test for the cluster prep helm chart
236 - There is a helm chart to prepare a namespace in a cluster for Conjur Kubernetes authentication
237 - There is a helm test for the namespace prep helm chart
235 - There is published documentation on managing Conjur configuration in a Kubernetes cluster
246 - There is a quick start guide for Conjur Kubernetes authentication
242 - There are end-to-end tests for Kubernetes sidecars with Conjur OSS in Kubernetes
261 - There is a release of the new configuration management helm charts
There are additional lower-level stories for building out the automated test suite, but these are the primary stories included in this effort.