This is unreleased documentation for Admission Controller 1.36-dev.

Security hardening

SUSE Security Admission Controller strives to be secure with little configuration. In this section and its subpages, you can find hardening tips (with their trade-offs) to secure Admission Controller itself.

Please refer to the threat model for more information.

kubewarden-defaults Helm chart

Operators can obtain a secure deployment by installing all the Admission Controller Helm charts. It’s recommended to install the kubewarden-defaults Helm chart and enable its recommended policies with:

helm install --wait -n kubewarden kubewarden-defaults kubewarden/kubewarden-defaults \
  --set recommendedPolicies.enabled=True \
  --set recommendedPolicies.defaultPolicyMode=protect

This provides a default PolicyServer and default policies, in protect mode, to ensure the Admission Controller stack is safe from other workloads.

Verifying Admission Controller artifacts

Refer to the Verifying Admission Controller tutorial.

RBAC

Admission Controller describes RBAC configurations in different Explanations sections. Users can fine-tune the needed permissions for the Audit Scanner feature, as well as per Policy Server Service Account for the context-aware feature.

To view all Roles:

kubectl get clusterroles,roles -A | grep kubewarden

Per-policy permissions

For context-aware policies, operators specify fine-grained permissions per policy under its spec.contextAwareResources, and those work in conjunction with the Service Account configured for the Policy Server where the policy runs.

Workload coverage

By default, Admission Controller excludes specific Namespaces from Admission Controller coverage. This is done to simplify first-time use and interoperability with other workloads.

Security-conscious operators can tune these Namespaces list via the .global.skipNamespaces value for both the kubewarden-controller and kubewarden-defaults Helm charts.

Pod Security Admission

From 1.23, Admission Controller’s stack is able to run in a Namespace where the restricted` Pod Security Standards are in place, with current Pod hardening best practices.

To do that, you need to add the pod-security.kubernetes.io/enforce: restricted label to the Admission Controller deployment Namespace.

kubectl label namespace kubewarden pod-security.kubernetes.io/enforce=restricted --overwrite

See the official documentation of Kubernetes' Pod Security Admission for more details.

SecurityContexts

The kubewarden-controller Helm chart configures the SecurityContexts and exposes them in its values.yaml.

The kubewarden-defaults Helm chart allows for configuring the default Policy Server .spec.securityContexts under .Values.policyServer.securityContexts.

For Policy Servers managed by operators, you can configure them via their spec.securityContexts.

Namespaced policy host capabilities

Namespaced policies (AdmissionPolicy and AdmissionPolicyGroup) cannot access Kubernetes resources via contextAwareResources, but they can exercise other host capabilities: OCI registry queries, Kubernetes can_i checks, DNS lookups, and certificate verification. These capabilities could be exploited by a low-privileged user for information disclosure or reconnaissance (see our threat model).

Each PolicyServer exposes a spec.namespacedPoliciesCapabilities field that lists which host capability API call paths are available to its namespaced policies. By default, all PolicyServers allow all host capability calls for namespaced policies. This includes the PolicyServer default (installed with the kubewarden-defaults Helm chart), and custom PolicyServers.

Cluster operators need to configure each PolicyServer’s spec.namespacedPoliciesCapabilities by setting it to [] to deny all, or provide an explicit allowlist.

For a full walkthrough, including an example on secure self-service Namespaces and policies useful for teams, see Controlling host capabilities for namespaced policies.