fix(audit): log user for filtered requests

[anisimov-es]

Summary

Capsule Proxy forwards filtered cross-namespace requests using its own ServiceAccount. As a result, the Kubernetes API server audit event cannot include the original caller in impersonatedUser.

This change adds a structured V(4) Proxy log before the caller token is replaced:

{
  "msg": "proxying filtered request",
  "username": "system:serviceaccount:<namespace>:<name>",
  "method": "GET",
  "uri": "/api/v1/secrets"
}

The log makes the authenticated caller observable for requests handled through the selector/filter path, without logging bearer tokens or groups. It gives security teams a reliable way to attribute filtered API requests to the originating user or ServiceAccount, instead of inferring the caller from a proxy IP address or treating successful requests as unattributed.

Changes

• Pass the resolved username to handleRequest.
• Log the username, HTTP method, and URI before the proxy replaces the request bearer token with its ServiceAccount token.
• Keep existing impersonation behavior unchanged.

Validation

• make golint
• go test $(go list ./... | grep -v /e2e/)
• Manual validation in a local Kubernetes cluster:

  • Created a Tenant owned by a dedicated ServiceAccount.

  • Created three Tenant namespaces, a BusyBox workload, and one Secret per namespace.

  • Requested GET /api/v1/secrets?limit=500 through Capsule Proxy using the ServiceAccount token.

  • The response contained only the three Tenant secrets.

  • Capsule Proxy emitted:

    {
      "msg": "proxying filtered request",
      "username": "system:serviceaccount:capsule-audit-client:audit-user",
      "method": "GET",
      "uri": "/api/v1/secrets"
    }

[anisimov-es]

@oliverbaehler thank you