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.
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.severityannotation allows you to specify the severity level of the policy violation, such as
io.kubewarden.policy.categoryannotation allows you to categorize the policy based on a specific domain or purpose, such as
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
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
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.