We deploy a fleet of .NET microservices to Kubernetes, and each service currently receives a generated application.json file through a ConfigMap. A Jenkins job builds that file before deployment, but we want to replace this approach with something easier to manage and safer.
The basic idea is to keep ordinary configuration in ConfigMaps and sensitive values in Secrets, allowing environment variables or mounted files to override the defaults in application.json. The difficult part is managing configuration across multiple environments and teams.
I previously used Ansible with several layers of YAML files that were merged in order. That worked, but it encouraged duplication: when it was unclear where a value was defined, people would redefine it at a later level, making the hierarchy difficult to understand.
I'm therefore looking for a system with a useful UI, evaluated configuration visibility, and access control so developers can manage normal configuration while only authorized people can access secrets. I've considered OpenBao, Infisical, and Phase, but each has drawbacks: OpenBao does not make the fully resolved configuration easy to inspect, Phase appears focused mainly on secrets, and Infisical's self-hosted licensing is more expensive than expected.
What tools or architecture are you using for this kind of setup?
4 Answers
OpenBao together with External Secrets Operator works well for this. Secrets remain in OpenBao, and ESO periodically synchronizes them into Kubernetes Secrets, which the applications can reference. Regular application configuration can stay as plain YAML in version control. OpenBao provides a UI and access policies for the sensitive values, while Git provides the audit trail for non-sensitive configuration.
For the deployment and visibility side, Flux with Kustomize can cover most of this without introducing another paid configuration platform. The desired state stays in Git, and Flux reconciles it into the cluster. Flux also has UI options now through the Flux Operator, although the interface is intentionally more focused on observing and reconciling declarative state than on editing values directly.
A clean approach is to separate the two concerns. Keep non-sensitive configuration in Git and generate the ConfigMaps with Jsonnet, Kustomize, or Helm. Changes then go through normal reviews and the resulting manifests are deployed with a GitOps tool. Store passwords, API keys, and other sensitive values in OpenBao or another vault, then use External Secrets Operator to create Kubernetes Secrets from them. This avoids putting secret values in YAML while keeping ordinary configuration easy to review.
A hybrid setup may be more practical than forcing one product to handle everything. Configuration-management platforms such as Chef can provide predictable policy evaluation and a UI for seeing effective state and job history, while Kubernetes handles rendering normal ConfigMaps. Secrets can still be bridged into the cluster through External Secrets Operator. This gives you access control and visibility without building a large hierarchy of overlapping YAML files.
That read-only model is actually a benefit in many teams: changes happen through reviewed commits instead of someone making an untracked change in a deployment UI.