Change:
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

Discussion:
Secrets that a Pod requests are potentially visible within its containers. Therefore, one Pod does not have access to the Secrets of another Pod. <ins> ### Configure least-privilege access to Secrets To enhance the security measures around Secrets, Kubernetes provides a mechanism: you can annotate a ServiceAccount as `kubernetes.io/enforce-mountable-secrets: "true"`. For more information, you can refer to the [documentation about this annotation](/docs/concepts/security/service-accounts/#enforce-mountable-secrets). </ins> {{< warning >}} Any containers that run with `privileged: true` on a node can access all Secrets used on that node.

*  Implement audit rules that alert on specific events, such as concurrent reading of multiple Secrets by a single user <ins> #### Additional ServiceAccount annotations for Secret management You can also use the `kubernetes.io/enforce-mountable-secrets` annotation on a ServiceAccount to enforce specific rules on how Secrets are used in a Pod. For more details, see the [documentation on this annotation](/docs/reference/labels-annotations-taints/#enforce-mountable-secrets). </ins> ### Improve etcd management policies Consider wiping or shredding the durable storage used by `etcd` once it is

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

You should enable this admission controller if you intend to make any use of Kubernetes `ServiceAccount` objects. <ins> Regarding the annotation `kubernetes.io/enforce-mountable-secrets`: While the annotation's name suggests it only concerns the mounting of Secrets, its enforcement also extends to other ways Secrets are used in the context of a Pod. Therefore, it is crucial to ensure that all the referenced secrets are correctly specified in the ServiceAccount. </ins> ### StorageObjectInUseProtection **Type**: Mutating.

Used on: ServiceAccount The value for this annotation must be **true** to take effect. <del> This annotation indicates that Pods running as this ServiceAccount may only reference Secret API objects specified in the ServiceAccount's `secrets` field. </del> <ins> When you set this annotation  to "true", Kubernetes enforces the following rules for Pods running as this ServiceAccount: 1. Secrets mounted as volumes must be listed in the ServiceAccount's `secrets` field. 1. Secrets referenced in `envFrom` for containers (including sidecar containers and init containers) must also be listed in the ServiceAccount's secrets field. If any container in a Pod references a Secret not listed in the ServiceAccount's `secrets` field (and even if the reference is marked as `optional`), then the Pod will fail to start, and an error indicating the non-compliant secret reference will be generated. 1. Secrets referenced in a Pod's `imagePullSecrets` must be present in the ServiceAccount's `imagePullSecrets` field, the Pod will fail to start, and an error indicating the non-compliant image pull secret reference will be generated. When you create or update a Pod, these rules are checked. If a Pod doesn't follow them, it won't start and you'll see an error message. If a Pod is already running and you change the `kubernetes.io/enforce-mountable-secrets` annotation to true, or you edit the associated ServiceAccount to remove the reference to a Secret that the Pod is already using, the Pod continues to run. </ins> ### node.kubernetes.io/exclude-from-external-load-balancers