Kubernetes policies for dynamic permissions and fine-grained access controls.

Kubernetes supports role-based access control (RBAC) that enables you to configure a set of permissions for a certain user or group of users, that can access Kubernetes objects in your cluster. This gives you the ability to control API-level resource access for users. But sometimes RBAC is not enough and you may need finer-grained or dynamic access controls. For example, preventing accidental deletion of critical resources. Or, preventing users from modifying or deleting a default network policy, while allowing them to self-manage other network policies. Here is one example of a community discussion on this topic. Writing a custom admission controller is complicated, in this post, I will show you how Kyverno makes it easy to manage fine-grained access controls as custom policies.

Briefly, Kyverno is a policy engine built for Kubernetes. It runs as an admission controller that can mutate and validate incoming resources. Also, Kyverno can generate any type of resource-based on various triggers of the admission request. For a validate policy, you can define the desired behavior of an admission request — the request will be blocked if you set the failure action to “enforce”, otherwise the policy will just “audit” the result and create policy violations to report non-compliant configurations. With the support of “enforce” action, it is possible to configure a validate policy to deny specific operations on the selected resources, which is what we will focus on for our use case.

A Kyverno deny policy rule blocks the admission request based on a given set of conditions. Similar to Kubernetes Field Selector, Kyerno lets you select the requests by key-value pairs.

The key can be defined with the fixed value, or it can be dynamically configured using JMESPath, i.e., “{{request.operation}}” will be replaced by the actual value of the admission request when applying the policy. The supported operators “In” “NotIn” “Equals” and “NotEquals”, provide flexibility to write a generic and simple policy.

Here is an example of the deny policy that denies the UPDATE operation of resources with the label “app=critical”.

In a Kyverno policy, you can select the target resources based on various types. A policy rule can be filtered by the resource information, i.e., kinds, name, namespaces, and label selectors, just like the example above. Also, a rule can be selected by the user information of the admission request, i.e., clusterRoles, serviceAccounts, users, and groups. This is how you can customize fine-grained access for certain resources.

Assume we have a user “tenant-admin” who can already delete the deployment, with the following deny policy, you can still block the deletion of the deployments with label “app=critical”. The deletion of deployments without this label is allowed.

To summarize, the Kvyerno Deny policy helps achieve fine-grained access controls that cannot be performed using Kubernetes RBAC. These rules can be used to prevent critical resources from being deleted or mutated by unauthorized users.

Check out the Kyverno GitHub page to learn more about the validation policy and several other features, like generating configurations. Find more in the previous post Kubernetes Policy Management with Kyverno.