What is the Audit Scanner?

note

The Audit Scanner feature is available starting from Kubewarden 1.7.0 release

The audit-scanner component constantly checks resources in the cluster. It flags the ones that don't adhere with the Kubewarden policies deployed in the cluster.

Policies evolve over time. New ones are deployed, existing ones are updated. Versions and configuration settings change. This can lead to situations where resources already inside the cluster are no longer compliant. The audit scanning feature provides Kubernetes administrators with a tool that constantly verifies the compliance state of their clusters.

To explain the use of the audit scanner in Kubewarden, consider the following scenario.

Assume Bob is deploying a WordPress Pod in the cluster. Bob is new to Kubernetes, makes a mistake and deploys the Pod running as a privileged container. At this point there's no policy preventing that so the Pod is successfully created in 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 in the cluster as it already exists.

A report generated by the audit scanner lets Alice identify all the workloads that are violating creation policies. This includes the WordPress Pod created by Bob.

The audit scanner operates by:

• identifying all the resources to audit
• for each it builds a synthetic admission request with the resource's data
• it sends each admission request to a policy server endpoint which is only for audit requests

For the policy evaluating the request, there are no differences between real or audit requests. The data received is the same. This auditing policy server endpoint has instrumentation to collect data of the evaluation. So, users can use their monitoring tools analyze audit scanner data.

Enable audit scanner

You can enable the audit scanner starting from the Kubewarden 1.7.0 release.

Detailed installation instructions are in the audit scanner How-to.

Policies

By default, the audit scanner evaluates every policy. Operators that want to skip a policy evaluation in the audit scanner must set the spec.backgroundAudit field to false in the policy definition.

Also, policies in Kubewarden now support two optional annotations:

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

See the policy authors documentation for more information.

Permissions and ServiceAccounts

The audit scanner in Kubernetes requires specific Role Based Access Control (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. The user can create and configure 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.

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