dadrus
Enforce secure configuration with option to disable it
Preflight checklist
- [X] I agree to follow this project's Code of Conduct.
- [X] I have read and am following this repository's Contribution Guidelines."
- [X] I have discussed this feature request with the community.
Describe the background of your feature request
Heimdall already enforces a variety of secure defaults, such as verifying JWT issuers, validating certificates opon configuration, or supporting only secure TLS versions and ciphers. These and other related features contribute significantly to ensuring that heimdall operates in a secure way by default. However, there are still scenarios where misconfigurations can lead to less secure behavior. For instance, it is currently possible to avoid configuring TLS or to define a default rule that allows passing through any request not matched by upstream-specific rules. Even though, such topics are addressed in the available documentation, they can introduce security risks, particularly if not carefully managed in production environments.
Describe your idea
To further reinforce heimdall's security posture, I would like to extend the enforcement of secure defaults and address potential gaps in configurations with the aim to ensure that heimdall defaults to the most secure settings across all relevant areas, including:
- Ensure that TLS is always used for inbound and outbound requests.
- If a default rule is configured, enforce that it prevents unauthorized pass-through requests if no upstream-specific rule is matched.
- Strict Verification of Certificates on startup and during operation
- ...
To accommodate development or non-production use cases, we could implement --insecure or --dev flag used while starting heimdall to disable the secure defaults, allowing developers to bypass security configurations and experiment with heimdall in a more permissive environment.
This approach would make it easy to detect insecure configurations or the usage of these flags using tools like Kyverno, or similar and allow organizations to enforce policies that prevent the usage of insecure configurations in production environments while still permitting them in development.
Are there any workarounds or alternatives?
Alternatively,
- heimdall could automatically detect the environment (e.g., production or development) and adjust secure defaults accordingly. This could be done by detecting environment variables or through integration with Kubernetes annotations or similar. Personally, I don't like such "automagic".
- Rely entirely on available configuration options and make use of Kyverno & Co to enforce secure configuration. On the one hand, this could offer finer control over individual settings. On the other hand, it will introduce complexity in detecting insecure configurations and there will be a need to provide proper policies for different tools (like Kyverno).
Version
0.15.0
Additional Context
Personally, I'm favor the flag approach.
