Auditing Veeam Kasten

Independent of whether the dashboard, CLI, or API is used to access Veeam Kasten, the usage translates into native Kubernetes API calls. Veeam Kasten usage can therefore be transparently audited using the Kubernetes Auditing feature without requiring any additional changes.

Note

Managed Kubernetes providers like EKS, GKE, and AKS do not allow any modifications to the kube-apiserver flags, thereby lacking control over the passed-in audit policy. Typically, these providers log the audit events at the metadata level, resulting in the loss of important information within the request and response bodies.

This approach is not applicable if you want to send these logs to different cloud object stores or use NFS for storing the logs.

Since the Kubernetes Auditing feature only has access to Kubernetes API calls, any internal Veeam Kasten event that does not use this API will not get logged. The ongoing work with integrating Veeam Kasten more closely with Security Information and Event Management (SIEM) platforms, such as with Datadog, will allow for a more robust auditing of Veeam Kasten.

When viewing audit logs, consider the following:

Authentication Mode

For correct user attribution, we depend on Veeam Kasten to be set up with OIDC or token-based authentication.

• OIDC: When OIDC is enabled, Kubernetes user impersonation will be used based on the email address extracted from the provided OIDC token.

• Token-based Authentication: When token-based authentication is enabled, the token is used directly for making API calls.

Request Attribution

Note that there are two callers of Veeam Kasten and Kubernetes APIs in the Veeam Kasten system. Actions triggered by the dashboard, CLI, or API will be attributed to the user that initiated them. Other system actions (e.g., validation of a Profile or Policy) will be attributed to the Veeam Kasten Service Account (SA).