Merge master into dev-1.21 to keep in sync

content/en/docs/reference/access-authn-authz/abac.md

@@ -19,7 +19,7 @@ Attribute-based access control (ABAC) defines an access control paradigm whereby
 To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
 
 The file format is [one JSON object per line](https://jsonlines.org/).  There
-should be no enclosing list or map, just one map per line.
+should be no enclosing list or map, only one map per line.
 
 Each line is a "policy object", where each such object is a map with the following
 properties:

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -193,7 +193,7 @@ This admission controller will deny exec and attach commands to pods that run wi
 allow host access.  This includes pods that run as privileged, have access to the host IPC namespace, and
 have access to the host PID namespace.
 
-The DenyEscalatingExec admission plugin is deprecated and will be removed in v1.21.
+The DenyEscalatingExec admission plugin is deprecated.
 
 Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin)
 which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
@@ -206,7 +206,7 @@ is recommended instead.
 This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.
 
 This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec).
-The DenyExecOnPrivileged admission plugin is deprecated and will be removed in v1.21.
+The DenyExecOnPrivileged admission plugin is deprecated.
 
 Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin)
 which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods

content/en/docs/reference/access-authn-authz/authentication.md

@@ -458,7 +458,7 @@ clusters:
   - name: name-of-remote-authn-service
     cluster:
       certificate-authority: /path/to/ca.pem         # CA for verifying the remote service.
-      server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.
+      server: https://authn.example.com/authenticate # URL of remote service to query. 'https' recommended for production.
 
 # users refers to the API server's webhook configuration.
 users:

content/en/docs/reference/access-authn-authz/authorization.md

@@ -138,7 +138,7 @@ no
 exposes the API server authorization to external services. Other resources in
 this group include:
 
-* `SubjectAccessReview` - Access review for any user, not just the current one. Useful for delegating authorization decisions to the API server. For example, the kubelet and extension API servers use this to determine user access to their own APIs.
+* `SubjectAccessReview` - Access review for any user, not only the current one. Useful for delegating authorization decisions to the API server. For example, the kubelet and extension API servers use this to determine user access to their own APIs.
 * `LocalSubjectAccessReview` - Like `SubjectAccessReview` but restricted to a specific namespace.
 * `SelfSubjectRulesReview` - A review which returns the set of actions a user can perform within a namespace. Useful for users to quickly summarize their own access, or for UIs to hide/show actions.
 

content/en/docs/reference/access-authn-authz/bootstrap-tokens.md

@@ -167,7 +167,7 @@ data:
     users: []
 ```
 
-The `kubeconfig` member of the ConfigMap is a config file with just the cluster
+The `kubeconfig` member of the ConfigMap is a config file with only the cluster
 information filled out.  The key thing being communicated here is the
 `certificate-authority-data`.  This may be expanded in the future.
 

content/en/docs/reference/access-authn-authz/certificate-signing-requests.md

@@ -196,8 +196,8 @@ O is the group that this user will belong to. You can refer to
 [RBAC](/docs/reference/access-authn-authz/rbac/) for standard groups.
 
 ```shell
-openssl genrsa -out john.key 2048
-openssl req -new -key john.key -out john.csr
+openssl genrsa -out myuser.key 2048
+openssl req -new -key myuser.key -out myuser.csr
 ```
 
 ### Create CertificateSigningRequest
@@ -209,7 +209,7 @@ cat <<EOF | kubectl apply -f -
 apiVersion: certificates.k8s.io/v1
 kind: CertificateSigningRequest
 metadata:
-  name: john
+  name: myuser
 spec:
   groups:
   - system:authenticated
@@ -224,7 +224,7 @@ Some points to note:
 
 - `usages` has to be '`client auth`'
 - `request` is the base64 encoded value of the CSR file content.
-  You can get the content using this command: ```cat john.csr | base64 | tr -d "\n"```
+  You can get the content using this command: ```cat myuser.csr | base64 | tr -d "\n"```
 
 ### Approve certificate signing request
 
@@ -239,7 +239,7 @@ kubectl get csr
 Approve the CSR:
 
 ```shell
-kubectl certificate approve john
+kubectl certificate approve myuser
 ```
 
 ### Get the certificate
@@ -247,11 +247,17 @@ kubectl certificate approve john
 Retrieve the certificate from the CSR:
 
 ```shell
-kubectl get csr/john -o yaml
+kubectl get csr/myuser -o yaml
 ```
 
 The certificate value is in Base64-encoded format under `status.certificate`.
 
+Export the issued certificate from the CertificateSigningRequest.
+
+```
+kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt
+```
+
 ### Create Role and RoleBinding
 
 With the certificate created. it is time to define the Role and RoleBinding for
@@ -266,31 +272,30 @@ kubectl create role developer --verb=create --verb=get --verb=list --verb=update
 This is a sample command to create a RoleBinding for this new user:
 
 ```shell
-kubectl create rolebinding developer-binding-john --role=developer --user=john
+kubectl create rolebinding developer-binding-myuser --role=developer --user=myuser
 ```
 
 ### Add to kubeconfig
 
 The last step is to add this user into the kubeconfig file.
-This example assumes the key and certificate files are located at "/home/vagrant/work/".
 
 First, you need to add new credentials:
 
 ```
-kubectl config set-credentials john --client-key=/home/vagrant/work/john.key --client-certificate=/home/vagrant/work/john.crt --embed-certs=true
+kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true
 
 ```
 
 Then, you need to add the context:
 
 ```
-kubectl config set-context john --cluster=kubernetes --user=john
+kubectl config set-context myuser --cluster=kubernetes --user=myuser
 ```
 
-To test it, change the context to `john`:
+To test it, change the context to `myuser`:
 
 ```
-kubectl config use-context john
+kubectl config use-context myuser
 ```
 
 ## Approval or rejection  {#approval-rejection}
@@ -363,7 +368,7 @@ status:
 
 It's usual to set `status.conditions.reason` to a machine-friendly reason
 code using TitleCase; this is a convention but you can set it to anything
-you like. If you want to add a note just for human consumption, use the
+you like. If you want to add a note for human consumption, use the
 `status.conditions.message` field.
 
 ## Signing
@@ -438,4 +443,3 @@ status:
 * View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
 * For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
 * For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
-

content/en/docs/reference/access-authn-authz/rbac.md

@@ -219,7 +219,7 @@ the role that is granted to those subjects.
 1. A binding to a different role is a fundamentally different binding.
 Requiring a binding to be deleted/recreated in order to change the `roleRef`
 ensures the full list of subjects in the binding is intended to be granted
-the new role (as opposed to enabling accidentally modifying just the roleRef
+the new role (as opposed to enabling or accidentally modifying only the roleRef
 without verifying all of the existing subjects should be given the new role's
 permissions).
 
@@ -333,7 +333,7 @@ as a cluster administrator, include rules for custom resources, such as those se
 or aggregated API servers, to extend the default roles.
 
 For example: the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource
-named CronTab, whereas the "view" role can perform just read actions on CronTab resources.
+named CronTab, whereas the "view" role can perform only read actions on CronTab resources.
 You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server.
 
 ```yaml