Merge remote-tracking branch 'upstream/master' into dev-1.20

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -419,8 +419,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
    See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
    for more details.
 - `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume consisting of a
-   ServiceAccountTokenVolumeProjection.
-   Check [Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)
+   ServiceAccountTokenVolumeProjection. Cluster admins can use metric `serviceaccount_stale_tokens_total` to
+   monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off
+   extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`.
+   Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
    for more details.
 - `ConfigurableFSGroupPolicy`: Allows user to configure volume permission change policy for fsGroups when mounting a volume in a Pod. See [Configure volume permission and ownership change policy for Pods](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods) for more details.
 - `CronJobControllerV2`: Use an alternative implementation of the {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} controller. Otherwise, version 1 of the same controller is selected. The version 2 controller provides experimental performance improvements.

content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md

@@ -415,6 +415,17 @@ approve node _serving_ certificates for [security
 reasons](https://github.com/kubernetes/community/pull/1982). To use
 `RotateKubeletServerCertificate` operators need to run a custom approving
 controller, or manually approve the serving certificate requests.
+
+A deployment-specific approval process for kubelet serving certificates should typically only approve CSRs which:
+
+1. are requested by nodes (ensure the `spec.username` field is of the form 
+   `system:node:<nodeName>` and `spec.groups` contains `system:nodes`) 
+2. request usages for a serving certificate (ensure `spec.usages` contains `server auth`, 
+   optionally contains `digital signature` and `key encipherment`, and contains no other usages)
+3. only have IP and DNS subjectAltNames that belong to the requesting node, 
+   and have no URI and Email subjectAltNames (parse the x509 Certificate Signing Request 
+   in `spec.request` to verify `subjectAltNames`)
+
 {{< /note >}}
 
 ## Other authenticating components

content/en/docs/reference/kubectl/cheatsheet.md

@@ -311,6 +311,7 @@ kubectl run nginx --image=nginx                     # Run pod nginx and write it
 kubectl attach my-pod -i                            # Attach to Running Container
 kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
 kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case)
+kubectl exec --stdin --tty my-pod -- /bin/sh        # Interactive shell access to a running pod (1 container case) 
 kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case)
 kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers
 ```