Auditing K10

Independent of whether the dashboard, CLI, or API is used to access K10, the usage translates into native Kubernetes API calls. K10 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 K10 event that does not use this API will not get logged. The ongoing work with integrating K10 more closely with Security Information and Event Management (SIEM) platforms, such as with Datadog, will allow for a more robust auditing of K10.

When viewing audit logs, consider the following:

Authentication Mode

For correct user attribution, we depend on K10 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 K10 and Kubernetes APIs in the K10 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 K10 Service Account (SA).