Carol Pereira and Corey Dinkens contributed to this blog post.
With the increasing complexity of distributed systems, it is essential to define and implement policies for Kubernetes clusters to ensure the security, reliability, and compliance of the environment—and of course to build the scaffolding for scalability.
So, we are glad to announce that VMware Tanzu Mission Control now has additional policy improvements designed to enhance Kubernetes security. Platform teams can now mutate the security context for workoads and modify the default Open Policy Agent (OPA) Gatekeeper policy settings.
Tanzu Mission Control launched mutation policies because they significantly enhance an organization's security measures by enabling an always-on security posture. These policies can impose limitations on a pod’s functionalities to help thwart malicious actions. For instance, they can prohibit the use of privileged containers or forbid containers from operating as root, which helps minimize the risk of potential security breaches. In addition, it supports customers that are migrating their clusters away from Pod Security Policies (PSPs) while still maintaining the security posture of their organizations. It also supports platform teams with a “shift left” approach to security and can help ease the burden on developers to stay on top of the ever-changing world of Kubernetes security policies and settings. This helps enforce the desired security posture of platform teams consistently across an enterprise, regardless of which Kubernetes distribution is used.
The second portion of today’s announcement covers the ability to modify the default OPA Gatekeeper policy settings, such as increasing resource limits, for better governance, enabling users to better adjust resource allocation for clusters with high utilization. In addition, it gives highly regulated companies with mandated security requirements, such as those in the financial sector, the ability to override defaults, such as failure policy and timeout seconds, to lock down their infrastructure more efficiently.
Automate policy enforcement across clusters and environments
Tanzu Mission Control helps platform teams apply several types of policies today, including:
-
Access – Ability to give each group or individual access to clusters or separate namespaces
-
Network – Option to segregate apps and ensure they don’t receive unwanted traffic
-
Image registry – Opportunity to allow only known and trusted container registries to be pulled from, preventing images from untrusted sources and avoiding external sources like Docker hub
-
Quota – Constrain the resources used in your clusters, as aggregate quantities across specified namespaces, using preconfigured and custom templates
-
Security – Power to limit capabilities and privilege escalation within containers, with the ability to configure policies to monitor without enforcement, so violators can be identified
-
Custom – Implement additional business rules, using templates to enforce policies that are not already addressed using the other built-in policy types.
PSP and OPA Gatekeeper can both be used to enforce security policies in Kubernetes environments, but they differ in their approach and capabilities.
VMware uses OPA as a policy engine for Tanzu Mission Control in security, custom, and image-related policies in addition to other native Kubernetes security components (e.g., Antrea Network Policies) due to its broader flexibility (e.g., support for mutation policies) and the fact that it is a graduated Cloud Native Computing Foundation (CNCF) open source project with a vibrant community.
With PSP being removed from Kubernetes v1.25 and later, many organizations that are using this solution could be caught off guard and left scrambling to update their deployments and configurations. So, leveraging OPA Gatekeeper can help ensure workloads are compliant as the needed updates and application changes take place.
Benefits of OPA Gatekeeper include actions like "dryrun," which allows users to create a policy without enforcing it, view any violations via the Insights page with the ability to fix their workloads or update the policy, and when everything looks good, change enforcement to "deny." Admins can define policies at a fine-grain level (cluster, cluster group, or organization) and enforce those accordingly, making it a more robust solution for managing security policies at scale. Admins can also use label-based namespace selectors to include and exclude specific namespaces, ensuring that clusters are in compliance with security policies.
By providing a more powerful and flexible way to enforce policies in Kubernetes environments, OPA Gatekeeper offers better governance to enforce policies across clusters.
This is why we’ve worked to improve Kubernetes security with added policy features in Tanzu Mission Control, including the ability to mutate the security context for containers and pods and modify the default OPA Gatekeeper policy settings.
No more validation errors: Set more rules with mutation policies
Mutation policies are different from validating security policies because they do not block the creation of Kubernetes resources that may violate a policy. Instead, they will update or mutate that request to create the desired resource at runtime.
As such, mutation policies are a powerful tool for improving the reliability and consistency of your Kubernetes objects by enforcing policy constraints and ensuring that objects are always in a valid state at runtime.
To create a mutation policy, the platform admin must go to the Mutation tab under Policy assignments and click Create mutation policy. Tanzu Mission Control is currently offering PodSecurity mutation, with more options to come.
The platform admin can enter a name for their policy and choose among several fields in the security context to mutate so that when someone creates a pod in that cluster, it will inherit those security values.
An example of a common mutation policy would be ensuring that all submitted workloads are configured to have a runAsUser, runAsNonRoot, and disallowPrivilegeEscalation. The gatekeeper admission controller validates resources against the properties defined in a mutation policy, and depending on the condition you configure (Always, IfFieldExists, IfFieldDoesNotExist), the property will be added by the admission controller.
Creating a mutation policy with modified values in Tanzu Mission Control
Pod security expanded: Update Gatekeeper's settings
As mentioned above, Tanzu Mission Control has various types of guardrail policies, and some of them, such as security, image, custom, and mutation, are enforced using the OPA Gatekeeper open source tool.
When Tanzu Mission Control installs Gatekeeper on clusters, a few default settings and configuration values are applied.
Now, with the new policy-setting features, organizations can override some of these values at the Settings tab located inside the Administration page found on the left-hand menu.
This means organizations and administrators can adjust the Gatekeeper deployment settings to their needs at all levels, such as organization, cluster group, and cluster. This initial release allows for the modification of the validating webhook configuration (by changing the failure policy and timeout seconds) as well as the controller manager deployment and auto-deployment settings (by altering the number of replicas and CPU memory limits).
One example of this added flexibility would be to override Gatekeeper's default validating webhook policy, which is currently (by default) set to Ignore and allows cron jobs and other workloads to still be accepted if Gatekeeper goes down on a cluster. By setting that default to Fail, admins will be able to ensure the denial of any workload or job until Gatekeeper is available again.
Being able to override policy settings while leveraging key security features of OPA Gatekeepers makes Tanzu Mission Control a very powerful option for enterprise policy management across multi-cloud Kubernetes fleets.
View of the Settings tab within the Administration area of Tanzu Mission Control
Validating webhooks configuration in the new Tanzu Mission Control settings feature
Access policies now include Kubernetes service accounts
Tanzu Mission Control now allows you to use Kubernetes service accounts as an entity type when creating role bindings in access policies. With that update, admins can manage service account access fleet-wide rather than on a per-cluster basis, reducing the time dedicated to such operations and they can also audit policies across fleets.
Service account identity types are important in Kubernetes because they determine the level of access and permissions that a service account has within the cluster, which is critical for maintaining the security and integrity of the cluster.
Being able to add policies to service accounts is critically valuable because it helps to further ensure that only authorized services and users have access to resources within a Kubernetes cluster and that service accounts are limited to only the resources they need to perform their tasks. This, again, improves the security and stability of the cluster, particularly in multi-tenant environments.
What's next?
Review how to create a mutation policy and how to update Gatekeeper configurations by managing administrative settings.
Visit the Tanzu Mission Control product page, and check the release notes so you don't miss any new features.
