訳しながら理解していくKubernetes_Using RBAC Authorization編

はじめに

Kubernetesのドキュメントって英語だし、英検3級レベルで英語力のない私にはつらい・・・
そして、一回(google翻訳を使って)訳しながら読んでまた忘れてまた(google翻訳を使って)訳すを繰り返すのをやめたい。
調べるときは全文を見ずに、必要な部分だけを見てたりするので、公式ドキュメントを訳しながら全体を理解していこうと思う。

英語読むのめんどくせーーーとなっている人の助けになればと思い公開した

今回は Using RBAC Authorization

注意事項

• 基本的にGoogle翻訳のまんまです。
• 一応、意味が分かるようには訳してるつもりですが、ちょいちょい意味分からない部分もあります。
  誤訳がある可能性があるので、最後はちゃんと公式ドキュメントを読みましょう
• 私の知りたい部分からやるので、訳す部分はバラバラになります。
• 公式ドキュメントに記載されていない部分(自分で調べた部分とか)はitalicで記載しています。
• V1.12でのドキュメントを記載

Using RBAC Authorization

役割ベースのアクセス制御（RBAC）は、企業内の個々のユーザーの役割に基づいて、コンピュータまたはネットワークリソースへのアクセスを制御する方法です。

RBACはrbac.authorization.k8s.io APIグループを使用して承認決定を行い、管理者がKubernetes APIを通じてポリシーを動的に設定できるようにします。

1.8以降、RBACモードは安定しており、rbac.authorization.k8s.io/v1 APIによってサポートされています。 RBACを有効にするには、--authorization-mode=RBACでapiserverを起動します。

API Overview

RBAC APIは、このセクションで説明する4つのトップレベルタイプを宣言しています。
ユーザーは、他のAPIリソースと同じように（kubectl、API呼び出しなどを介して）これらのリソースと対話できます。例えば、kubectl create -f （resource）.ymlは、これらの例のどれでも使用できますが、それに従うことを望む読者は最初にブートストラッピングに関するセクションを確認する必要があります。

Role and ClusterRole

パーミッションは純粋に相加的(additive)です（「拒否」ルールはありません）。roleは、Roleを持つnamespace内で定義することも、ClusterRoleを使用してクラスタ全体に定義することもできます。

Roleは、単一のnamespace内のリソースへのアクセスを許可するためにのみ使用できます。ポッドへの読み取りアクセスを許可するために使用できる「デフォルトの」名前空間の役割の例を次に示します。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRoleを使用して、Roleと同じアクセス権を付与できますが、クラスタスコープであるため、次のものへのアクセス権の付与にも使用できます。

• クラスタスコープのリソース（ノードなど）
• 非リソースエンドポイント（「/ healthz」など）
• namespacedなリソース(ポッドなど)すべての名前空間を横断する（kubectl get pod --all-namespacesなど）

次のClusterRoleを使用して、特定の名前空間またはすべての名前空間のシークレットへの読み取りアクセスを許可することができます（バインド方法によって異なります）。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding and ClusterRoleBinding

ロールバインディングは、ロールに定義された権限をuserまたはusersのセットに付与します。サブジェクト（ユーザー、グループ、またはサービスアカウント）のリストと、付与されるロールへの参照を保持します。パーミッションは、RoleBindingを持つネームスペース内、またはClusterRoleBindingを持つクラスタワイド内で付与できます。

RoleBindingは、同じ名前空間内のロールを参照することがあります。次のRoleBindingは、「デフォルト」ネームスペース内のユーザー「jane」に「ポッドリーダー」ロールを付与します。これにより、 "jane"は "default"名前空間のポッドを読み取ることができます。

roleRefは実際にバインディングを作成する方法です。kindはRoleまたはClusterRoleのいずれかになり、nameは必要な特定のRoleまたはClusterRoleの名前を参照します。以下の例では、このRoleBindingはroleRefを使用して、前述のpod-readerという名前のロールにユーザー "jane"をバインドしています。

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

RoleBindingは、ClusterRoleを参照して、RoleBindingの名前空間内のClusterRoleに定義されている名前空間のリソースにアクセス権を付与することもできます。これにより、管理者はクラスタ全体の共通ロールを定義し、複数のネームスペース内でそれらを再利用することができます。

たとえば、次のRoleBindingがClusterRoleを参照していても、 "dave"（件名、大文字と小文字を区別）は、 "開発"名前空間（RoleBindingの名前空間）でのみsecretsを読み取ることができます。

# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

最後に、ClusterRoleBindingを使用して、クラスタレベルとすべてのネームスペースでパーミッションを付与することができます。次のClusterRoleBindingは、グループ "manager"内のすべてのユーザーが任意の名前空間のsecretsを読み取ることを許可します。

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Referring to Resources

ほとんどのリソースは、関連するAPIエンドポイントのURLに表示されるように、「pods」などの名前の文字列表現で表されます。ただし、一部のKubernetes APIには、ポッドのログなどの「subresource」が含まれています。ポッドログエンドポイントのURLは次のとおりです。

GET /api/v1/namespaces/{namespace}/pods/{name}/log

この場合、「pods」は名前空間のリソース、「log」はポッドのサブリソースです。これをRBAC roleで表すには、スラッシュを使用してリソースとサブリソースを区切ります。サブジェクトがポッドとポッドログの両方を読み取ることができるようにするには、次のように記述します。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

リソースは、resourceNamesリストを介して特定のリクエストの名前で参照することもできます。指定すると、「get」、「delete」、「update」、および「patch」動詞を使用する要求をリソースの個々のインスタンスに限定することができます。単一のconfigmapだけを "get"し "update"するようにサブジェクトを制限するには、次のように記述します。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

特に、resourceNamesが設定されている場合、verbはlist、watch、create、またはdeletecollectionであってはなりません。リソース名はcreate、list、watch、およびdeletecollection API要求のURLには存在しないため、ルールのresourceNames部分が要求と一致しないため、これらのverbはresourceNamesを設定したルールでは許可されません。

Aggregated ClusterRoles

1.9では、aggregationRuleを使用して他のClusterRolesを組み合わせることによってClusterRolesを作成できます。

集約されたClusterRoleのパーミッションはコントローラで管理され、提供されたラベルセレクタに一致するClusterRoleのルールを結合することによって埋められます。集約されたClusterRoleの例：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # Rules are automatically filled in by the controller manager.

ラベルセレクタに一致するClusterRoleを作成すると、aggregationされたClusterRoleにルールが追加されます。この場合、rbac.example.com/aggregate-to-monitoring：trueというラベルを持つ別のClusterRoleを作成して、ルールを「monitoring」ClusterRoleに追加できます。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# These rules will be added to the "monitoring" role.
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

既定のuser-facingのrole（後述）は、ClusterRole aggregationを使用します。これにより、管理者は、CustomResourceDefinitionsまたはAggregated APIサーバーによって提供されるカスタムリソースのルールをデフォルトのロールに含めることができます。

たとえば、次のClusterRolesでは、デフォルトのロール "admin"と "edit"がカスタムリソース "CronTabs"を管理し、 "view"ロールはリソースの読み取り専用アクションを実行します。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # Add these permissions to the "admin" and "edit" default roles.
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # Add these permissions to the "view" default role.
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

Role Examples

以下の例では、rulesセクションのみが示されています。

コアAPIグループ内のリソース「pods」の読み込みを許可する：

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

「extensions」APIグループと「apps」APIグループの両方に「deployments」のreading/writingを許可する：

rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

「pod」のreadingと「jobs」のreading/writingを許可する：

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

"my-config"という名前のConfigMap（単一の名前空間内の単一のConfigMapに制限するためにRoleBindingにバインドされている必要があります）を読み込めるようにします。

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

コアグループ内のリソース「node」の読み取りを許可します（Nodeがクラスタスコープであるため、これはClusterRoleBindingを有効にするためにはClusterRoleバインド内にある必要があります）。

rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

非リソースエンドポイント「/healthz」とすべてのサブパス（ClusterRoleBindingにバインドされたClusterRole内に有効である必要があります）に「GET」および「POST」リクエストを許可します。

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
  verbs: ["get", "post"]

Referring to Subjects

RoleBindingまたはClusterRoleBindingは、ロールをsubjectsにバインドします。Subjectsは、グループ、ユーザーまたはサービスアカウントにすることができます。

Usersは文字列で表されます。これらは、 "alice"のようなプレーンなユーザー名、 "[e-mail]"のような電子メールスタイルの名前、または文字列として表された数値IDです。Kubernetesの管理者は、認証モジュールを設定して、希望する形式のユーザー名を生成する必要があります。RBAC認証システムには、特定の形式は必要ありません。しかし、プレフィックス system：はKubernetesシステム用に予約されているため、管理者はユーザー名にこの接頭辞が偶然含まれないようにする必要があります。

現在、Kubernetesのグループ情報はAuthenticatorモジュールによって提供されています。ユーザーのようなグループは文字列として表され、その文字列にはフォーマット要件はありません。プレフィックスsystem：は予約されています。

サービスアカウントは、system：serviceaccount：接頭辞付きのユーザー名を持ち、system：serviceaccounts：接頭辞付きのグループに属します。

Role Binding Examples

次の例では、RoleBindingのsubjectsセクションのみを示しています。

"[e-mail]"という名前のユーザーの場合：

subjects:
- kind: User
  name: "[e-mail]"
  apiGroup: rbac.authorization.k8s.io

"frontend-admins"という名前のグループの場合：

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

kube-systemネームスペースのデフォルトサービスアカウントの場合：

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

"qa"名前空間のすべてのサービスアカウントについて：

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

どこのサービスアカウントでも：

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

すべての認証済みユーザー（バージョン1.5以降）：

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

認証されていないすべてのユーザー（バージョン1.5以降）：

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

すべてのユーザー（バージョン1.5以降）

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io

Default Roles and Role Bindings

APIサーバーは、デフォルトのClusterRoleおよびClusterRoleBindingオブジェクトのセットを作成します。これらの多くはsystem：prefixedであり、リソースがインフラストラクチャによって「所有」されていることを示します。これらのリソースを変更すると、機能しないクラスタが発生する可能性があります。 1つの例はsystem：node ClusterRole。このロールはkubeletsの権限を定義します。役割が変更された場合、kubeletが機能しなくなる可能性があります。

すべての既定のクラスタロールとロールバインドには、kubernetes.io/bootstrapping=rbac-defaultsというラベルが付けられています。

Auto-reconciliation

各起動時に、APIサーバーは既定のクラスタロールを不足しているアクセス許可で更新し、既定のクラスターロールバインディングを不足しているサブジェクトと共に更新します。これにより、クラスタは偶発的な変更を修復し、新しいリリースで権限とsubjectsが変更されるたびに役割とロールバインディングを最新の状態に保つことができます。

この調整をオプトアウトするには、デフォルトのクラスタロールまたはロールバインドのrbac.authorization.kubernetes.io/autoupdateアノテーションをfalseに設定します。既定のアクセス許可とサブジェクトがないと、機能しないクラスターが発生する可能性があることに注意してください。

Kubernetesバージョン1.6以降では、RBAC承認者がアクティブなときに自動調整(Auto-reconciliation)が有効になります。

Discovery Roles

デフォルトのロールバインディングは、認証されていないユーザーと認証されたユーザーに、（CustomResourceDefinitionsを含む）公開アクセスが安全であるとみなされるAPI情報を読み取ることを許可します。匿名の非認証アクセスを無効にするには、APIサーバー構成に対して--anonymous-auth=falseを追加します。

kubectlを実行してこれらのロールの設定を表示するには：

kubectl get clusterroles system:discovery -o yaml

注：ロールの編集は推奨されません。これは、自動調整(auto-reconciliation)によるAPIサーバーの再起動時に変更が上書きされるためです（上記参照）。

Default ClusterRole	Default ClusterRoleBinding	Description
system:basic-user	system:authenticated and system:unauthenticated groups	ユーザーが自分自身に関する基本情報に読み取り専用でアクセスできるようにします。
system:discovery	system:authenticated and system:unauthenticated groups	APIレベルを検出してネゴシエートするために必要なAPIディスカバリエンドポイントへの読み取り専用アクセスを許可します。

User-facing Roles

既定の役割の一部は、system:接頭辞ではありません。これらは、ユーザーが直面する役割を意図しています。スーパーユーザー役割（cluster-admin）、ClusterRoleBindings（cluster-status）を使用してクラスタ全体に付与される役割、RoleBindings（admin、edit、view）を使用して特定の名前空間内で付与される役割が含まれます。

1.9から、ユーザに面する役割はClusterRole集約を使用して、管理者がこれらの役割にカスタムリソースの規則を含めることを可能にします。 "admin"、 "edit"、または "view"ロールにルールを追加するには、次の1つ以上のラベルを持つClusterRoleを作成します。

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

Default ClusterRole	Default ClusterRoleBinding	Description
cluster-admin	system:masters group	スーパユーザアクセスが任意のリソースに対して任意のアクションを実行できるようにします。 ClusterRoleBindingで使用すると、クラスタ内のすべてのリソースとすべてのネームスペースを完全に制御できます。RoleBindingで使用すると、名前空間自体を含むロールバインディングの名前空間内のすべてのリソースを完全に制御できます。
admin	None	RoleBindingを使用して名前空間内で付与されることを意図した管理アクセスを許可します。RoleBindingで使用すると、ネームスペース内のロールとロールバインディングを作成する機能を含む、ネームスペース内のほとんどのリソースへの読み取り/書き込みアクセスが可能になります。リソースクォータまたはネームスペース自体への書き込みアクセスは許可されません。
edit	None	ネームスペース内のほとんどのオブジェクトに対する読み取り/書き込みアクセスを許可します。ロールまたはロールバインドを表示または変更することはできません。
view	None	名前空間内のほとんどのオブジェクトを読み取り専用でアクセスできるようにします。ロールまたはロールバインディングを表示することはできません。彼らはエスカレートしているので、secretsを見ることはできません。

Core Component Roles

Default ClusterRole	Default ClusterRoleBinding	Description
system:kube-scheduler	system:kube-scheduler user	kube-schedulerコンポーネントが必要とするリソースへのアクセスを許可します。
system:volume-scheduler	system:kube-scheduler user	kube-schedulerコンポーネントが必要とするボリュームリソースへのアクセスを許可します。
system:kube-controller-manager	system:kube-controller-manager user	kube-controller-managerコンポーネントが必要とするリソースへのアクセスを許可します。個々の制御ループに必要な権限は、コントローラの役割に含まれています。
system:node	None in 1.8+	すべてのシークレットへの読み取りアクセス、すべてのポッドステータスオブジェクトへの書き込みアクセスを含む、kubeletコンポーネントが必要とするリソースへのアクセスを許可します。1.7以降、このロールの代わりにNode authorizerとNodeRestriction admissionプラグインを使用することをお勧めします。また、kubeletsへのAPIアクセスは、実行予定のポッドに基づいて許可されます。1.7以前では、この役割は自動的に system：nodesグループにバインドされていました。1.7では、 Node認可モードが有効でない場合、この役割は自動的にsystem：nodesグループに束縛されました。 1.8+では、バインディングは自動的に作成されません
system:node-proxier	system:kube-proxy user	kube-proxyコンポーネントが必要とするリソースへのアクセスを許可します。

Other Component Roles

Default ClusterRole	Default ClusterRoleBinding	Description
system:auth-delegator	None	委任された認証と認可の確認を許可します。これは、統一された認証と認可のためにアドオンAPIサーバーで一般的に使用されます。
system:heapster	None	ヒープスターコンポーネントの役割。
system:kube-aggregator	None	kube-aggregatorコンポーネントのRole。
system:kube-dns	kube-system名前空間のkube-dnsサービスアカウント	kube-dnsコンポーネントのRole。
system:kubelet-api-admin	None	kubelet APIへの完全なアクセスを許可します。
system:node-bootstrapper	None	Kubelet TLSのブートストラップを実行するために必要なリソースへのアクセスを許可します。
system:node-problem-detector	None	ノード問題検出器(node-prooblem-detector)コンポーネントの役割。
system:persistent-volume-provisioner	None	ほとんどの動的ボリューム・プロビジョナーが必要とするリソースへのアクセスを可能にします。

Controller Roles

Kubernetesコントローラマネージャは、コア制御ループを実行します。--use-service-account-credentialsを指定して呼び出すと、別のサービスアカウントを使用して各制御ループが開始されます。制御ループごとに対応する役割が存在し、接頭辞はsystem：controller：です。コントローラマネージャが--use-service-account-credentialsで起動されていない場合は、すべての関連ロールを付与する必要がある独自の認証情報を使用してすべての制御ループを実行します。これらの役割は次のとおりです。

• system:controller:attachdetach-controller
• system:controller:certificate-controller
• system:controller:cronjob-controller
• system:controller:daemon-set-controller
• system:controller:deployment-controller
• system:controller:disruption-controller
• system:controller:endpoint-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:route-controller
• system:controller:service-account-controller
• system:controller:service-controller
• system:controller:statefulset-controller
• system:controller:ttl-controller

Privilege Escalation Prevention and Bootstrapping

RBAC APIを使用すると、ユーザーは役割または役割のバインディングを編集して特権を昇格できなくなります。これはAPIレベルで適用されるため、RBAC認可者が使用されていなくても適用されます。

次のうち少なくとも1つが真である場合、ユーザーはロールの作成/更新のみ可能です。

1. それらはすでに変更されているオブジェクトと同じスコープで、ロールに含まれているすべての権限を持っています（ClusterRoleのクラスタ全体、同じ名前空間またはクラスタ全体のRole）
2. rbac.authorization.k8s.ioAPIグループ（Kubernetes 1.12以降）のrolesまたはclusterrolesリソースでescalate動詞を実行する明示的な許可が与えられます。

たとえば、「user-1」にsecretsをクラスタ全体にリストする機能がない場合、そのパーミッションを含むClusterRoleを作成することはできません。ユーザーがロールを作成/更新できるようにするには：

1. RoleやClusterRoleオブジェクトを必要に応じて作成/更新できるようにする役割を与えます。
2. 作成/更新ロールに特定の権限を含める権限を付与します。 暗黙のうちに、それらのパーミッションを与えることによって（彼ら自身が許可されていないパーミッションを持つRoleまたはClusterRoleを作成または変更しようとすると、APIリクエストは禁止されます） 　　　　　　　　rbac.authorization.k8s.ioAPIグループ（Kubernetes 1.12以降）のRoleまたはClusterRoleリソースのescalate動詞を実行する権限を与えて、RoleまたはClusterRole`の任意のパーミッションを明示的に指定することができます。

ユーザーは、参照されたロール（ロールバインディングと同じスコープ）でのみ、または参照されたロールでbind動詞を実行するための明示的なアクセス許可が与えられている場合、ロールバインディングを作成または更新できます。たとえば、「user-1」にsecretをクラスタ全体にリストする機能がない場合、そのアクセス権を付与するロールへのClusterRoleBindingを作成することはできません。ユーザーがロールバインディングを作成/更新できるようにするには：

1. RoleBindingまたはClusterRoleBindingオブジェクトを必要に応じて作成または更新できるロールをロールに付与します。
2. 特定のロールをバインドするために必要な権限を付与します。 それらにロールに含まれている権限を与えることによって暗黙的に行われます。 特定の役割（またはクラスターロール）でbind動詞を実行するための許可を与えて、明示的に許可します。

たとえば、このクラスタロールとロールバインディングは、 "user-1-namespace"名前空間のadmin、edit、およびviewの役割を他のユーザーに許可することができます。

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

最初の役割と役割のバインディングをブートストラップするとき、最初のユーザーはまだ持っていない権限を付与する必要があります。初期ロールとロールバインディングをブートストラップするには：

• system：mastersグループの資格情報を使用します。これは、デフォルトのバインディングによってcluster-adminスーパーユーザー役割にバインドされています。
• APIサーバーが安全でないポート（--insecure-port）が有効な状態で実行されている場合は、そのポートを介してAPI呼び出しを行うこともできます。

Command-line Utilities

ネームスペース内またはクラスタ全体にロールを付与するための2つのkubectlコマンドが存在します。

kubectl create rolebinding

特定の名前空間内にRoleまたはClusterRoleを付与します。例：

• ネームスペース "acme"内の "bob"という名前のユーザーにadmin ClusterRoleを与えます。
  kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
• 名前空間 "acme"の "myapp"というサービスアカウントにview ClusterRoleを与えます。
  kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

kubectl create clusterrolebinding

すべての名前空間を含むクラスタ全体にClusterRoleを与えます。例：

• クラスタ全体の「root」という名前のユーザーに、cluster-admin ClusterRoleを付与します。
  kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
• クラスタ全体の "kubelet"という名前のユーザーにシステム:ノード ClusterRoleを付与します。
  kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet
• クラスタ全体の名前空間 "acme"内の "myapp"という名前のサービスアカウントにClusterRole viewを付与します。
  kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

詳細な使用方法については、CLIのヘルプを参照してください。

Service Account Permissions

デフォルトのRBACポリシーは、コントロールプレーンのコンポーネント、ノード、コントローラにスコープ付きのアクセス許可を与えますが、（すべての認証済みユーザーに与えられた検出権限を超えて）kube-system名前空間外のサービスアカウントに対してはアクセス許可を与えません。

これにより、必要に応じて特定の役割を特定のサービスアカウントに付与することができます。Fine-grainedロールバインディングはセキュリティを強化しますが、管理に多くの労力が必要です。より広範な権限付与は、サービスアカウントへの不要な（そして潜在的に段階的に）APIアクセスを与えることができますが、管理が容易です。

最も安全なものから最も安全でないものへの順に、アプローチは次のとおりです。

1. アプリケーション固有のサービスアカウントに役割を付与する（ベストプラクティス） これには、アプリケーションがそのポッド仕様でserviceAccountNameを指定し、API、アプリケーションマニフェスト、kubectl create serviceaccountなどを介してサービスアカウントを作成する必要があります。

たとえば、 "my-namespace"内の読み取り専用アクセス許可を "my-sa"サービスアカウントに付与します。

kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace

1. ネームスペース内の "デフォルトの"サービスアカウントに役割を与える アプリケーションでserviceAccountNameが指定されていない場合は、「デフォルト」のサービスアカウントが使用されます。

注： "default"サービスアカウントに与えられた権限は、serviceAccountNameを指定していない名前空間内のポッドで使用できます。

たとえば、 "my-namespace"内の読み取り専用アクセス許可を "default"サービスアカウントに付与します。

kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:default \
  --namespace=my-namespace

多くのアドオンは現在、kube-system名前空間の「デフォルト」サービスアカウントとして実行されています。これらのアドオンをスーパーユーザーアクセスで実行できるようにするには、kube-systemネームスペースの "default"サービスアカウントに対してcluster-admin権限を与えます。

注：これを有効にすると、kube-system名前空間には、スーパーユーザーがAPIにアクセスできるsecretsが含まれていることを意味します。

kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

1. ネームスペース内のすべてのサービスアカウントに役割を付与する

ネームスペース内のすべてのアプリケーションが役割を持つようにするには、それらが使用するサービスアカウントに関係なく、そのネームスペースのサービスアカウントグループにロールを付与できます。
たとえば、「my-namespace」内の読み取り専用アクセス許可を、その名前空間内のすべてのサービスアカウントに付与します。

kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

1. クラスタ全体にわたるすべてのサービスアカウントに限定された役割を与える（推奨しない）

名前空間ごとのアクセス許可を管理しない場合は、すべてのサービスアカウントにクラスタ全体の役割を付与できます。
たとえば、クラスタ内のすべてのサービスアカウントに対して、すべてのネームスペースにわたって読み取り専用アクセス許可を付与します。

kubectl create clusterrolebinding serviceaccounts-view \
 --clusterrole=view \
 --group=system:serviceaccounts

1. クラスタ全体にわたるすべてのサービスアカウントへのスーパーユーザーアクセスを許可する（強く推奨する）

パーミッションの分割について気にしない場合は、すべてのサービスアカウントにスーパーユーザーアクセスを許可できます。

警告： これにより、読み取りアクセス権を持つすべてのユーザー スーパーユーザーにアクセスするための秘密またはポッドを作成する機能 資格情報。

kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

Upgrading from 1.5

Kubernetes 1.6より前のバージョンでは、多くのデプロイメントで、すべてのサービスアカウントへの完全なAPIアクセスを許可するなど、非常に容認しやすいABACポリシーが使用されていました。

デフォルトのRBACポリシーは、コントロールプレーンのコンポーネント、ノード、コントローラにスコープ付きのアクセス許可を与えますが、（すべての認証済みユーザーに与えられた検出権限を超えて）kube-system名前空間外のサービスアカウントに対してはアクセス許可を与えません。

はるかに安全ですが、これは自動的にAPI権限を受け取ることを期待している既存のワークロードに混乱を招く可能性があります。この移行を管理するには、次の2つの方法があります。

Parallel Authorizers

RBACとABACの両方の承認者を実行し、従来のABACポリシーを含むポリシーファイルを指定します。

--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json

RBAC承認者は、最初に要求を承認しようとします。 API要求を拒否した場合は、ABAC承認者が実行されます。つまり、RBACポリシーまたはABACポリシーのいずれかで許可されている要求はすべて許可されます。

apiserverがRBACコンポーネント（--vmodule = rbac * = 5または - v = 5）に対して5以上のログレベルで実行されると、apiserverログ（RBAC DENY :)の前にRBAC拒否が表示されます。 この情報を使用して、どのユーザー、グループ、またはサービスアカウントに付与する必要がある役割を判断できます。サービスアカウントにロールを付与し、サーバーログにRBAC拒否メッセージがない状態でワークロードが実行されている場合は、ABAC承認者を削除できます。

Permissive RBAC Permissions

RBACロールバインディングを使用して許容ポリシーを複製できます。

警告： 次のポリシーでは、すべてのサービスアカウントをクラスタ管理者として機能させることができます。コンテナ内で実行されているアプリケーションは、自動的にサービスアカウントの資格情報を受け取り、secretsの表示や権限の変更など、APIに対して何らかのアクションを実行できます。これは推奨されるポリシーではありません。

kubectl create clusterrolebinding permissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts