Authentication audit logging - denote the authentication mechanism used.

[raesene]

What would you like to be added:

Logging for the authentication mechanism used by a user for requests to the API server.

Why is this needed:

At the moment Kubernetes does not put the mechanism used to authenticate a user into it's audit logs. As Kubernetes supports multiple authentication mechanisms, this could lead to a circumstance where an identical username is defined under different authentication schemes and it would be impossible to identify which had been used for a given request.

This is particularly serious in the case of client certificate authentication. As all that is required for the creation of client certificate credentials is access to the ca.key file for the cluster and credentials can be created using openssl commands, there may be no audit trail of users created with this mechanism.

An attacker who gained read-only access to that file would be able to create new credentials with the same usernames as users authenticated via other mechanisms, removing the ability of cluster operators to accurately audit user actions.

[raesene]

/sig auth

[danielqsj]

/cc

[mayakacz]

cc: @mikedanese

[tallclair]

related: #82379

[tallclair]

From sig-auth discussion 10/30: Consider adding an audit annotation.

[tedyu]

How about adding audit annotation key:

	annotationKey = "audit.k8s.io/auth-mechanism"

[tallclair]

Maybe authentication.k8s.io/plugin-name? Or might we want to subdivide different plugins?
(more consistent with the authorization annotaitons: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/endpoints/filters/authorization.go#L35)

As an asside, we should probably centralize the well-known audit annotations. Or should we consider promoting them to fields?

[tedyu]

'authentication.k8s.io/auth-mechanism' seems to be a bit more general compared to 'authentication.k8s.io/plugin-name'.

For this issue, probably introducing one audit annotation key suffices.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[tallclair]

/remove-lifecycle rotten
/assign @immutableT

Alex, would you be interested in tackling this as part of adding monitoring for the authentication method?

xref: #85113

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tallclair]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tallclair]

/remove-lifecycle stale

@immutableT - Are you still owning this? I'd like to get it in v1.20.

/milestone v1.20

[sayanchowdhury]

👋🏽 Hey @tallclair @immutableT ! I'm from the Bug Triage team. This issue has not been updated for a while, so I'd like to check on the status. The code freeze is starting November 12th (about 3 weeks from now) and while there is still plenty of time, we want to ensure that each PR has a chance to be merged on time.

As the issue is tagged for 1.20, is it still planned for this release?

[tallclair]

Unfortunately I think @immutableT is no longer working on Kubernetes, and I won't be able to get to this.

@mikedanese would anyone from your team be able to pick this up? Or maybe @micahhausler (I can't remember why this was assigned to you)?

/unassign @immutableT

[sayanchowdhury]

Hi @tallclair Since we have crossed the code freeze for 1.20, and there are not many updates in the issues I'm dropping the milestone. Please add the 1.21 milestone if you think the issue will be addressed in the next milestone.
/milestone clear

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[tallclair]

/remove-lifecycle stale

[tallclair]

/help

[k8s-ci-robot]

@tallclair:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.