Kratos Config Override: Like Oathkeeper's Approach?

Hey everyone! Today, we're diving deep into a challenge many of us face when deploying Kratos with Kustomize and Helm charts: configuration management. Specifically, we're exploring how to achieve a complete configuration override in Kratos, similar to Oathkeeper's handy configFileOverride feature. Let's break down the problem, explore potential solutions, and discuss why this is such a hot topic for Kratos users.

The Configuration Conundrum with Kratos and Kustomize

When deploying Kratos using Helm charts alongside Kustomize, things can get a bit tricky. The default Helm chart has a lot of moving parts, doing a lot of magic under the hood to massage configurations, create secrets, and manage hashed values. This complexity is great for streamlining the average deployment, but can cause headaches when you need more control or are using tools like envsubst. Many of us, especially those with combined local and cloud deployments, rely on envsubst for environment-specific value replacements. Unfortunately, Kratos's default configuration approach often clashes with this workflow, making customization a real pain.

Dealing with complex configurations is a common pain point, particularly when you're trying to maintain consistency across different environments. The built-in mechanisms of the Kratos Helm chart, while powerful, can feel opaque and inflexible when you need to inject specific values or override default settings. This is where the need for a more direct and straightforward configuration override solution becomes apparent. For those managing multiple environments, the need for a simple, repeatable, and predictable configuration process is critical. Without it, deployments become error-prone and time-consuming. This is precisely why the configFileOverride feature in Oathkeeper is so appealing – it provides a clear and direct way to manage configurations.

Furthermore, the current Kratos setup requires a deep understanding of the Helm chart's internal workings. To modify even a seemingly small configuration parameter, you often have to navigate a maze of templates, secrets, and hashed values. This not only increases the learning curve for new users but also adds significant overhead to maintaining and updating existing deployments. A configFileOverride option would greatly simplify this process by allowing you to provide a complete, self-contained configuration file. This approach aligns better with infrastructure-as-code principles, making your Kratos deployments more manageable, predictable, and scalable.

Imagine, for instance, you need to tweak the database connection settings for a specific environment. With the current setup, you might have to modify multiple Helm templates, update secrets, and ensure that all the hashed values are correctly recalculated. With a configFileOverride option, you could simply provide a complete configuration file tailored to that environment, eliminating the need to dive into the intricacies of the Helm chart. This not only saves time and effort but also reduces the risk of introducing errors.

The Ideal Solution: configFileOverride

So, what's the dream scenario? Well, many of us are looking for the ability to completely override all Kratos configuration and secrets, and also control how they are mounted to the containers. Oathkeeper has a feature called configFileOverride, and many of us think it would be perfect to have a similar option in Kratos. This would give us the granular control we need without getting bogged down in the Helm chart's internal complexities.

The beauty of configFileOverride is its simplicity and directness. It allows you to provide a complete configuration file, bypassing the default configuration mechanisms of the application. This is particularly useful when you have complex configuration requirements or when you need to integrate Kratos with existing infrastructure that relies on specific configuration patterns. With configFileOverride, you can ensure that Kratos is configured exactly as you need it, without having to fight against the defaults.

Moreover, a configFileOverride option would promote better separation of concerns. Your configuration logic would be decoupled from the Helm chart, making it easier to manage and version control. You could store your Kratos configuration files in a separate repository, alongside your other infrastructure-as-code artifacts. This would improve the overall organization of your deployments and make it easier to track changes to your Kratos configuration over time. This also simplifies the process of rolling back to previous configurations, which is essential for maintaining stability and reliability.

Another advantage of configFileOverride is that it provides a clear and unambiguous way to configure Kratos. There's no need to guess which Helm templates to modify or which secrets to update. You simply provide a complete configuration file, and Kratos uses that file to configure itself. This reduces the risk of misconfiguration and makes it easier to troubleshoot problems. It also makes it easier for new team members to understand how Kratos is configured, as they can simply read the configuration file.

In addition to simplifying configuration management, configFileOverride can also improve the security of your Kratos deployments. By providing a complete configuration file, you can ensure that all sensitive information, such as database passwords and API keys, are properly secured. You can also use configFileOverride to configure Kratos to use secure communication protocols, such as TLS, and to enable authentication and authorization features. This helps to protect your Kratos deployments from unauthorized access and data breaches.

Current Workarounds: A Manual and Time-Consuming Process

Right now, the workaround involves using helm template to generate the files manually. After generating the files, many of us are saving the result in our own repository, and then applying patches and replacements using kustomize. This approach works, but it's far from ideal. It's not sustainable in the long run because keeping up with updates becomes a manual and time-consuming process. Whenever there's a new Kratos release, you have to regenerate the files, re-apply your patches, and make sure everything still works as expected. This quickly becomes a maintenance nightmare.

The manual approach is not only time-consuming but also error-prone. When you're manually patching and replacing files, there's always a risk of introducing mistakes. You might accidentally delete a line of code, misconfigure a setting, or forget to update a secret. These errors can lead to unexpected behavior, security vulnerabilities, and deployment failures. The more complex your Kratos configuration, the greater the risk of making mistakes.

Moreover, the manual approach makes it difficult to track changes to your Kratos configuration. When you're manually patching and replacing files, it's hard to keep track of what changes you've made and why. This can make it difficult to troubleshoot problems and to revert to previous configurations. It also makes it difficult to collaborate with other team members, as everyone needs to be aware of the manual changes that have been made.

Another drawback of the manual approach is that it violates the principles of infrastructure-as-code. Infrastructure-as-code is the practice of managing and provisioning infrastructure through code, rather than through manual processes. By manually patching and replacing files, you're deviating from this practice and making your Kratos deployments more difficult to manage and automate. This can lead to inconsistencies between environments, increased deployment times, and reduced reliability.

Finally, the manual approach can hinder your ability to take advantage of new Kratos features and updates. When you're manually patching and replacing files, it's more difficult to incorporate new Kratos features and updates into your deployments. You have to carefully review the changes in each Kratos release and manually apply those changes to your patched files. This can be a time-consuming and error-prone process, especially if you have a complex Kratos configuration.

In Conclusion

The lack of a configFileOverride option in Kratos creates unnecessary friction in the configuration process, especially when using tools like Kustomize and envsubst. The current workaround is not sustainable and makes keeping up with updates a headache. Adding a configFileOverride option, similar to what's available in Oathkeeper, would be a huge improvement for Kratos users, providing a more flexible, manageable, and secure way to configure their deployments. Hopefully, the Ory team will consider this feature request in future releases. Keep an eye on this space for updates, and let's keep the conversation going!