Admission control with Open Policy Agent
Prisma Cloud provides a dynamic admission controller for Kubernetes and OpenShift that is built on the Open Policy Agent (OPA).
In Console, you can manage and compose rules in Rego, which is OPA’s native query language.
Rules can allow or deny (alert or block) pods.
Console pushes your policies to Defender, which enforces them.
Decisions made by the system are logged.
There is currently no support for Windows.
Open Policy Agent
The Open Policy Agent is an open source, general-purpose policy engine that lets you consolidate policy enforcement in a single place.
OPA can enforce policies in microservices, Kubernetes clusters, CI/CD pipelines, API gateways, and so on.
OPA provides a high-level declarative language called Rego, which lets you specify policy as code.
The OPA APIs let you offload policy decision-making from your software.
OPA decouples policy decision-making from policy enforcement.
When your software needs to make policy decisions, it queries OPA and supplies structured data, such as JSON, as input.
The data can be inspected and transformed using OPA’s native query language Rego.
OPA generates policy decisions by evaluating the query input and against policies and data.
Prisma Cloud operationalizes OPA by:
- Extending Console to manage and compose policies in Rego.
- Integrating OPA’s decision-making library into Defender.
- Connecting Defender’s enforcement capabilities to OPA’s decisions.
Admission webhook
An admission controller is code that intercepts requests to the API server for creating objects.
There are two types of admission controllers: built-in and dynamic.
Prisma Cloud implements a dynamic admission controller.
Dynamic admission controllers are built as webhooks.
After registering to intercept admission requests, they assess requests against policy, and then accept or reject those requests.
In Kubernetes terms, these are known as validating admission webhooks.
The Prisma Cloud validating admission webhook handles the API server’s AdmissionReview requests, and returns decisions in an AdmissionReview object.
When configuring Prisma Cloud, you’ll create a ValidatingWebookConfiguration object, which sets up the Defender service to intercept all create, update, and connect calls to the API server.
The default ValidatingWebookConfiguration provided here sets failurePolicy to Ignore.
The failure policy specifies how your cluster handles unrecognized errors and timeout errors from the admission webhook.
When set to Ignore, the API request is allowed to continue.
Configuring the webhook
Configure the API server to route AdmissionReview requests to Prisma Cloud.
Prerequisites:
- You have a running instance of Prisma Cloud Compute Console.
- You have a Kubernetes cluster. Minimum supported version is v1.16.
- Defender has been deployed to your cluster as a DaemonSet. In Console, you can verify Defenders are running and connected underManage > Defenders > Manage.
- Go toDefend > Access > Admission
- Enable admission control.
- ClickGo to settings.
- Copy the configuration provided to a file named webhook.yamlIf the Defender CA has been rotated and the old certificate still hasn’t expired, you may have Defenders using an old certificate. For daemonset which its Defenders are using an old certificate, you need to retrieve the old Defender CA certificate from the daemonset yaml file you deployed this daemonset with.Search for defender-ca.pem within the daemonset yaml, copy its content, then paste it to replace the content of the caBundle field of the webhook. If defender-ca.pem doesn’t exist in the daemonset yaml, use the content of the