Currently, if an Audit-ID header is provided with a request, the apiserver uses that audit-id for the audit events recorded for that request. The motivation for this was to track requests across aggregate API servers in the audit logs. The problem is that it inherently trusts the audit ID provided by the client. This isn't directly a problem in Kubernetes, but if an external system is aggregating or deduplicating audit events based on ID, a malicious user could potentially cover their tracks by reusing audit IDs.

Option 1: new Audit ID Chain

1. Add an AuditIDChain field to the audit event API
2. When API server receives a request with a Audit-ID header, set the audit ID chain to the audit-ID header, but still generate a unique ID for that request
3. In the response, set the Audit-ID header to the full audit ID chain (request chain + new ID)
4. When delegating a request to an aggregate apiserver, set the Audit-ID header to the full audit chain (same as used in step 3)

Option 2: trusted Audit IDs (breaking)

Require some form of trust to use the header audit ID. The simplest option would probably be to use a staticly defined ACL based on the authenticated user.

Option 3: ignore the header (very breaking)

Discard the audit ID header. This could be softened by making the option conifgurable, so the "front" apiserver can discard the header-based ID, but agregated apiservers can still use it.

/sig auth api-machinery