-
-
-| デフォルトのClusterRole |
-デフォルトのClusterRoleBinding |
-説明 |
-
-
-| system:kube-scheduler |
-system:kube-scheduler user |
-{{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}コンポーネントが必要とするリソースへのアクセスを許可します。 |
-
-
-| system:volume-scheduler |
-system:kube-scheduler user |
-kube-scheduleコンポーネントが必要とするリソースへのアクセスを許可します。 |
-
-
-| system:kube-controller-manager |
-system:kube-controller-manager user |
-{{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}}コンポーネントが必要とするリソースへのアクセスを許可します。
-個々のコントローラーに必要な権限については、組み込みコントローラーのRoleで詳しく説明しています。 |
-
-
-| system:node |
-None |
-すべてのsecretへの読み取りアクセス、すべてのポッドステータスオブジェクトへの書き込みアクセスなど、kubeletが必要とするリソースへのアクセスを許可します。
-
-system:nodeRoleの代わりにNode authorizerと NodeRestriction admission pluginを使用し、それらで実行するようにスケジュールされたPodに基づいてkubeletへのAPIアクセスを許可する必要があります。
-
-system:nodeのRoleは、V1.8より前のバージョンからアップグレードしたKubernetesクラスターとの互換性のためだけに存在します。
- |
-
-
-| system:node-proxier |
-system:kube-proxy user |
-{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}コンポーネントが必要とするリソースへのアクセスを許可します。 |
-
-
-
-### 他のコンポーネントのRole
-
-
-
-
-| デフォルトのClusterRole |
-デフォルトのClusterRoleBinding |
-説明 |
-
-
-| system:auth-delegator |
-None |
-委任された認証と認可のチェックを許可します。
-これは一般に、認証と認可を統合するためにアドオンAPIサーバーで使用されます。 |
-
-
-| system:heapster |
-None |
-HeapsterコンポーネントのRole(非推奨)。 |
-
-
-| system:kube-aggregator |
-None |
-kube-aggregatorコンポーネントのRole。 |
-
-
-| system:kube-dns |
-kube-systemNamespaceのサービスアカウントkube-dns |
-kube-dnsコンポーネントのRole。 |
-
-
-| system:kubelet-api-admin |
-None |
-kubelet APIへのフルアクセスを許可します。 |
-
-
-| system:node-bootstrapper |
-None |
-kubelet TLS bootstrappingの実行に必要なリソースへのアクセスを許可します。 |
-
-
-| system:node-problem-detector |
-None |
-node-problem-detectorコンポーネントのRole。 |
-
-
-| system:persistent-volume-provisioner |
-None |
-ほとんどのdynamic volume provisionersが必要とするリソースへのアクセスを許可します。 |
-
-
-
-### 組み込みコントローラーのRole {#controller-roles}
-
-Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}}は、Kubernetesコントロールプレーンに組み込まれている{{< glossary_tooltip term_id="controller" text="controllers" >}}を実行します。
-`--use-service-account-credentials`を指定して呼び出すと、kube-controller-manager個別のサービスアカウントを使用して各コントローラーを起動します。
-組み込みコントローラーごとに、プレフィックス`system:controller:`付きの対応するRoleが存在します。
-コントローラーマネージャーが`--use-service-account-credentials`で開始されていない場合、コントローラマネージャーは、関連するすべてのRoleを付与する必要がある自身のクレデンシャルを使用して、すべてのコントロールループを実行します。
-これらのRoleは次のとおりです。
-
-* `system:controller:attachdetach-controller`
-* `system:controller:certificate-controller`
-* `system:controller:clusterrole-aggregation-controller`
-* `system:controller:cronjob-controller`
-* `system:controller:daemon-set-controller`
-* `system:controller:deployment-controller`
-* `system:controller:disruption-controller`
-* `system:controller:endpoint-controller`
-* `system:controller:expand-controller`
-* `system:controller:generic-garbage-collector`
-* `system:controller:horizontal-pod-autoscaler`
-* `system:controller:job-controller`
-* `system:controller:namespace-controller`
-* `system:controller:node-controller`
-* `system:controller:persistent-volume-binder`
-* `system:controller:pod-garbage-collector`
-* `system:controller:pv-protection-controller`
-* `system:controller:pvc-protection-controller`
-* `system:controller:replicaset-controller`
-* `system:controller:replication-controller`
-* `system:controller:resourcequota-controller`
-* `system:controller:root-ca-cert-publisher`
-* `system:controller:route-controller`
-* `system:controller:service-account-controller`
-* `system:controller:service-controller`
-* `system:controller:statefulset-controller`
-* `system:controller:ttl-controller`
-
-## 特権昇格の防止とブートストラップ
-
-RBAC APIは、RoleまたはRoleBindingを編集することにより、ユーザーが特権を昇格するのを防ぎます。
-これはAPIレベルで適用されるため、RBAC authorizerが使用されていない場合でも適用されます。
-
-### Roleの作成または更新に関する制限
-
-次の項目1つ以上が当てはまる場合にのみ、Roleを作成/更新できます。
-
-1. 変更対象のオブジェクトと同じスコープで、Roleに含まれるすべての権限を既に持っている(ClusterRoleの場合はクラスター全体。Roleの場合は、同じNamespace内またはクラスター全体)。
-2. `rbac.authorization.k8s.io`APIグループの` roles`または`clusterroles`リソースで` escalate` verbを実行する明示的な権限が付与されている。
-
-たとえば、 `user-1`にクラスター全体でSecretsを一覧表示する権限がない場合、それらにその権限を含むClusterRoleを作成できません。
-ユーザーがRoleを作成/更新できるようにするには、以下のいずれかを実施します。
-
-1. 必要に応じて、RoleオブジェクトまたはClusterRoleオブジェクトを作成/更新できるRoleを付与する。
-2. 作成/更新するRoleに特定の権限を含む権限を付与する。
- * 暗黙的に、これらの権限を付与することにより(自分自身が付与されていない権限でRoleまたはClusterRoleを作成または変更しようとすると、APIリクエストは禁止されます)。
- * または、`rbac.authorization.k8s.io`APIグループの` roles`または `clusterroles`リソースで` escalate` verbを実行する権限を与えることにより、 `Role`または` ClusterRole`で権限を指定することを明示的に許可する
-
-### RoleBindingの作成または更新に関する制限
-
-参照されるRoleに含まれるすべての権限を(RoleBindingと同じスコープで)すでに持っている場合、
-*または*参照されたRoleで`bind` verbを実行する認可されている場合のみ、RoleBindingを作成/更新できます。
-たとえば、 `user-1`にクラスター全体でSecretsを一覧表示する権限がない場合、ClusterRoleBindingを作成してもRoleにその権限を付与できません。
-ユーザーがRoleBindingを作成/更新できるようにするには、以下のいずれかを実施します。
-
-1. 必要に応じて、RoleBindingまたはClusterRoleBindingオブジェクトを作成/更新できるようにする役割を付与する。
-2. 特定の役割をバインドするために必要なアクセス許可を付与する。
- * 暗黙的に、Roleに含まれる権限を付与することによって。
- * 明示的に、特定のRole(またはClusterRole)で `bind` verbを実行する許可を与えることによって。
-
-たとえば、このClusterRoleとRoleBindingを使用すると、 `user-1`は他のユーザーにNamespace` user-1-namespace`の `admin`、` edit`、および `view`Roleを付与します。
-
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
- name: role-grantor
-rules:
-- apiGroups: ["rbac.authorization.k8s.io"]
- resources: ["rolebindings"]
- verbs: ["create"]
-- apiGroups: ["rbac.authorization.k8s.io"]
- resources: ["clusterroles"]
- verbs: ["bind"]
- resourceNames: ["admin","edit","view"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
- name: role-grantor-binding
- namespace: user-1-namespace
-roleRef:
- apiGroup: rbac.authorization.k8s.io
- kind: ClusterRole
- name: role-grantor
-subjects:
-- apiGroup: rbac.authorization.k8s.io
- kind: User
- name: user-1
-```
-
-最初のRoleとRoleBindingをブートストラップするときは、最初のユーザーがまだ持っていない権限を付与する必要があります。
-初期RoleとRoleBindingをブートストラップするには、以下のいずれかを実施します。
-
-* 「system：masters」グループのクレデンシャルを使用します。このグループは、デフォルトのBindingによって「cluster-admin」スーパーユーザーRoleにバインドされています。
-* APIサーバーが安全でないポート(`--insecure-port`)を有効にして実行されている場合、そのポートを介してのAPI呼び出しもできます。これにより、認証や認可が実行されません。
-
-## コマンドラインユーティリティー
-
-### `kubectl create role`
-
-以下に、単一のNamespace内で権限を定義するRoleオブジェクトをいくつか例として作成します。
-
-* ユーザーがポッドで `get`、` watch`、および `list`を実行できるように「pod-reader」という名前のRoleを作成します。
-
- ```shell
- kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
- ```
-
-* resourceNamesを指定して、「pod-reader」という名前のRoleを作成します。
-
- ```shell
- kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
- ```
-
-* apiGroupsを指定して「foo」という名前のRoleを作成します。
-
- ```shell
- kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
- ```
-
-* サブリソースの権限を持つ「foo」という名前のRoleを作成します。
-* Create a Role named "foo" with subresource permissions:
-
- ```shell
- kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
- ```
-* 特定の名前のリソースを取得/更新する権限を持つ「my-component-lease-holder」という名前のRoleを作成します。
-
- ```shell
- kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
- ```
-
-### `kubectl create clusterrole`
-
-以下にClusterRoleをいくつか例として作成します。
-
-* ユーザーがポッドに対して`get`、` watch`、および `list`を実行できるようにする「pod-reader」という名前のClusterRoleを作成します。
-
- ```shell
- kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
- ```
-
-* resourceNamesを指定して、「pod-reader」という名前のClusterRoleを作成します。
-
- ```shell
- kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
- ```
-
-* apiGroupsを指定して「foo」という名前のClusterRoleを作成します。
-
- ```shell
- kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
- ```
-
-* サブリソースの権限を持つ「foo」という名前のClusterRoleを作成します。
-
- ```shell
- kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
- ```
-
-* nonResourceURLを指定して「foo」という名前のClusterRoleを作成します。
-
- ```shell
- kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
- ```
-
-* aggregationRuleを指定して、「monitoring」という名前のClusterRoleを作成します。
-
- ```shell
- kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
- ```
-
-### `kubectl create rolebinding`
-
-以下に、特定のNamespace内でRoleまたはClusterRoleをいくつか例として付与します。
-
-* Namespace「acme」内で、「admin」ClusterRoleの権限を「bob」という名前のユーザーに付与します。
-
- ```shell
- kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
- ```
-
-* Namespace「acme」内で、ClusterRole「view」へのアクセス許可を「myapp」というNamespace「acme」のサービスアカウントに付与します。
-
- ```shell
- kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
- ```
-
-* Namespace「acme」内で、ClusterRole「view」へのアクセス許可を「myapp」というNamespace「myappnamespace」のサービスアカウントに付与します。
-
- ```shell
- kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
- ```
-
-### `kubectl create clusterrolebinding`
-
-以下に、クラスタ全体(すべてのNamespace)にClusterRoleをいくつか例として付与します。
-
-* クラスター全体で、ClusterRole「cluster-admin」へのアクセス許可を「root」という名前のユーザーに付与します。
-
- ```shell
- kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
- ```
-
-* クラスター全体で、ClusterRole「system：node-proxier」へのアクセス許可を「system：kube-proxy」という名前のユーザーに付与します。
-
- ```shell
- kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
- ```
-
-* クラスター全体で、ClusterRole「view」へのアクセス許可を、Namespace「acme」の「myapp」という名前のサービスアカウントに付与します。
-
- ```shell
- kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
- ```
-
-### `kubectl auth reconcile` {#kubectl-auth-reconcile}
-
-マニフェストファイルから `rbac.authorization.k8s.io/v1`APIオブジェクトを作成または更新します。
-
-欠落しているオブジェクトが作成され、必要に応じて、Namespaceに属するオブジェクト用にオブジェクトを含むNamespaceが作成されます。
-
-既存のRoleが更新され、入力オブジェクトに権限が含まれるようになります。
-`--remove-extra-permissions`が指定されている場合は、余分な権限を削除します。
-
-既存のBindingが更新され、入力オブジェクトにsubjectsが含まれるようになります。
-`--remove-extra-subjects`が指定されている場合は、余分な件名を削除します。
-
-以下、例として。
-
-* RBACオブジェクトのマニフェストファイルをテストとして適用し、行われる変更を表示します。
-
- ```
- kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
- ```
-
-* RBACオブジェクトのマニフェストファイルを適用し、(Role内の)追加のアクセス許可と(Binding内の)追加のsubjectsを保持します。
-
- ```shell
- kubectl auth reconcile -f my-rbac-rules.yaml
- ```
-
-* RBACオブジェクトのマニフェストファイルを適用し、(Role内の)余分なアクセス許可と(Binding内の)余分なsubjectsを削除します。
-
-## ServiceAccount権限 {#service-account-permissions}
-
-デフォルトのRBACポリシーは、コントロールプレーンコンポーネント、ノード、
-およびコントローラーをスコープとして権限を付与しますが、 Namespace`kube-system`外のサービスアカウントには*no permissions*で付与します
-(すべての認証されたユーザーに与えられたディスカバリー権限に関わらず)。
-
-これにより、必要に応じて特定のServiceAccountに特定のRoleを付与できます。
-きめ細かいRoleBindingはセキュリティを強化しますが、管理にはより多くの労力が必要です。
-より広範な権限は、不必要な(そして潜在的にエスカレートする)APIアクセスをServiceAccountsに与える可能性がありますが、管理が簡単です。
-
-アプローチを最も安全なものから最も安全でないものの順に並べると、次のとおりです。
-
-1. アプリケーション固有のサービスアカウントにRoleを付与する(ベストプラクティス)
- これには、アプリケーションがpodのspec、そして作成するサービスアカウント(API、アプリケーションマニフェスト、 `kubectl create serviceaccount`などを介して）で`serviceAccountName`を指定する必要があります。
- たとえば、「my-namespace」内の読み取り専用権限を「my-sa」サービスアカウントに付与します。
-
- ```shell
- kubectl create rolebinding my-sa-view \
- --clusterrole=view \
- --serviceaccount=my-namespace:my-sa \
- --namespace=my-namespace
- ```
-
-2. あるNamespaceのサービスアカウント「default」にRoleを付与します
-
- アプリケーションが `serviceAccountName`を指定しない場合、サービスアカウント「default」を使用します。
-
- {{< note >}}
- サービスアカウント「default」に付与された権限は、`serviceAccountName`を指定しないNamespace内のすべてのポッドで利用できます。
- {{< /note >}}
-
- たとえば、「my-namespace」内の読み取り専用権限をサービスアカウント「default」に付与します。
-
- ```shell
- kubectl create rolebinding default-view \
- --clusterrole=view \
- --serviceaccount=my-namespace:default \
- --namespace=my-namespace
- ```
-
- 多くの[アドオン](https://kubernetes.io/docs/concepts/cluster-administration/addons/)は、
- Namespace`kube-system`のサービスアカウント「default」として実行されます。
- これらのアドオンをスーパーユーザーアクセスでの実行を許可するには、Namespace`kube-system`のサービスアカウント「default」のcluster-admin権限を付与します。
-
- {{< caution >}}
- これを有効にすると、 Namespace`kube-systemにクラスターのAPIへのスーパーユーザーアクセス許可するSecretsが含まれます。
- {{< /caution >}}
-
- ```shell
- kubectl create clusterrolebinding add-on-cluster-admin \
- --clusterrole=cluster-admin \
- --serviceaccount=kube-system:default
- ```
-
-3. Namespace内のすべてのサービスアカウントにRoleを付与します
-
- Namespace内のすべてのアプリケーションにRoleを持たせたい場合は、使用するサービスアカウントに関係なく、
- そのNamespaceのサービスアカウントグループにRoleを付与できます。
-
- たとえば、「my-namespace」内の読み取り専用アクセス許可を、そのNamespace内のすべてのサービスアカウントに付与します。
-
- ```shell
- kubectl create rolebinding serviceaccounts-view \
- --clusterrole=view \
- --group=system:serviceaccounts:my-namespace \
- --namespace=my-namespace
- ```
-
-4. クラスター全体のすべてのサービスアカウントに制限されたRoleを付与します(お勧めしません)
-
- Namespaceごとのアクセス許可を管理したくない場合は、すべてのサービスアカウントにクラスター全体の役割を付与できます。
-
- たとえば、クラスター内のすべてのサービスアカウントに、すべてのNamespaceで読み取り専用のアクセス許可を付与します。
-
- ```shell
- kubectl create clusterrolebinding serviceaccounts-view \
- --clusterrole=view \
- --group=system:serviceaccounts
- ```
-
-5. クラスター全体のすべてのサービスアカウントへのスーパーユーザーアクセスを許可します。(強くお勧めしません)
-
- 権限の分割をまったく考慮しない場合は、すべてのサービスアカウントにスーパーユーザーアクセスを許可できます。
-
- {{< warning >}}
- これにより、すべてのアプリケーションにクラスターへのフルアクセスが許可され、Secretsの読み取りアクセス権(または任意のポッドを作成する機能)を持つユーザーに、クラスターへのフルアクセスが許可されます。
- {{< /warning >}}
-
- ```shell
- kubectl create clusterrolebinding serviceaccounts-cluster-admin \
- --clusterrole=cluster-admin \
- --group=system:serviceaccounts
- ```
-
-## ABACからアップグレードする
-
-以前は古いバージョンのKubernetesを実行していたクラスターは、すべてのサービスアカウントに完全なAPIアクセスを許可するなど、permissiveなABACポリシーを使用することがよくありました。
-
-デフォルトのRBACポリシーは、コントロールプレーンコンポーネント、ノード、
-およびコントローラーをスコープとして権限を付与しますが、 Namespace`kube-system`外のサービスアカウントには*no permissions*で付与します
-(すべての認証されたユーザーに与えられたディスカバリー権限に関わらず)。
-
-これははるかに安全ですが、API権限を自動的に受け取ることを期待している既存のワークロードを混乱させる可能性があります。
-この移行を管理するための2つのアプローチは次のとおりです。
-
-### 並行認可
-
-
-RBACとABACの両方のauthorizerを実行し、[legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format)を含むポリシーファイルを指定します。
-
-```
---authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json
-```
-
-最初のコマンドラインオプションを詳細に説明すると、Nodeなどの以前のauthorizerが
-要求を拒否すると、RBAC authorizerはAPI要求を認可しようとします。 RBACの場合
-また、そのAPI要求を拒否すると、ABAC authorizerが実行されます。これにより、すべてのリクエストが
-RBACまたはABACポリシーの*いずれか*で許可されます。
-
-RBACコンポーネントのログレベルが5以上でkube-apiserverを実行した場合(`--vmodule = rbac * = 5`または` --v = 5`)、APIサーバーログでRBACの拒否を確認できます(プレフィックスは「RBAC」)。
-その情報を使用して、どのRoleをどのユーザー、グループ、またはサービスアカウントに付与する必要があるかを判断できます。
-
-[サービスアカウントに付与されたRole](#service-account-permissions)を取得し、
-ワークロードがサーバーログにRBACの拒否メッセージがない状態で実行されている場合は、ABAC authorizerを削除できます。
-
-### Permissive RBAC権限
-
-RBACRoleBindingを使用して、permissive ABACポリシーを複製できます。
-
-{{< warning >}}
-次のポリシーでは、**すべて**のサービスアカウントがクラスター管理者としてふるまうことを許可しています。
-コンテナで実行されているアプリケーションは、サービスアカウントのクレデンシャルを自動的に受け取ります。
-secretsの表示や権限の変更など、APIに対して任意のアクションを実行できます。
-これは推奨されるポリシーではありません。
-
-```shell
-kubectl create clusterrolebinding permissive-binding \
- --clusterrole=cluster-admin \
- --user=admin \
- --user=kubelet \
- --group=system:serviceaccounts
-```
-{{< /warning >}}
-
-RBACの使用に移行後、クラスターが情報セキュリティのニーズを確実に満たすように、アクセスコントロールを調整する必要があります。
diff --git a/content/ja/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/ja/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
deleted file mode 100644
index fe7a1626fb..0000000000
--- a/content/ja/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: Kubelet 認証/認可
----
-
-
-## 概要
-
-kubeletのHTTPSエンドポイントは、さまざまな感度のデータへのアクセスを提供するAPIを公開し、
-ノードとコンテナ内のさまざまなレベルの権限でタスクを実行できるようにします。
-
-このドキュメントでは、kubeletのHTTPSエンドポイントへのアクセスを認証および承認する方法について説明します。
-
-## Kubelet 認証
-
-デフォルトでは、他の構成済み認証方法によって拒否されないkubeletのHTTPSエンドポイントへのリクエストは
-匿名リクエストとして扱われ、ユーザー名は`system:anonymous`、
-グループは`system:unauthenticated`になります。
-
-匿名アクセスを無効にし、認証されていないリクエストに対して`401 Unauthorized`応答を送信するには：
-
-* `--anonymous-auth=false`フラグでkubeletを開始します。
-
-kubeletのHTTPSエンドポイントに対するX509クライアント証明書認証を有効にするには：
-
-* `--client-ca-file`フラグでkubeletを起動し、クライアント証明書を確認するためのCAバンドルを提供します。
-* `--kubelet-client-certificate`および`--kubelet-client-key`フラグを使用してapiserverを起動します。
-* 詳細については、[apiserver認証ドキュメント](/ja/docs/reference/access-authn-authz/authentication/#x509-client-certs)を参照してください。
-
-APIベアラートークン(サービスアカウントトークンを含む)を使用して、kubeletのHTTPSエンドポイントへの認証を行うには：
-
-* APIサーバーで`authentication.k8s.io/v1beta1`グループが有効になっていることを確認します。
-* `--authentication-token-webhook`および`--kubeconfig`フラグを使用してkubeletを開始します。
-* kubeletは、構成済みのAPIサーバーで `TokenReview` APIを呼び出して、ベアラートークンからユーザー情報を判別します。
-
-## Kubelet 承認
-
-認証に成功した要求(匿名要求を含む)はすべて許可されます。デフォルトの認可モードは、すべての要求を許可する`AlwaysAllow`です。
-
-kubelet APIへのアクセスを細分化するのは、次のような多くの理由が考えられます:
-
-* 匿名認証は有効になっていますが、匿名ユーザーがkubeletのAPIを呼び出す機能は制限する必要があります。
-* ベアラートークン認証は有効になっていますが、kubeletのAPIを呼び出す任意のAPIユーザー(サービスアカウントなど)の機能を制限する必要があります。
-* クライアント証明書の認証は有効になっていますが、構成されたCAによって署名されたクライアント証明書の一部のみがkubeletのAPIの使用を許可されている必要があります。
-
-kubeletのAPIへのアクセスを細分化するには、APIサーバーに承認を委任します:
-
-* APIサーバーで`authorization.k8s.io/v1beta1` APIグループが有効になっていることを確認します。
-* `--authorization-mode=Webhook`と`--kubeconfig`フラグでkubeletを開始します。
-* kubeletは、構成されたAPIサーバーで`SubjectAccessReview` APIを呼び出して、各リクエストが承認されているかどうかを判断します。
-
-kubeletは、apiserverと同じ[リクエスト属性](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)アプローチを使用してAPIリクエストを承認します。
-
-動詞は、受けとったリクエストのHTTP動詞から決定されます:
-
-HTTP動詞 | 要求 動詞
-----------|---------------
-POST | create
-GET, HEAD | get
-PUT | update
-PATCH | patch
-DELETE | delete
-
-リソースとサブリソースは、受けとったリクエストのパスから決定されます:
-
-Kubelet API | リソース | サブリソース
--------------|----------|------------
-/stats/\* | nodes | stats
-/metrics/\* | nodes | metrics
-/logs/\* | nodes | log
-/spec/\* | nodes | spec
-*all others* | nodes | proxy
-
-名前空間とAPIグループの属性は常に空の文字列であり、
-リソース名は常にkubeletの`Node` APIオブジェクトの名前です。
-
-このモードで実行する場合は、apiserverに渡される`--kubelet-client-certificate`フラグと`--kubelet-client-key`
-フラグで識別されるユーザーが次の属性に対して許可されていることを確認します:
-
-* verb=\*, resource=nodes, subresource=proxy
-* verb=\*, resource=nodes, subresource=stats
-* verb=\*, resource=nodes, subresource=log
-* verb=\*, resource=nodes, subresource=spec
-* verb=\*, resource=nodes, subresource=metrics
diff --git a/content/ja/docs/reference/glossary/cloud-controller-manager.md b/content/ja/docs/reference/glossary/cloud-controller-manager.md
deleted file mode 100755
index 6e9c9104da..0000000000
--- a/content/ja/docs/reference/glossary/cloud-controller-manager.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: クラウドコントローラーマネージャー
-id: cloud-controller-manager
-date: 2018-04-12
-full_link: /ja/docs/concepts/architecture/cloud-controller/
-short_description: >
- サードパーティクラウドプロバイダーにKubernetewを結合するコントロールプレーンコンポーネント
-aka:
-tags:
-- core-object
-- architecture
-- operation
----
- クラウド特有の制御ロジックを組み込むKubernetesの{{< glossary_tooltip text="control plane" term_id="control-plane" >}}コンポーネントです。クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIをリンクし、クラスタのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。
-
-
-
-Kubernetesと下のクラウドインフラストラクチャー間の相互運用ロジックを分離することで、cloud-controller-managerコンポーネントはクラウドプロバイダを主なKubernetesプロジェクトと比較し異なるペースで機能をリリース可能にします。
diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
deleted file mode 100644
index 62e610b277..0000000000
--- a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ /dev/null
@@ -1,181 +0,0 @@
----
-title: Windowsノードの追加
-min-kubernetes-server-version: 1.17
-content_type: tutorial
-weight: 30
----
-
-
-
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
-
-Kubernetesを使用してLinuxノードとWindowsノードを混在させて実行できるため、Linuxで実行するPodとWindowsで実行するPodを混在させることができます。このページでは、Windowsノードをクラスターに登録する方法を示します。
-
-
-
-
-## {{% heading "prerequisites" %}}
- {{< version-check >}}
-
-* WindowsコンテナをホストするWindowsノードを構成するには、[Windows Server 2019ライセンス](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)(またはそれ以上)を取得します。
-VXLAN/オーバーレイネットワークを使用している場合は、[KB4489899](https://support.microsoft.com/help/4489899)もインストールされている必要があります。
-
-* コントロールプレーンにアクセスできるLinuxベースのKubernetes kubeadmクラスター([kubeadmを使用したシングルコントロールプレーンクラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照)
-
-
-
-
-## {{% heading "objectives" %}}
-
-
-* Windowsノードをクラスターに登録する
-* LinuxとWindowsのPodとServiceが相互に通信できるようにネットワークを構成する
-
-
-
-
-
-
-## はじめに: クラスターへのWindowsノードの追加
-
-### ネットワーク構成
-
-LinuxベースのKubernetesコントロールプレーンノードを取得したら、ネットワーキングソリューションを選択できます。このガイドでは、簡単にするためにVXLANモードでのFlannelの使用について説明します。
-
-#### Flannel構成
-
-1. FlannelのためにKubernetesコントロールプレーンを準備する
-
- クラスター内のKubernetesコントロールプレーンでは、多少の準備が推奨されます。Flannelを使用する場合は、iptablesチェーンへのブリッジIPv4トラフィックを有効にすることをお勧めします。すべてのLinuxノードで次のコマンドを実行する必要があります:
-
- ```bash
- sudo sysctl net.bridge.bridge-nf-call-iptables=1
- ```
-
-1. Linux用のFlannelをダウンロードして構成する
-
- 最新のFlannelマニフェストをダウンロード:
-
- ```bash
- wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
- ```
-
- VNIを4096、ポートを4789に設定するために、flannelマニフェストの`net-conf.json`セクションを変更します。次のようになります:
-
- ```json
- net-conf.json: |
- {
- "Network": "10.244.0.0/16",
- "Backend": {
- "Type": "vxlan",
- "VNI" : 4096,
- "Port": 4789
- }
- }
- ```
-
- {{< note >}}Linux上のFlannelがWindows上のFlannelと相互運用するには、VNIを4096およびポート4789に設定する必要があります。これらのフィールドの説明については、[VXLANドキュメント](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)を参照してください。{{< /note >}}
-
- {{< note >}}L2Bridge/Host-gatewayモードを使用するには、代わりに`Type`の値を`"host-gw"`に変更し、`VNI`と`Port`を省略します。{{< /note >}}
-
-1. Flannelマニフェストを適用して検証する
-
- Flannelの構成を適用しましょう:
-
- ```bash
- kubectl apply -f kube-flannel.yml
- ```
-
- 数分後、Flannel Podネットワークがデプロイされていれば、すべてのPodが実行されていることがわかります。
-
- ```bash
- kubectl get pods -n kube-system
- ```
-
- 出力結果には、実行中のLinux flannel DaemonSetが含まれているはずです:
-
- ```
- NAMESPACE NAME READY STATUS RESTARTS AGE
- ...
- kube-system kube-flannel-ds-54954 1/1 Running 0 1m
- ```
-
-1. Windows Flannelとkube-proxy DaemonSetを追加する
-
- これで、Windows互換バージョンのFlannelおよびkube-proxyを追加できます。
- 互換性のあるバージョンのkube-proxyを確実に入手するには、イメージのタグを置換する必要があります。
- 次の例は、Kubernetes{{< param "fullversion" >}}の使用方法を示していますが、
- 独自のデプロイに合わせてバージョンを調整する必要があります。
-
- ```bash
- curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f -
- kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml
- ```
- {{< note >}}
- ホストゲートウェイを使用している場合は、代わりに https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml を使用してください。
- {{< /note >}}
-
- {{< note >}}
-Windowsノードでイーサネット(「Ethernet0 2」など)ではなく別のインターフェースを使用している場合は、次の行を変更する必要があります:
-
-```powershell
-wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
-```
-
-`flannel-host-gw.yml`または`flannel-overlay.yml`ファイルで、それに応じてインターフェースを指定します。
-
-```bash
-# 例
-curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
-```
- {{< /note >}}
-
-
-
-### Windowsワーカーノードの参加
-{{< note >}}
-`Containers`機能をインストールし、Dockerをインストールする必要があります。
-行うための指示としては、[Dockerエンジンのインストール - Windowsサーバー上のエンタープライズ](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)を利用できます。
-{{< /note >}}
-
-{{< note >}}
-Windowsセクションのすべてのコードスニペットは、
-Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実行されます。
-{{< /note >}}
-
-1. wins、kubelet、kubeadmをインストールします。
-
- ```PowerShell
- curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
- .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
- ```
-
-1. `kubeadm`を実行してノードに参加します
-
- コントロールプレーンホストで`kubeadm init`を実行したときに提供されたコマンドを使用します。
- このコマンドがなくなった場合、またはトークンの有効期限が切れている場合は、`kubeadm token create --print-join-command`
- (コントロールプレーンホスト上で)を実行して新しいトークンを生成します。
-
-
-#### インストールの確認
-次のコマンドを実行して、クラスター内のWindowsノードを表示できるようになります:
-
-```bash
-kubectl get nodes -o wide
-```
-
-新しいノードが`NotReady`状態の場合は、flannelイメージがまだダウンロード中の可能性があります。
-`kube-system`名前空間のflannel Podを確認することで、以前と同様に進行状況を確認できます:
-
-```shell
-kubectl -n kube-system get pods -l app=flannel
-```
-
-flannel Podが実行されると、ノードは`Ready`状態になり、ワークロードを処理できるようになります。
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-- [Windows kubeadmノードのアップグレード](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
deleted file mode 100644
index 3c367aaa22..0000000000
--- a/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Windowsノードのアップグレード
-min-kubernetes-server-version: 1.17
-content_type: task
-weight: 40
----
-
-
-
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
-
-このページでは、[kubeadmで作られた](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)Windowsノードをアップグレードする方法について説明します。
-
-
-
-
-## {{% heading "prerequisites" %}}
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* [残りのkubeadmクラスターをアップグレードするプロセス](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)を理解します。
-Windowsノードをアップグレードする前にコントロールプレーンノードをアップグレードしたいと思うかもしれません。
-
-
-
-
-
-
-## ワーカーノードをアップグレード
-
-### kubeadmをアップグレード
-
-1. Windowsノードから、kubeadmをアップグレードします。:
-
- ```powershell
- # {{< param "fullversion" >}}を目的のバージョンに置き換えます
- curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
- ```
-
-### ノードをドレインする
-
-1. Kubernetes APIにアクセスできるマシンから、
- ノードをスケジュール不可としてマークして、ワークロードを削除することでノードのメンテナンスを準備します:
-
- ```shell
- #