PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21. There are many external access controllers available such as OPA/Gatekeeper, but getting started with OPA can be tricky.
Otomi, a full suite of built-in K8s apps and extensions, along with developer self-service, uses OPA/Gatekeeper as a standard to provide policy enforcement. All apps built into Otomi are pre-configured based on sound default settings and best practices. The configuration of all applications is managed using a version control system where the requested state is reflected as an icon and the state of the group is automatically updated.
One of the main principles of Otomi is that it is easy to use and provides security from the ground up. In this article, I will soon explain how to get started with OPA/Gatekeeper using Otomi.
First, install Otomi on a Kubernetes cluster in the cloud of your choice. You can use Otomi Quickstart to provision a Kubernetes cluster in AWS, Azure, or GCP, or install Otomi using a Helm schema. To install Otomi using Helm schema, make sure you have a working Kubernetes cluster with at least 16 CPU threads and 32GB + RAM available in your worker node pool.
Add Otomi Repository:
helm repo add otomi https://otomi.io/otomi-core helm repo update
Create a values file with the following values:
cluster: k8sVersion: '1.20' # currently 1.18, 1.19, 1.20 and 1.21 are supported name: # the name of your cluster provider: # choose between aws, azure, google or onprem
Install the scheme:
helm install -f values.yaml otomi otomi/otomi
When the installer task is finished (in the default namespace), copy the generated URL and password from below the logs and complete the post-installation steps.
You can now log in to the console. In the right pane (under Enterprise) you will see
Policies And when you click on it, you will see a list of all the policies available in Otomi.
Screenshot of Otomi . policies
Manage policies with the Otomi Console
Otomi contains a selection of 13 usable OPA policies adapted for use by Conftest as well as for static analysis of lists generated by Otomi.
You can turn policies on or off, as well as set default parameters to use them. Select the policy you want to modify (enable / disable or change default parameters), click
Submit and click
Deploy Changes. The changes will now be applied to the Otomi configuration.
Screenshot of Otomi Banned Photo Tags
Otomi supports three Gatekeeper modes:
- permissive (default)
In both enforcement and tolerance modes, individual policies can be turned on or off. By default, Gatekeeper is enabled in allowed mode (logging and non-blocking).
Customizing policies based on an Otomi schema or using the Otomi Console is supported. In case of specific requirements, operators can add their own custom policies.
To change the mode, open Gitea (in apps) and go to
To switch to force mode, edit the file and set
charts: gatekeeper-operator: disableValidatingWebhook: false
To disable the policy application, edit the file and set
charts: gatekeeper-operator: enabled: false
In the Team section of the Otomi console, developers can use the Gatekeeper dashboard to see all policy violations related to their deployments. First, create a team in Otomi if you haven’t already. In the Team section, tap
Apps Then click
Screenshot from Gatekeeper
Run policy checks against any type of YAML resource
With a simple command, you can test if the Helm chart is violating any policies.
YAML files generated in Conftest are streamed and policies are tested one by one.
$ helm template stable/keycloak | conftest test --policy ./policies/ --all-namespaces - FAIL - Policy: container-limits - container <keycloak> has no resource limits FAIL - Policy: container-limits - container <keycloak-test> has no resource limits 162 tests, 160 passed, 0 warnings, 2 failures, 0 exceptions
By examining the log message, you can see that the container boundary policy sets two sources as failing. Now, all you have to do is modify the templates to provide a “sensitive” amount of resource limits for the indicated containers and our policy checks will pass successfully!
This is very useful if you want to adopt new Helm applications, but don’t want to publish anything in the batch unless they are thoroughly scanned for any violations. Conftest supports passing values to policies using the –data option, which allows policy designers to configure different settings through parameters.
Policy exception capabilities
To create some flexibility, Otomi provides the ability to make exceptions by examining exact annotation information for each resource.
Example: Using the following annotations for an entire room or specific instances of a container would allow one or more policies to be excluded:
# Annotation for the entire pod policy.otomi.io/ignore: psp-allowed-repos # Annotation for Istio sidecar based containers policy.otomi.io/ignore-sidecar: psp-allowed-users,psp-capabilities # Annotation for a specific container (name=app-container) policy.otomi.io/ignore/app-container: banned-image-tags
Implementing an OPA/Gatekeeper can be a challenging endeavor. Some cloud providers have already integrated Gatekeeper into their managed Kubernetes service, but this has resulted in a lockout, while Otomi on the other hand is non-cloud. Using integrated policies in a managed Kubernetes service is not always very flexible. For example, in Azure, policy enforcement can only be turned on or off. There is no option to run in permissive mode.
Otomi offers full Kubernetes security policy capabilities with OPA/Gatekeeper and Conftest. In the allowed (default) mode, developers can publish their apps without the need for direct compliance. They can then see all violations and adjust their posts accordingly. With Otomi, you get all the functionality of OPA/Gatekeeper with a sane set of default policies applied, easy user experience, and plenty of flexibility, available immediately after installing Otomi.
Get started with Otomi today. Check out the GitHub repo here.