+
+
+| デフォルトの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サーバーで使用されます。This is commonly used by add-on API servers for unified authentication and authorization. |
+
+
+| system:heapster |
+None |
+HeapsterコンポーネントのRole(非推奨)。 |
+
+
+| system:kube-aggregator |
+None |
+kube-aggregatorコンポーネントのRole。 |
+
+
+| system:kube-dns |
+kube-dns service account in the kube-system namespace |
+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を付与する(ベストプラクティス)
+ これには、アプリケーションがポッドの仕様、そして作成するサービスアカウント(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
+ ```
+
+ 多くの[アドオン](/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の使用に移行後、クラスターが情報セキュリティのニーズを確実に満たすように、アクセスコントロールを調整する必要があります。