Policies streamline your Kubernetes deployments.
As your organisation grows, policies become deliberate systems which guide decisions and help you achieve better outcomes. Even for smaller companies these systematic guidelines can help you do more with less. Define your policy with over 100+ build-in rules or extend it with custom plugins.
- How-to enable default policies
- How-to create a custom policies and plugin to validate memory consumption
Policies are defined in your Projects. You can start streamlining your deployments by going to your project's policy tab. Here you can use the Policy Quick Start to bootstrap a policy or the Policy Builder to tailor a policy to your needs.
You can review changes before saving or even revert them. Once saved, the policy will automatically be enforced across all the repositories within this project.
Security Frameworks contain industry standards such as CIS Benchmarks or the Kubernetes Hardening Guidance of the NSA/CISA. Each are defined as standard taxonomies which allows you to understand which rules help you comply with these guidelines.
The benefit of security frameworks is that it's more meaningful to comply with an industry standard rather than a set of arbitrary rules. That's why the Quick Start widget will use these frameworks to bootstrap your first policy.
Plugins contain a set of related rules. They are the heart of the extensible architecture of our static analysis tool. You can use one of our build-in plugins or extend Monokle with community or custom plugins.
Once you are ready to go beyond our quick start, check out the Policy Builder to modify the toggle, level and settings of each rule:
- The toggle simply enables or disables this rule. You can disable rules that are not sensible for your infrastructure or enable new ones to further constrain your deployments.
- The level indicates how misconfigurations should be treated. Both warnings and errors will give a notification, but errors will also get blocked during enforcement. It's recommended to start with warnings and slowly move them over to errors after fixing it to prevent blocking your deployments
- The settings are sparsely available to rules that need additional input such as thresholds or allowed values.
Within the Policy Builder you'll likely also notice some read-only information:
- The severity is a read-only attribute which indicate the gravity of misconfigurations. A low severity indicates that it will lead to minor inconveniences, while a high severity means it can leave your infrastructure exposed to hackers. You can rely on this information to tackle the important controls first.
- The description gives a summary of this security control. You can hover it for additional details.
The YAML View
Under the hood the validation configuration is actually a YAML file. This eases sharing configuration and interoperability between the tools in the Monokle ecosystem. You can learn more about the format here.
The Policy Builder's YAML view shows the configuration and is handy for more advanced use cases such as (1) troubleshooting, (2) copy-pasting configuration, or (3) configuring settings that are not available through the user interface.
# Example monokle.validation.yaml
As an alternative to policies, you can also commit a monokle.validation.yaml to the root of your repository. Monokle will detect it and use these settings.
Can you add multiple policies to a single project?
No, currently each project defines a single policy. Multiple policies per project will be added in the future to unlock advanced use-cases. Reach out to us if this limitation is holding you back in your policy implementation.