Merge pull request #33130 from tengqm/move-kubelet-authn-authz
Move kubelet authn authz
This commit is contained in:
Kubernetes Prow Robot
@@ -24,3 +24,5 @@ Reference documentation:
|
||||
- Service accounts
|
||||
- [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
- [Administration](/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
- [Kubelet Authentication & Authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
- including kubelet [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
|
||||
@@ -15,7 +15,7 @@ creating new clusters or joining new nodes to an existing cluster. It was built
|
||||
to support [kubeadm](/docs/reference/setup-tools/kubeadm/), but can be used in other contexts
|
||||
for users that wish to start clusters without `kubeadm`. It is also built to
|
||||
work, via RBAC policy, with the
|
||||
[Kubelet TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system.
|
||||
[Kubelet TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) system.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -43,7 +43,7 @@ have the minimal set of permissions required to operate correctly.
|
||||
In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as
|
||||
being in the `system:nodes` group, with a username of `system:node:<nodeName>`.
|
||||
This group and user name format match the identity created for each kubelet as part of
|
||||
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
|
||||
[kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/).
|
||||
|
||||
The value of `<nodeName>` **must** match precisely the name of the node as registered by the kubelet. By default, this is the host name as provided by `hostname`, or overridden via the [kubelet option](/docs/reference/command-line-tools-reference/kubelet/) `--hostname-override`. However, when using the `--cloud-provider` kubelet option, the specific hostname may be determined by the cloud provider, ignoring the local `hostname` and the `--hostname-override` option.
|
||||
For specifics about how the kubelet determines the hostname, see the [kubelet options reference](/docs/reference/command-line-tools-reference/kubelet/).
|
||||
|
||||
@@ -798,7 +798,7 @@ This is commonly used by add-on API servers for unified authentication and autho
|
||||
<td><b>system:node-bootstrapper</b></td>
|
||||
<td>None</td>
|
||||
<td>Allows access to the resources required to perform
|
||||
<a href="/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/">kubelet TLS bootstrapping</a>.</td>
|
||||
<a href="/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/">kubelet TLS bootstrapping</a>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>system:node-problem-detector</b></td>
|
||||
|
||||
@@ -1086,10 +1086,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
[Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
|
||||
for more details.
|
||||
- `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
|
||||
See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)
|
||||
See [kubelet configuration](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)
|
||||
for more details.
|
||||
- `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet.
|
||||
See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)
|
||||
See [kubelet configuration](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)
|
||||
for more details.
|
||||
- `RunAsGroup`: Enable control over the primary group ID set on the init
|
||||
processes of containers.
|
||||
|
||||
@@ -219,7 +219,7 @@ Other API server flags that are set unconditionally are:
|
||||
|
||||
- `--insecure-port=0` to avoid insecure connections to the api server
|
||||
- `--enable-bootstrap-token-auth=true` to enable the `BootstrapTokenAuthenticator` authentication module.
|
||||
See [TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for more details
|
||||
See [TLS Bootstrapping](/docs/reference/access-authn-authn/kubelet-tls-bootstrapping/) for more details
|
||||
- `--allow-privileged` to `true` (required e.g. by kube proxy)
|
||||
- `--requestheader-client-ca-file` to `front-proxy-ca.crt`
|
||||
- `--enable-admission-plugins` to:
|
||||
@@ -266,7 +266,7 @@ The static Pod manifest for the controller manager is affected by following para
|
||||
Other flags that are set unconditionally are:
|
||||
|
||||
- `--controllers` enabling all the default controllers plus `BootstrapSigner` and `TokenCleaner` controllers for TLS bootstrap.
|
||||
See [TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for more details
|
||||
See [TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for more details
|
||||
- `--use-service-account-credentials` to `true`
|
||||
- Flags for using certificates generated in previous steps:
|
||||
- `--root-ca-file` to `ca.crt`
|
||||
|
||||
@@ -52,7 +52,7 @@ following steps:
|
||||
|
||||
1. Makes all the necessary configurations for allowing node joining with the
|
||||
[Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and
|
||||
[TLS Bootstrap](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
[TLS Bootstrap](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
mechanism:
|
||||
|
||||
- Write a ConfigMap for making available all the information required
|
||||
|
||||
Reference in New Issue
Block a user