In our feature hungry world, companies are pushing developers to their limits. Where automations and CI/CD pipelines are supposed to eliminate the woes developers face in moving a feature to production, security and compliance concerns around the current flows of configuration management have placed manual road blocks that cannot be ignored. As a result, development teams are continuously plagued with rigorous manual processes that either result in significant lead times, or if ignored, result in non-compliance and security incidents. Even with DevOps practices and Agility in the mix, there just doesn't seems to be a solution to the problem of secure application configuration management
The two most popular designs for managing application configurations are:
Scenario One: Developers manage configurations, encrypt and share them via a VCS like Git. The IT or Operations departments are held responsible for creating and managing the relevant accounts, which are then shared with the developers.
Scenario Two: Developers manage their local configurations and the IT/Operations departments are responsible for creating and deploying configurations to the relevant environments, via automations or manually.
Let's take an example of developers requiring a simple integration with MailChimp to send emails.
Developers might share keys amongst themselves via insecure means (*cough* slack messages *cough*).
Uploading an un-encrypted configuration file exposes sensitive data.
There is no mechanism to do version control on the configuration since they are encrypted.
If there is a security incident, there is no easy way to find which configuration is deployed where, or what application is using it.
Let's take the same integration request as above, where the IT/Operation department manages all configuration.
Hard dependency between IT and Development for not only creation but deployment and debugging of any credential related issues.
With ConfigTree you can share your Mailchimp keys across teams or individuals. All the applications that use this key, just need to point to the Published version and they will always have the most up to date values.
If something goes wrong and the value goes missing, well you don't have to wait on DevOps or IT to create a new one. You can always roll back to a previous version and use those values.
Secure, fast and efficient