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

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

@@ -677,9 +677,6 @@ for more information.
 This admission controller acts on creation and modification of the pod and determines if it should be admitted
 based on the requested security context and the available Pod Security Policies.
 
-For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
-extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
-
 See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
 for more information.
 

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

@@ -26,7 +26,7 @@ even a file with a list of usernames and passwords. In this regard, _Kubernetes
 does not have objects which represent normal user accounts._ Normal users
 cannot be added to a cluster through an API call.
 
-Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
+Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
 
 In contrast, service accounts are users managed by the Kubernetes API. They are
 bound to specific namespaces, and created automatically by the API server or

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

@@ -997,7 +997,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for
 ### Matching requests: matchPolicy
 
 API servers can make objects available via multiple API groups or versions.
-For example, the Kubernetes API server allows creating and modifying `Deployment` objects
+For example, the Kubernetes API server may allow creating and modifying `Deployment` objects
 via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs.
 
 For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`),

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

@@ -606,12 +606,15 @@ either do not manually edit the role, or disable auto-reconciliation.
 
 <table>
 <caption>Kubernetes RBAC API discovery roles</caption>
-<colgroup><col width="25%" /><col width="25%" /><col /></colgroup>
+<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup>
+<thead>
 <tr>
 <th>Default ClusterRole</th>
 <th>Default ClusterRoleBinding</th>
 <th>Description</th>
 </tr>
+</thead>
+<tbody>
 <tr>
 <td><b>system:basic-user</b></td>
 <td><b>system:authenticated</b> group</td>
@@ -627,6 +630,7 @@ either do not manually edit the role, or disable auto-reconciliation.
 <td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td>
 <td>Allows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.</td>
 </tr>
+</tbody>
 </table>
 
 ### User-facing roles
@@ -649,12 +653,15 @@ metadata:
 ```
 
 <table>
-<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup>
+<thead>
 <tr>
 <th>Default ClusterRole</th>
 <th>Default ClusterRoleBinding</th>
 <th>Description</th>
 </tr>
+</thead>
+<tbody>
 <tr>
 <td><b>cluster-admin</b></td>
 <td><b>system:masters</b> group</td>
@@ -691,17 +698,21 @@ the contents of Secrets enables access to ServiceAccount credentials
 in the namespace, which would allow API access as any ServiceAccount
 in the namespace (a form of privilege escalation).</td>
 </tr>
+</tbody>
 </table>
 
 ### Core component roles
 
 <table>
-<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup>
+<thead>
 <tr>
 <th>Default ClusterRole</th>
 <th>Default ClusterRoleBinding</th>
 <th>Description</th>
 </tr>
+</thead>
+<tbody>
 <tr>
 <td><b>system:kube-scheduler</b></td>
 <td><b>system:kube-scheduler</b> user</td>
@@ -733,17 +744,21 @@ The <tt>system:node</tt> role only exists for compatibility with Kubernetes clus
 <td><b>system:kube-proxy</b> user</td>
 <td>Allows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.</td>
 </tr>
+</tbody>
 </table>
 
 ### Other component roles
 
 <table>
-<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<colgroup><col style="width: 25%;" /><col style="width: 25%;" /><col /></colgroup>
+<thead>
 <tr>
 <th>Default ClusterRole</th>
 <th>Default ClusterRoleBinding</th>
 <th>Description</th>
 </tr>
+</thead>
+<tbody>
 <tr>
 <td><b>system:auth-delegator</b></td>
 <td>None</td>
@@ -786,6 +801,7 @@ This is commonly used by add-on API servers for unified authentication and autho
 <td>None</td>
 <td>Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.</td>
 </tr>
+<tbody>
 </table>
 
 ### Roles for built-in controllers {#controller-roles}