Document well-known audit annotations

[tallclair]

Similar to https://kubernetes.io/docs/reference/labels-annotations-taints/ (should probably be a separate page though).

The current (2023-02-08) list of well-known audit annotations is:

• authorization.k8s.io/decision
• authorization.k8s.io/reason
• podsecuritypolicy.policy.k8s.io/admit-policy
• podsecuritypolicy.policy.k8s.io/validate-policy
• [PodSecurity] Extra audit annotations kubernetes#103923
• authentication.k8s.io/stale-token
• authentication.k8s.io/legacy-token
• apiserver.latency.k8s.io/transform-response-object
• apiserver.latency.k8s.io/etcd
• apiserver.latency.k8s.io/serialize-response-object
• apiserver.latency.k8s.io/response-write
• apiserver.latency.k8s.io/mutating-webhook
• apiserver.latency.k8s.io/validating-webhook
• apiserver.latency.k8s.io/total
• k8s.io/deprecated
• k8s.io/removed-release

[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.

[sftim]

/sig auth
(I think)

[borkod]

@sftim @tallclair Is the idea to create a new reference page or just add the annotations to the above page? I guess I am trying to understand the reasoning for creating a new page vs adding the annotations to the page references above. In either case, I would love to help with this and take a first attempt at it 😃

[tallclair]

I think that page (https://kubernetes.io/docs/reference/labels-annotations-taints/) would be more useful if it were reorganized with headings for each of the resources the annotations apply to, and then we could just add a section for audit events.

topology.kubernetes.io/zone looks like the only one that's used on multiple resources, but it already has a separate description for each - so I think it would be preferable to split it into 2 separate sections (one under node, and one under PVs)

[borkod]

I like that idea. I'll work on implementing something along those lines 😃

[borkod]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale