Skip to main content
Version: Next 🚧

Security hardening

Kubewarden strives to be secure with little configuration. In this section you can find hardening tips (with their trade-offs) to secure Kubewarden itself.

Please refer to the threat model for more information.

kubewarden-defaults Helm chart​

Operators can obtain a secure deployment by installing all the Kubewarden 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 check the Kubewarden stack is safe from other workloads.

Verifying Kubewarden artifacts​

See the Verifying Kubewarden tutorial.

RBAC​

Kubewarden describes Role Based Access Control (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.

The 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. These work in conjunction with the Service Account configured for the Policy Server where the policy runs.

Workload coverage​

By default, Kubewarden excludes specific Namespaces from Kubewarden coverage. Kubewarden does this 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 version 1.23, Kubewarden'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 Kubewarden 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 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.