Deeper Dive: Updates to Our Kubernetes Essential Policy Toolkit

Last week we announced the broadest policy library and toolset for Kubernetes, Terraform and CloudFormation. This work is part of our effort to support platform engineering and cloud infrastructure teams with policy guardrails, as they work to support hundreds (or thousands) of developers. But what does this exactly mean for Kubernetes users? Today we’ll cover the Styra DAS features and policies that are now at your fingertips for those managing Kubernetes clusters.

We consistently hear from Kubernetes customers that the Styra DAS policy library is one of the most valuable features of the Styra DAS Kubernetes System Type, saving them time from having to author Rego policies for commonly used rules. This allows customers to quickly bootstrap policy for a Kubernetes cluster with rigorous security and compliance best practices in a no-code or low-code manner, even for those who are unfamiliar with Rego.

Let’s quickly recap the policy library and its features. Below is a snapshot of the Styra DAS UI showing our click-to-apply policy library dropdown.

Add and manage rules without ever having to author or edit policy code.

The Styra DAS policy library contains 130 pre-built Kubernetes validating and mutating rules which can be added to policies in any Kubernetes System or Stack (policy collections which can be applied across clusters). These rules range all the way from the relatively simple “Require Secrets to be Encrypted” to the more complex “Deployment: Require Update Strategy” with, in this case, configurable inputs for the user’s selected update strategy, the maximum allowed unavailable pods during an update and the minimum number of pods to create during an update.

Additionally, all pre-built rules in the Kubernetes policy library support the ability to add filters. This allows you to apply that rule only to specific Kinds, Labels, Annotations or Namespaces. Take for example the rule “Containers: Prohibit Privileged Mode” in the Styra DAS policy code editing view:

Once you add a Namespaces filter to the rule and specify a namespace (e.g., “my-app”), Styra DAS automatically adds a snippet of code to the rule’s Rego code, allowing the rule to apply only to resources in the “my-app” namespace.

Alternatively, you may want the rule to apply to all namespaces, except for a specific internal namespace—in this case “internal-admin”. For this, you  can use the Namespaces filter in negation mode, which will exclude resources in the “internal-admin” namespace from policy enforcement.

A quick, general note on multi-cluster policy management: policies can be easily applied across any number of Kubernetes clusters using Stacks, making multi-cluster policy management simple and straightforward, even in complex environments at scale. In Styra DAS, clusters are represented as Systems.

To recap: You can simply select any of our pre-built policies and customer-built Custom Snippets (more on that below) to apply them to a System. You can also filter those policies to apply them in different ways, such as by Labels or Namespaces. You can collect groups of policies into Stacks and apply them, as a group, to any number of Systems; customers often have Stacks for baseline policy guardrails (applied across all Systems), dev environment Stacks, prod environment Stacks and so on. As for compliance monitoring, that’s easy: the Compliance View for any System or Stack displays its violations to easily drill down into specifics or export policy decisions for audit. That’s about it. While Styra DAS offers deeper and richer functionality and customization for customers as they grow with the product, we try to make it as easy as possible to get started.

The Styra DAS policy library also includes a number of Compliance Packs, which combine rules from the policy library into policy templates to meet specific compliance goals. Our existing Kubernetes Compliance Packs are a huge hit with customers, and not just for those in highly regulated industries. Our Pod Security Policies Compliance Pack is one of our most popular Compliance Packs, which helps customers follow pod security best practices by default.

That’s why the most exciting announcement from last week for Kubernetes was the new Pod Security v2 and NIST Container Security Compliance Packs, in addition to an expansion of the CIS Benchmarks Compliance Pack. This expansion brings our Kubernetes Compliance Pack count in Styra DAS to seven.

The existing Styra DAS Pod Security Policies Compliance Pack was developed to align with and replace the functionality of the built-in Kubernetes PodSecurityPolicy (PSP) admission controller. With the deprecation of PSP in Kubernetes v1.25 and stable release of Kubernetes Pod Security Standards (PSS), the new Styra DAS Pod Security v2 Compliance Pack builds on the success of our Pod Security Policies Compliance Pack and realigns it to the Kubernetes PSS Baseline and Restricted profiles, along with the addition of new policies for parity with new controls introduced in PSS. ​​For more information on how Styra policy library rules map to Kubernetes PSS profiles, refer to the Kubernetes Policy Library Rules Pod Security v2 Compliance Pack section in the Styra DAS docs.

For customers looking to meet compliance related to NIST Kubernetes Security (NIST Special Publication 800-190 Application Container Security Guide), last week we added the new NIST Container Security Compliance Pack, mapping pre-built rules from the Styra DAS policy library to address the requirements in NIST SP 800-190. For full details of the requirements mapping, refer to the Kubernetes Policy Library Rules NIST Container Security Compliance Pack section in the Styra DAS docs. For customers, this full roster of Compliance Packs means that you can immediately meet compliance for (or assess your deviation from) leading industry standards, continually monitor for policy violations in your clusters and easily audit policy decisions.

Enabling one of our new Kubernetes Compliance Packs is simple: in your Kubernetes System or Stack, click on Manage Compliance Packs, and then select the desired Compliance Pack.

For example, if you enable the new Pod Security v2 Compliance Pack, Styra DAS will add the Pod Security v2 policy to the System or Stack and begin the configuration process to guide you through reviewing and configuring the rules in this Compliance Pack. In the case of the Pod Security v2 Compliance Pack, each requirement includes details for that requirement and specifies which PSS profile it maps to.

No two customers are alike, just like no two Kubernetes clusters are alike. The pre-built rules in the Styra DAS policy library cover many of the common configuration scenarios for Kubernetes clusters, and now we’ve expanded the power of our rule GUI to custom policies authored by customers. With the Custom Snippets feature, Enterprise customers can have their policy authoring team parameterize their custom policies used across Systems and Stacks so that they can be added and configured in a low-code/no-code manner via the DAS UI by team members not versed in Rego—just like pre-built rules from the Styra DAS policy library. OPA Gatekeeper users may find this feature familiar, as it shares similarities with Gatekeeper’s ConstraintTemplate and Constraint functionality to allow Rego policy authors to create policies for other team members to implement.

To create Custom Snippets, author your rules in a git repository and add the appropriate Custom Snippet metadata to your rule. This metadata defines the title, description, input parameters, applicable System Type and policy return object for your Custom Snippet. Then add that git repository as a global library in your tenant by following the steps outlined in the Mounting Git Repositories for Libraries doc.

The best way to see the true power of Custom Snippets is with an example. Let’s start with a policy which prevents deletion of protected deployments unless by a specified admin:

prohibit_delete_deployment[message] {
   action_is_delete_deployment(parameters.protected_deployments)
   not is_allowed_to_delete_resource(parameters.allowed_users)

   message := sprintf("User %s is not authorized to delete protected deployment %s", [input.request.name, input.request.userInfo.username])
}

action_is_delete_deployment(protected_deployments) {
   input.request.kind.kind == "Deployment"
   input.request.operation == "DELETE"
   input.request.name in protected_deployments
}

is_allowed_to_delete_resource(allowed_users) {
   input.request.userInfo.username in allowed_users
}

Previously, you may have created a global library associated with a git repository with this rule to reference in your System or Stack policy, and you may have used utility functions in that global library to define your allowed users and protected deployments. However, you would not have been able to configure the rule using only the rule GUI in Styra DAS like with our pre-built policy library rules.

With Custom Snippets, simply add the appropriate metadata above the rule head based on the metadata format outlined in the Styra DAS Custom Snippets doc. Then, push your changes to your global library git repository. Now your Custom Snippet is available as a rule in the Styra DAS policy editor, just like Styra DAS pre-built rules:

Adding the rule to a policy results in the display of the associated UI rule card with your rule’s title, description and any input parameters defined in the rule’s metadata. The user adding the Custom Snippet can then enter values for the defined input parameters:

By taking a look at the metadata added to this Custom Snippet, you can see how that translates to the rule snippet code and UI card added to your validating policy:

#############################################################################
# METADATA: library-snippet/kubernetes
# version: v1
# title: "CUSTOM: Prohibit deletion of protected deployments except by admins"
# description: >-
#   This custom snippet prevents the deletion of protected deployments unless by a specified admin.
# filePath:
# - systems/.*/policy/com.styra.kubernetes.validating/rules/.*
# - stacks/.*/policy/com.styra.kubernetes.validating/rules/.*
# policy:
#   rule:
#     type: rego
#     value: "{|{this}}[message]"
# schema:
#   parameters:
#     - name: allowed_users
#       type: set_of_strings
#       placeholder: "Examples: admin@example.com, admin-user"
#       required: true
#     - name: protected_deployments
#       type: set_of_strings
#       placeholder: "Examples: k8sctl, k8state"
#       required: true
#   decision:
#     - type: rego
#       key: allowed
#       value: "false"
#     - type: rego
#       key: message
#       value: "message"
#############################################################################
prohibit_delete_deployment[message] {
   action_is_delete_deployment(parameters.protected_deployments)
   not is_allowed_to_delete_resource(parameters.allowed_users)

   message := sprintf("User %s is not authorized to delete protected deployment %s", [input.request.name, input.request.userInfo.username])
}

action_is_delete_deployment(protected_deployments) {
   input.request.kind.kind == "Deployment"
   input.request.operation == "DELETE"
   input.request.name in protected_deployments
}

is_allowed_to_delete_resource(allowed_users) {
   input.request.userInfo.username in allowed_users
}

And just like with pre-built library rules, your Kubernetes Custom Snippets can also make use of the rule snippet filters for Kinds, Labels, Annotations or Namespaces.

You can improve on this Custom Snippet by connecting the inputs to data sources. For example, use an LDAP datasource as the definition for allowed_users rather than manually defining the users in the input parameters, resulting in the allowed_users always remaining in sync with your LDAP service.

This Kubernetes sample Custom Snippet, as well as several sample Entitlements Custom Snippets and a Custom Snippet metadata validator script, can be found in Styra’s Custom Snippet Samples GitHub repository.

For enterprises, securing Kubernetes means securing a core piece of their mission-critical infrastructure. With our updates to our Styra DAS policy library, Compliance Packs and the addition of Custom Snippets, we’re giving customers more power to quickly and easily add validated policy guardrails in a no-code/low-code way, instantly adhere to leading compliance and security best practices and roll out custom policies to business and less technical team members.

If you’d like to learn more about using Styra DAS for Kubernetes, be sure to book some time with a Styra team member today, or read about how OPA Gatekeeper and Styra DAS compare in Beyond OPA Gatekeeper: Enterprise-scale Admission Control for Kubernetes. Moreover, you can explore many of these changes today in Styra DAS Free.