With shared responsibility, the Airlock Microgateway settings are configured by different teams. Since the security team is still responsible for the company's security, they must create and maintain policies.
Policies
As described in Identify security settings, define the undesired settings for your environment which should be prevented by policies. When creating policies, do the following:
- Good practice:
- Define the responsible team to maintain the policy.
- Mention the prohibited settings in your guidelines.
- Ensure that the templates do not contain prohibited settings.
- The policy validation message contains enough information to resolve violations.
- The project teams know how who to contact in case a policy prohibits the deployment.
- Policies can differ based on context (e.g. deployment stage).
- Observe the violations and take action in case of a burst (e.g. update guidelines, education, ...).
- Include the policy checks in your CI/CD pipeline to see violations as early as possible (some tools have better integration than others).
Ensure that only the necessary group can create, update and delete the policies.
Tooling
There are different tools available to enforce policies for Kubernetes resources. The most famous ones are Open Policy Agent Gatekeeper, Kyverno or Kubewarden. They allow enforcing constraints on Kubernetes resources which includes the Microgateway CRDs.
Basically, the mentioned tools do the same but in detail, they differ in their policy language, Kubernetes-native integration, possibility to use outside Kubernetes, and integration in CI/CD pipeline. This is why you should check which of them suits best for you and whether you use already one of them.
Example
We made a configuration example available on GitHub which shows a Kyverno policy that prevents insecure deny rules settings. See (Github) Airlock Microgateway - Examples in the folder configurations/policy.