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

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

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

今回は [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)


## 注意事項
* 基本的に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内のリソースへのアクセスを許可するためにのみ使用できます。ポッドへの読み取りアクセスを許可するために使用できる「デフォルトの」名前空間の役割の例を次に示します。

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

```yml
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"をバインドしています。

```yml
# 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を読み取ることができます。

```yml
# 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を読み取ることを許可します。

```yml
# 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で表すには、スラッシュを使用してリソースとサブリソースを区切ります。サブジェクトがポッドとポッドログの両方を読み取ることができるようにするには、次のように記述します。

```yml
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"するようにサブジェクトを制限するには、次のように記述します。

```yml
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の例：

```yml
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に追加できます。

```yml
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"ロールはリソースの読み取り専用アクションを実行します。


```yml
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」の読み込みを許可する：

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

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

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

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

```yml
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`にバインドされている必要があります）を読み込めるようにします。

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

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

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

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

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

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

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

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

[サービスアカウント](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)は、`system：serviceaccount：`接頭辞付きのユーザー名を持ち、`system：serviceaccounts：`接頭辞付きのグループに属します。

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

"alice@example.com"という名前のユーザーの場合：

```yml
subjects:
- kind: User
  name: "alice@example.com"
  apiGroup: rbac.authorization.k8s.io
```

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

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

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

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

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

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

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

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

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

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

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

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

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

```yml
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を作成します。

```yml
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.io`APIグループ（Kubernetes 1.12以降）の`roles`または`clusterroles`リソースで`escalate`動詞を実行する明示的な許可が与えられます。

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

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

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

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

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

```yml
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"サービスアカウントに付与します。

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

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


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

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

```shell
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が含まれていることを意味します。

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

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

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

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

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

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

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

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

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

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

```shell
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
```