You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
There are additional lower-level stories for building out the automated test suite, but these are the primary stories included in this effort.
The text was updated successfully, but these errors were encountered: