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

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