Change:
You can also use TokenRequest to obtain short-lived tokens for your external application. {{< /note >}} <ins> ### Restricting access to Secrets {#enforce-mountable-secrets} Kubernetes provides an annotation called `kubernetes.io/enforce-mountable-secrets` that you can add to your ServiceAccounts. When this annotation is applied, the ServiceAccount's secrets can only be mounted on specified types of resources, enhancing the security posture of your cluster. You can add the annotation to a ServiceAccount using a manifest: ```yaml apiVersion: v1 kind: ServiceAccount metadata: annotations: kubernetes.io/enforce-mountable-secrets: "true" name: my-serviceaccount namespace: my-namespace ``` When this annotation is set to "true", the Kubernetes control plane ensures that the Secrets from this ServiceAccount are subject to certain mounting restrictions. 1. The name of each Secret that is mounted as a volume in a Pod must appear in the `secrets` field of the Pod's ServiceAccount. 1. The name of each Secret referenced using `envFrom` in a Pod must also appear in the `secrets` field of the Pod's ServiceAccount. 1. The name of each Secret referenced using `imagePullSecrets` in a Pod must also appear in the `secrets` field of the Pod's ServiceAccount. By understanding and enforcing these restrictions, cluster administrators can maintain a tighter security profile and ensure that secrets are accessed only by the appropriate resources. </ins> ## Authenticating service account credentials {#authenticating-credentials} ServiceAccounts use signed

Discussion:
The documentation for the annotation on consists of : This leaves unclear the details of the actual effect of the annotation. By checking I was able to determine that setting this annotation to causes the following enforcements: (1) s mounted as must appear in the 's (2) s referenced in in or must appear in the 's (3) s referenced in of s must appear in the 's (1) is implied by the name of the annotation, but the lack of any mention of (2) or (3) in the documentation forced me to check the code to ensure that it wasn't only enforcing mounting of s as the name implies. The documentation also mentions only the field of the , yet the enforcement also takes into account the 's field (which the 's are checked against). The documentation would be improved by describing the actual enforcement behaviour that this feature implements. This feature may also benefit from being mentioned in the document.
/triage accepted /help /kind feature
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /help /kind feature </details
I see , can come up with something like: I'll take this up?
/assign