第8章 RBAC の使用によるパーミッションの定義および適用
8.1. RBAC の概要
ロールベースアクセス制御 (RBAC) オブジェクトは、ユーザーがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。
これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、OpenShift Container Platform プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。
開発者はローカルロールとバインディングを使用して、プロジェクトにアクセスできるユーザーを制御できます。認可は認証とは異なる手順であることに注意してください。認証はアクションを実行するユーザーのアイデンティティーの判別により密接に関連しています。
認可は以下を使用して管理されます。
| 認可オブジェクト | 説明 |
|---|---|
| ルール |
オブジェクトのセットで許可されている動詞のセット(例: ユーザーまたはサービスアカウントが Pod の |
| ロール | ルールのコレクション。ユーザーおよびグループを複数のロールに関連付けたり、バインドしたりできます。 |
| バインディング | ロールを使用したユーザー/グループ間の関連付けです。 |
2 つのレベルの RBAC ロールおよびバインディングが認可を制御します。
| RBAC レベル | 説明 |
|---|---|
| クラスター RBAC | すべてのプロジェクトで適用可能なロールおよびバインディングです。クラスターロール はクラスター全体で存在し、クラスターロールのバインディング はクラスターロールのみを参照できます。 |
| ローカル RBAC | 所定のプロジェクトにスコープ設定されているロールおよびバインディングです。ローカルロール は単一プロジェクトのみに存在し、ローカルロールのバインディングはクラスターロールおよびローカルロールの 両方 を参照できます。 |
クラスターのロールバインディングは、クラスターレベルで存在するバインディングですが、ロールバインディングはプロジェクトレベルで存在します。ロールバインディングは、プロジェクトレベルで存在します。クラスターの view (表示) ロールは、ユーザーがプロジェクトを表示できるようローカルのロールバインディングを使用してユーザーにバインドする必要があります。ローカルロールは、クラスターのロールが特定の状況に必要なパーミッションのセットを提供しない場合にのみ作成する必要があります。
この 2 つのレベルからなる階層により、ローカルロールで個別プロジェクト内のカスタマイズが可能になる一方で、クラスターロールによる複数プロジェクト間での再利用が可能になります。
評価時に、クラスターロールのバインディングおよびローカルロールのバインディングが使用されます。以下に例を示します。
- クラスター全体の "allow" ルールがチェックされます。
- ローカルにバインドされた "allow" ルールがチェックされます。
- デフォルトで拒否します。
8.1.1. デフォルトのクラスターロール
OpenShift Container Platform には、クラスター全体で、またはローカルにユーザーおよびグループにバインドできるデフォルトのクラスターロールのセットが含まれます。
デフォルトのクラスターロールを手動で変更することは推奨されません。このようなシステムロールへの変更は、クラスターが正常に機能しなくなることがあります。
| デフォルトのクラスターロール | 説明 |
|---|---|
|
|
プロジェクトマネージャー。ローカルバインディングで使用される場合、 |
|
| プロジェクトおよびユーザーに関する基本的な情報を取得できるユーザーです。 |
|
| すべてのプロジェクトですべてのアクションを実行できるスーパーユーザーです。ローカルバインディングでユーザーにバインドされる場合は、クォータに対する完全な制御およびプロジェクト内のすべてのリソースに対するすべてのアクションを実行できます。 |
|
| 基本的なクラスターのステータス情報を取得できるユーザーです。 |
|
| ほとんどのオブジェクトを取得または表示できるが、変更できないユーザー。 |
|
| プロジェクトのほとんどのプロジェクトを変更できるが、ロールまたはバインディングを表示したり、変更したりする機能を持たないユーザーです。 |
|
| 独自のプロジェクトを作成できるユーザーです。 |
|
| 変更できないものの、プロジェクトでほとんどのオブジェクトを確認できるユーザーです。それらはロールまたはバインディングを表示したり、変更したりできません。 |
ローカルバインディングとクラスターバインディングに関する違いに留意してください。ローカルのロールバインディングを使用して cluster-admin ロールをユーザーにバインドする場合、このユーザーがクラスター管理者の特権を持っているように表示されます。しかし、実際はそうではありません。一方、cluster-admin をプロジェクトのユーザーにバインドすると、そのプロジェクトにのみ有効なスーパー管理者の権限がそのユーザーに付与されます。そのユーザーはクラスターロール admin のパーミッションを有するほか、レート制限を編集する機能などの、そのプロジェクトに関するいくつかの追加パーミッションを持ちます。このバインディングは、クラスター管理者にバインドされるクラスターのロールバインディングをリスト表示しない Web コンソール UI を使うと分かりにくくなります。ただし、これは、cluster-admin をローカルにバインドするために使用するローカルのロールバインディングをリスト表示します。
クラスターロール、クラスターロールのバインディング、ローカルロールのバインディング、ユーザー、グループおよびサービスアカウントの関係は以下に説明されています。
get pods/exec、get pods/*、および get * ルールは、ロールに適用されると実行権限を付与します。最小権限の原則を適用し、ユーザーおよびエージェントに必要な最小限の RBAC 権限のみを割り当てます。詳細は、RBAC ルールによる実行権限の許可 を参照してください。
8.1.2. 認可の評価
OpenShift Container Platform は以下を使用して認可を評価します。
- アイデンティティー
- ユーザーが属するユーザー名とグループのリスト。
- アクション
実行する動作。ほとんどの場合、これは以下で構成されます。
- プロジェクト: アクセスするプロジェクト。プロジェクトは追加のアノテーションを含む Kubernetes namespace であり、これにより、ユーザーのコミュニティーは、他のコミュニティーと分離された状態で独自のコンテンツを編成し、管理できます。
-
動詞:
get、list、create、update、delete、deletecollection、またはwatchなどのアクション自体。 - リソース名: アクセスする API エンドポイント。
- バインディング
- バインディングの詳細なリスト、ロールを持つユーザーまたはグループ間の関連付け。
OpenShift Container Platform は以下の手順を使用して認可を評価します。
- アイデンティティーおよびプロジェクトでスコープ設定されたアクションは、ユーザーおよびそれらのグループに適用されるすべてのバインディングを検索します。
- バインディングは、適用されるすべてのロールを見つけるために使用されます。
- ロールは、適用されるすべてのルールを見つけるために使用されます。
- 一致を見つけるために、アクションが各ルールに対してチェックされます。
- 一致するルールが見つからない場合、アクションはデフォルトで拒否されます。
ユーザーおよびグループは一度に複数のロールに関連付けたり、バインドしたりできることに留意してください。
プロジェクト管理者は CLI を使用してローカルロールとローカルバインディングを表示できます。これには、それぞれのロールが関連付けられる動詞およびリソースのマトリクスが含まれます。
プロジェクト管理者にバインドされるクラスターロールは、ローカルバインディングによってプロジェクト内で制限されます。これは、cluster-admin または system:admin に付与されるクラスターロールのようにクラスター全体でバインドされる訳ではありません。
クラスターロールは、クラスターレベルで定義されるロールですが、クラスターレベルまたはプロジェクトレベルのいずれかでバインドできます。
8.1.2.1. クラスターロールの集計
デフォルトの admin、edit、view、cluster-reader クラスターロールでは、クラスターロールの集約 がサポートされており、各ロールは新規ルール作成時に動的に更新されます。この機能は、カスタムリソースを作成して Kubernetes API を拡張する場合にのみ適用できます。
