diff --git a/cn/docs/admin/kubelet-authentication-authorization.md b/cn/docs/admin/kubelet-authentication-authorization.md index 03ab5fd64b70b..4df5a3654911c 100644 --- a/cn/docs/admin/kubelet-authentication-authorization.md +++ b/cn/docs/admin/kubelet-authentication-authorization.md @@ -33,11 +33,9 @@ To enable X509 client certificate authentication to the kubelet's HTTPS endpoint To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint: * ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server -* start the kubelet with the `--authentication-token-webhook`, `--kubeconfig`, and `--require-kubeconfig` flags +* start the kubelet with the `--authentication-token-webhook` and the `--kubeconfig` flags * the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens -**Note:** The flag `--require-kubeconfig` is deprecated as of Kubernetes 1.8, this will be removed in a future version. You no longer need to use `--require-kubeconfig` in Kubernetes 1.8. - ## Kubelet authorization Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests. @@ -51,11 +49,9 @@ There are many possible reasons to subdivide access to the kubelet API: To subdivide access to the kubelet API, delegate authorization to the API server: * ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server -* start the kubelet with the `--authorization-mode=Webhook`, `--kubeconfig`, and `--require-kubeconfig` flags +* start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags * the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized -**Note:** The flag `--require-kubeconfig` is deprecated as of Kubernetes 1.8, this will be removed in a future version. You no longer need to use `--require-kubeconfig` in Kubernetes 1.8. - The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver. The verb is determined from the incoming request's HTTP verb: diff --git a/cn/docs/admin/kubelet-tls-bootstrapping.md b/cn/docs/admin/kubelet-tls-bootstrapping.md index 3297da10cdb5d..92abe801d6d6a 100644 --- a/cn/docs/admin/kubelet-tls-bootstrapping.md +++ b/cn/docs/admin/kubelet-tls-bootstrapping.md @@ -190,7 +190,6 @@ When starting the kubelet, if the file specified by `--kubeconfig` does not exis **Note:** The following flags are required to enable this bootstrapping when starting the kubelet: ``` ---require-kubeconfig --bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig" ``` diff --git a/docs/admin/kubelet-authentication-authorization.md b/docs/admin/kubelet-authentication-authorization.md index 03ab5fd64b70b..b867d3021ec66 100644 --- a/docs/admin/kubelet-authentication-authorization.md +++ b/docs/admin/kubelet-authentication-authorization.md @@ -33,11 +33,9 @@ To enable X509 client certificate authentication to the kubelet's HTTPS endpoint To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint: * ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server -* start the kubelet with the `--authentication-token-webhook`, `--kubeconfig`, and `--require-kubeconfig` flags +* start the kubelet with the `--authentication-token-webhook` and `--kubeconfig` flags * the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens -**Note:** The flag `--require-kubeconfig` is deprecated as of Kubernetes 1.8, this will be removed in a future version. You no longer need to use `--require-kubeconfig` in Kubernetes 1.8. - ## Kubelet authorization Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests. @@ -51,11 +49,9 @@ There are many possible reasons to subdivide access to the kubelet API: To subdivide access to the kubelet API, delegate authorization to the API server: * ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server -* start the kubelet with the `--authorization-mode=Webhook`, `--kubeconfig`, and `--require-kubeconfig` flags +* start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags * the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized -**Note:** The flag `--require-kubeconfig` is deprecated as of Kubernetes 1.8, this will be removed in a future version. You no longer need to use `--require-kubeconfig` in Kubernetes 1.8. - The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver. The verb is determined from the incoming request's HTTP verb: diff --git a/docs/admin/kubelet-tls-bootstrapping.md b/docs/admin/kubelet-tls-bootstrapping.md index da2b187dff205..a3f0c104b23d1 100644 --- a/docs/admin/kubelet-tls-bootstrapping.md +++ b/docs/admin/kubelet-tls-bootstrapping.md @@ -198,7 +198,6 @@ When starting the kubelet, if the file specified by `--kubeconfig` does not exis **Note:** The following flags are required to enable this bootstrapping when starting the kubelet: ``` ---require-kubeconfig --bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig" ```