Skip to main content

Audit Scanner

note

The Audit Scanner feature is available starting from Kubewarden 1.7.0 release

A component, called audit-scanner, constantly checks the resources declared in the cluster, flagging the ones that do not adhere with the deployed Kubewarden policies.

Policies evolve over time: new ones are deployed and the existing ones can be updated, both in terms of version and configuration settings. This can lead to situations where resources already inside of the cluster are no longer compliant. The audit scanner feature provides Kubernetes administrators with a tool to consistently verify the compliance state of their clusters.

To illustrate the usage of the audit scanner in Kubewarden, let's consider the following scenario.

Assume Bob is deploying a Wordpress Pod inside of the cluster. He's new to Kubernetes, hence he makes a mistake and deploys this Pod running as a privileged container. Since there's no policy preventing that, the Pod is successfully created inside of the cluster.

Some days later, Alice, the Kubernetes administrator, enforces a Kubewarden policy that prohibits the creation of privileged containers. The Pod deployed by Bob keeps running inside of the cluster.

However, thanks to the report generated by the audit scanner, Alice can quickly identify all the workloads that are violating her policies; including the Wordpress Pod created by Bob.

To make that happens, audit scanner get all resources that should be audited, build a fake admission request with the resource's data and send it to the policy server in a different endpoint exclusively used to audit requests. However, for the policy evaluating the request, there is no differences from a real or an audit request. The data received are the same. Furthermore, this policy server endpoint is instrumented to collect data of the evaluation as the one used to validate request from the control plane. Therefore, users can use their monitoring tools analyze this data as well.

Enable audit scanner​

As stated before, the audit scanner feature can be enabled starting from the Kubewarden 1.7.0 release.

Detailed installation instructions can be found here.

Policies​

By default, every policy is evaluated by the audit scanner. Operators that want to skip a policy evaluation in the Audit scanner should set the spec.backgroundAudit field to false inside of the policy definition. Furthermore, policies in Kubewarden now support two optional annotations: io.kubewarden.policy.severity and io.kubewarden.policy.category:

  • The io.kubewarden.policy.severity annotation allows you to specify the severity level of the policy violation, such as critical, high, medium, low or info.
  • The io.kubewarden.policy.category annotation allows you to categorize the policy based on a specific domain or purpose, such as PSP, compliance, or performance.

See the policy authors docs for more info.

Permissions and ServiceAccounts​

The audit scanner in Kubernetes requires specific RBAC configurations to be able to scan Kubernetes resources and save the results. A correct default Service Account with those permissions is created during the installation. But the user can provide their own ServiceAccount to fine tune access to resources.

The default audit scanner ServiceAccount is bound to the view ClusterRole provided by Kubernetes. This ClusterRole allows read-only access to a wide range of Kubernetes resources within a namespace. You can find more details about this role in the Kubernetes documentation.

In addition, the audit scanner is also bound to a ClusterRole that grants read access to Kubewarden resource types and read-write access to the PolicyReport CRDs. These permissions enable the scanner to fetch resources for conducting audit evaluations and create policy reports based on the evaluation results.