Developers can create policies that fetch information from a Kubernetes cluster at run time.
These are context aware policies.
Context aware policies can determine whether an
AdmissionRequest is acceptable using information from resources deployed in the cluster.
Context aware policies are only available in Kubewarden versions ≥ v1.6.0.
Resources a policy can access in the cluster is controlled by the policy server's Service Account. A cluster administrator controls what a policy can access via Kubernetes RBAC rules. Context aware policies have only read access to the requested resources.
For security reasons, only
ClusterAdmissionPolicy policies can fetch information from the Kubernetes cluster.
This is because
AdmissionPolicy resources can be deployed by unprivileged users.
If a context aware policy is deployed as an
AdmissionPolicy all attempts to access Kubernetes resources are blocked and reported to the cluster administrator.
By default, all the cluster resources are blocked.
A Kubewarden administrator defines which Kubernetes resources each context aware policy is allowed to read.
This is done in the
ClusterAdmissionPolicy definition using the field
The following example deploys a policy that requires access to the
- apiVersion: "apps/v1"
- apiVersion: "v1"
- apiGroups: ["apps"]
Once deployed, this policy can read the data of the
Policy authors provide lists of Kubernetes resources for their context aware policy.
This is done by annotating the policy.
Kubewarden administrators view policy metadata using the
kwctl inspect command.
They can get a list of resources the policy needs access to.
An administrator uses this list to populate the
To prevent system abuse, Kubewarden administrators must review the resources the policy will access.
For example, a policy evaluating ingress objects would have good reasons to read the
Ingress resources defined in the cluster.
The same policy can't justify having access to
Policies should have the least access needed to function correctly.
Kubernetes resources are identified by
apiVersion is a string in the format
Resources from the
core API group (Pod, Service, and others) should not define the group name,
They should only define the
<version> (for example,
For a core resource, the first will not work, the second will.
- apiVersion: "core/v1"
- apiVersion: "v1"
All other Kubernetes resources need the full definition: