RBAC を使用して Kubernetes リソースへのアクセスを制限する

この記事では、Kubernetes RBAC 認証モデルを最初から再作成する方法と、Roles、ClusterRoles、ServiceAccounts、RoleBindings、および ClusterRoleBindings 間の関係を理解する方法について説明します。

クラスター内のアプリケーションとリソースの数が増えると、危険な操作を回避するために、関連する権限を確認して制限する必要がある場合があります。これらの危険な操作は、多くの場合、本番環境に重大な影響を及ぼし、過剰な権限によって正常に実行されているサービスが削除されるなど、長期的なダウンタイムを引き起こすこともあります。

通常、運用システムを制限して、少数のユーザーのみが管理およびアクセスできるようにする必要があります。

あるいは、クラスターにデプロイされたメンテナーに限定された権限セットを付与することもできます。

上記の要件は、Kubernetes のロールベースアクセス制御 (RBAC) を通じて実現できます。

Kubernetes API

RBAC について説明する前に、認可モデルがどこに当てはまるかを見てみましょう。

次の Pod を Kubernetes クラスターにデプロイするとします。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: my-pod
 仕様:
 コンテナ:
 - 名前： sise
 画像: learnk8s / アプリ: 1.0.0
 ポート:
 - コンテナポート: 8080

次のコマンドを使用して、Pod をクラスターにデプロイできます。

 $ kubectl apply -f ポッド.yaml

kubectl apply を入力すると、次の操作がトリガーされます。

kubectl は次のことを行います。

1. KUBECONFIG から構成を読み取ります。

2. API と API からのオブジェクトを検出します。

3. リソースクライアントを検証します (明らかなエラーはありますか?)。

4. ペイロードを含むリクエストを kube-apiserver に送信します。

kube-apiserver はリクエストを受信しても、それをすぐに etcd に保存しません。

まず、リクエスト者が正当であることを確認する必要があります。

つまり、リクエストを認証する必要があります。 (https://kubernetes.io/docs/reference/access-authn-authz/authentication/)。

認証されると、リクエスト者はリソースを作成する権限を持ちますか?

ID と権限は同じものではありません。

クラスターにアクセスできるからといって、すべてのリソースを作成したり読み取ったりできるわけではありません。

承認は通常、ロールベースのアクセス制御 (RBAC) (https://kubernetes.io/docs/reference/access-authn-authz/rbac/) を使用して行われます。

ロールベースのアクセス制御 (RBAC) を使用すると、きめ細かい権限を割り当て、ユーザーまたはアプリケーションが実行できるアクションを制限できます。

より現実的なシナリオでは、API サーバーは次の操作を順番に実行します。

1. リクエストを受信したら、ユーザーを認証します。

a.認証に失敗した場合は、401 Unauthorized を返してリクエストを拒否します。
b、それ以外の場合は、次の段階に進みます。

2. ユーザーは認証されていますが、リソースにアクセスできますか?

a.許可がない場合は、403 Forbidden を返してリクエストを拒否します。
b.それ以外の場合は、続行します。

この記事では、認可の部分に焦点を当てます。

RBAC ロールからユーザーと権限を切り離す

RBAC (ロールベースアクセス制御) とは、ロールベースの権限制御を意味します。ロールをユーザーに関連付け、ロールを権限に関連付けることで、ユーザーに間接的に権限が付与されます。以下のように表示されます。

ロールを追加するのではなく、ユーザーに権限を割り当てるだけではダメなのかと疑問に思う人もいるかもしれません。

実際、ユーザーに権限を直接割り当てることは可能ですが、ユーザーに権限を直接割り当てると関係のレイヤーが欠如し、スケーラビリティが大幅に低下します。ユーザー数とロールタイプが少ないプラットフォームにのみ適しています。

たとえば、一般的なシステムでは、同じ権限を持つ複数のユーザーが存在する場合、割り当て時にこれらのユーザーに同じ権限を個別に割り当て、変更時にこれらのユーザーの権限を 1 つずつ変更する必要があります。ロールを作成したら、ロールの権限を定義し、同じ権限を持つユーザーを同じロールに割り当てるだけで、権限管理が容易になります。

バッチユーザー権限調整の場合は、ユーザーに関連付けられているロール権限を調整するだけで済みます。ユーザーごとに権限を調整する必要はありません。これにより、権限調整の効率が大幅に向上し、権限が欠落する可能性が低減します。

これがどのように機能するかを理解するために、認証システムをゼロから設計する必要があると想像してみましょう。ユーザーが特定のリソースへの書き込みアクセス権を持っていることをどのように確認すればよいでしょうか?

単純な実装では、次のようなリストを記述することになります。

 | ユーザー| 許可| リソース|
 | ----- | ---------- | -------- |
 | ボブ読み取り+ 書き込み| アプリ1
 | アリス読む| アプリ2
 | モ読む| アプリ2

この例では、

· Bob には読み取りおよび書き込み権限があり、app1 にはアクセスできますが、app2 にはアクセスできません。
Mo と Alice は app2 に対して読み取り専用アクセス権を持ちますが、app1 に対してはアクセス権を持ちません。

上記の表は、ユーザー数とリソース数が少ない場合には適していますが、スケーリングを開始すると、いくつかの制限が現れます。

Mo と Alice が同じチームに所属しており、app1 への読み取りアクセス権が付与されていると仮定します。

次のエントリをテーブルに追加する必要があります。

 | ユーザー| 許可| リソース|
 | --------- | ---------- | -------- |
 | ボブ読み取り+ 書き込み| アプリ1
 | アリス読む| アプリ2
 | モ読む| アプリ2
 | アリス読む| アプリ1
 | モ読む| アプリ1

これは素晴らしいことですが、Alice と Mo は同じチームのメンバーであるため、同じアクセス権を持っているかどうかは明らかではありません。

一般的な認証システムでは、ユーザーがリソースにアクセスします。

ユーザーに直接権限を割り当て、ユーザーが使用できるリソースを定義できます。

これらの権限はリソースに直接マップされます。これらがユーザーにとってどのように機能するかに注目してください。
2 番目のユーザーに同じ権限を付与する場合は、同じ権限を関連付ける必要があります。

テーブルに「チーム」列を追加することでこれを修正できますが、より良い代替案は関係を分解することです。

1. 権限の共通属性であるロールを定義できます。
2. ユーザーに権限を直接割り当てる代わりに、定義済みの組織「チーム」を承認することができます。
3. 最後に、定義した組織「チーム」にユーザーを追加できます。

これがどのような違いをもたらすか見てみましょう。これで、2 つの権限マッピングテーブルが作成されました。

最初の表では、権限が役割にマッピングされています
2番目の表では、ロールはアイデンティティに関連付けられています

 | 役割| 許可| リソース|
 | -------- | ---------- | -------- |
 | 管理者1 | 読み取り+ 書き込み| アプリ1
 | レビュアー| 読む| アプリ2

 | ユーザー| 役割|
 | ----- | -------- |
 | ボブ管理者1 |
 | アリスレビュアー|
 | モレビュアー|

Mo を app1 の管理者にしたい場合はどうすればよいでしょうか?

次のようにしてユーザーにロールを追加できます。

 | ユーザー| 役割|
 | ----- | ------------------- |
 | ボブ管理者1 |
 | アリスレビュアー|
 | ま

ユーザーと権限をロールから分離すると、多数のユーザーと権限を持つ大規模な組織でのセキュリティ管理が容易になることは、すでに想像できます。

RBAC を使用する場合、ユーザー、リソース、およびロールが存在します。

権限はユーザーに直接割り当てられません。代わりに、それらは役割に含まれます。

ユーザーはバインディングを通じてロールに関連付けられます。

ロールは汎用的であるため、新しいユーザーが同じリソースにアクセスする必要がある場合は、既存のロールを使用して、新しいバインディングを関連付けることができます。

Kubernetes の RBAC

Kubernetes は、クラスター内のリソースを保護するために、RBAC モデル (およびその他のモデル) (https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules) を実装します。

ロールベースのアクセス制御 (RBAC) は、組織内のユーザーの役割に基づいてコンピューターまたはネットワークリソースへのアクセスを制御する方法です。

RBAC 認証メカニズムは、rbac.authorization.k8s.io API グループを使用して認証決定を実行し、Kubernetes API を通じてポリシーを動的に構成できるようにします。

RBAC を有効にするには、--authorization-mode パラメータをコンマ区切りのリストに設定して API サーバーを起動し、RBAC が含まれていることを確認します。

 kube-apiserver --authorization-mode = 例、 RBAC -- <その他のオプション> -- <その他のオプション>

したがって、Kubernetes は、前に説明したのと同じ 3 つの概念、つまり ID、ロール、バインディングを使用します。

ただ、少しだけ違う名前で呼ばれているだけです。

たとえば、Pod やサービスなどのリソースへのアクセスを許可するために必要な次の YAML 定義を調べてみましょう。

 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 名前: サービスアカウント: app1
 名前空間: デモ名前空間
---
 apiバージョン: rbac .authorization .k8s .io / v1
 種類: 役割
メタデータ:
 名前: 役割: 閲覧者
名前空間: デモ名前空間
ルール: # このロールの承認ルール
-apiGroups : # 最初のAPI グループ
- '' # 空の文字列はコアAPI グループを指定します。
 リソース：
 - サービス
- ポッド
動詞:
 - 得る
- リスト
-apiGroups : # 2番目のAPI グループ
-apextensions.k8s.io
 リソース：
 - カスタムリソース定義
動詞:
 - リスト
-apiGroups : # 3番目のAPI グループ
- cilium.io
 リソース：
 - ciliumnetworkポリシー
-ciliumnetworkpolicies / ステータス
---
 apiバージョン: rbac .authorization .k8s .io / v1
 種類: RoleBinding
 メタデータ:
 名前: ロールバインディング: app1-viewer
 名前空間: デモ名前空間
ロールリファレンス:
 apiグループ: rbac .authorization .k8s .io
 種類: 役割
名前: 役割: 閲覧者
科目:
 - 種類: サービスアカウント
名前: サービスアカウント: app1
 名前空間: デモ名前空間

この文書は 3 つの部分に分かれています。

1. ServiceAccount – これはリソースにアクセスするユーザーの ID です。
2. ロール - リソースにアクセスするための権限が含まれます。
3. ID (ServiceAccount) を権限 (Role) の RoleBinding に関連付けます。

構成がクラスターにコミットされると、サービスアカウントを使用するアプリケーションは次のエンドポイントにリクエストを送信できるようになります。

 # 1. Kubernetes 組み込みリソース
/ api / v1 / 名前空間/{ 名前空間}/ サービス
/ api / v1 / 名前空間/{ 名前空間}/ ポッド
# 2. cilium .io が提供する特定のAPI 拡張
/apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies
 /apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies/status

結果は成功しましたが、多くの詳細を見落としていました。

どのようなリソースへのアクセスを許可しますか?

サービスアカウントとは何ですか?アイデンティティはクラスター内の単なる「ユーザー」ではないのですか?

Role に Kubernetes オブジェクトのリストが含まれているのはなぜですか?

これらがどのように機能するかを理解するために、Kubernetes RBAC モデルを破棄して、ゼロから再構築してみましょう。

私たちは次の 3 つの要素に焦点を当てます。

1. ID を識別して割り当てます。
2. 権限を付与します。
3. ID を権限に関連付けます。

ID の割り当て: ユーザー、グループ、ロボットアカウント

新しい同僚が Kubernetes インターフェースにログインしたいとします。

この場合、「アカウント」または「ユーザー」というエンティティがあり、それぞれに一意の名前または ID (電子メールアドレスなど) が付けられている必要があります。

クラスターにユーザーをどのように保存すればよいでしょうか?

Kubernetes には、通常のユーザーアカウントを表すオブジェクトはありません。

API 呼び出しを通じてクラスターにユーザーを追加する方法はありません。

代わりに、クラスターの証明機関 (CA) によって署名された有効な証明書を提示する参加者は、認証済みとみなされます。 (https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)。

この場合、Kubernetes は証明書の「サブジェクト」の共通名フィールドからユーザー名を割り当てます (例: 「/CN=bob」)。

一時的なユーザー情報オブジェクトを作成し、それを認証 (RBAC) モジュールに渡します。

コードをさらに深く掘り下げていくと、認証モジュールから収集されたすべての詳細をマッピングする構造が見つかります。

 タイプUser 構造体{
 名前文字列// ユーザーごとに一意
 ... // その他のフィールド
}

ユーザーはクラスター外のユーザーまたはアプリケーションに使用されることに注意してください。

クラスター内のアプリケーションを識別する場合は、代わりにサービスアカウントを使用する必要があります。

このアカウントは通常のユーザーと非常に似ていますが、Kubernetes が管理するという点が異なります。

サービスアカウントは通常、権限を付与するためにポッドに割り当てられます。

たとえば、次のアプリケーションがクラスター内からリソースにアクセスできるようになります。

· cilium-agent は特定のノード上のすべてのポッドリソースを一覧表示する必要があります。 · ingress nginx コントローラーはサービスのすべてのバックエンドエンドポイントを一覧表示する必要があります。

これらのアプリケーションでは、ServiceAccount (SA) を定義できます。

サービスアカウントはクラスター内で管理されるため、YAML を使用して作成できます。

 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 name : sa : app1 # 任意だが一意の文字列
名前空間: デモ名前空間

Kubernetes の管理を容易にするために、User または ServiceAccount のセットを定義することもできます。

この方法では、特定の名前空間内のすべての ServiceAccounts を簡単に参照できます。

リソースにアクセスする方法を定義したので、次は権限について説明します。

この時点で、リソースにアクセスできるユーザーを決定するメカニズムができました。

それは個人、ボットアカウント、または人々のグループである可能性があります。

しかし、クラスター内のどのリソースにアクセスするのでしょうか?

リソースへのアクセスのモデリング

Kubernetes では、ポッド、サービス、エンドポイントなどのリソースへのアクセスを制御することに興味があります。

これらのリソースは通常、データベース (etcd) に保存され、次のような組み込み API を介してアクセスされます。

 / api / v1 / 名前空間/{ 名前空間}/ ポッド/{ 名前}
 / api / v1 / 名前空間/{ 名前空間}/ ポッド/{ 名前}/ ログ
/ api / v1 / 名前空間/{ 名前空間}/ サービス アカウント/{ 名前}

これらのリソースへのアクセスを制限する最善の方法は、これらの API エンドポイントへのリクエストの送信方法を制御することです。

これを行うには、次の 2 つが必要です。

1. リソースの API エンドポイント。
2. リソースにアクセスするために付与される権限の種類 (読み取り専用、読み取り/書き込みなど)。

権限については、get、list、create、patch、delete などの動詞を使用します。

Pod、ログ、サービスなどのリソースを取得、一覧表示、監視したいとします。

次のように、これらのリソースと権限を 1 つのリストに組み合わせることができます。

 リソース：
 - / api / v1 / namespaces /{ 名前空間}/ pods /{ 名前}
 - / api / v1 / namespaces /{ namespace }/ pods /{ name }/ ログ
- / api / v1 / namespaces /{ namespace }/ serviceaccounts /{ name }
 動詞:
 - 得る
- リスト
- 時計

以下の情報に基づいて、上記の定義を簡略化できます。

ベース URL /api/v1/namespaces/ はすべてのユーザーに共通です。省略できるかも知れません。
すべてのリソースが現在の名前空間にあると想定して、{namespace} パスを削除できます。

最終的には次のように簡略化できます。

 リソース：
 - ポッド
- ポッド/ ログ
-サービスアカウント
動詞:
 - 得る
- リスト
- 時計

この定義はよりユーザーフレンドリーであり、関連する権限情報を明確に理解できます。

ただし、権限の構成は上記だけではありません。

Kubernetes は、ポッド、エンドポイント、サービスなどの組み込みオブジェクトの API に加えて、API 拡張もサポートしています。

たとえば、を使用して Cilium CNI をインストールする場合、スクリプトは CiliumEndpoint カスタムリソース (CR) を作成します。

 apiバージョン: apiextensions .k8s .io / v1
 種類: カスタムリソース定義
メタデータ:
 名前: ciliumendpoints.cilium.io
 仕様:
 グループ: cilium.io
 名前:
 種類: CiliumEndpoint
 スコープ: 名前空間
# 切り捨てられました...

これらのオブジェクトはクラスターに保存され、kubectl 経由で利用できます。

 $ kubectl get ciliumendpoints .cilium .io - n デモ名前空間
名前エンドポイントID アイデンティティエンドポイントの状態IPV4
 6.1.1. IPv6について
app1 2773 1628124 準備完了10.6.7.54
 app2 3568 1624494 準備完了10.6.7.94
 app3 3934 1575701 準備完了10.6.4.24
 $

カスタムリソースには、Kubernetes API を介して同様にアクセスできます。

 /apis/cilium.io/v2/namespaces/{namespace}/ciliumendpoints
 /apis/cilium.io/v2/namespaces/ { 名前空間} / ciliumendpoints / { 名前}

YAML ファイルでマッピングする場合は、次のように記述します。

 リソース：
 - ciliumnetworkポリシー
-ciliumnetworkpolicies / ステータス
動詞:
 - 得る

しかし、Kubernetes はリソースがカスタマイズされていることをどのようにして知るのでしょうか?

カスタムリソースと組み込み API の使用をどのように区別しますか?

残念ながら、API エンドポイントから URL を削除するのは良い考えではありません。

少し変更するだけで復元できます。

これを先頭で定義し、後でリソースの URL を拡張するために使用できます。

 apiグループ:
 - cilium.io # APIグループ名
リソース：
 - ciliumnetworkポリシー
-ciliumnetworkpolicies / ステータス
動詞:
 - 得る

名前空間 API を持たない POD などのリソースについてはどうでしょうか?

Kubernetes の「空の API グループ」は、組み込みオブジェクトを参照する特別なグループです。したがって、以前の定義は次のように拡張する必要があります。

 apiグループ:
 - '' # 組み込みオブジェクト
リソース：
 - ポッド
- ポッド/ ログ
-サービスアカウント
動詞:
 - 得る
- リスト
- 時計

Kubernetes は API グループを読み取り、自動的に次のように拡張します。

空の場合、"" は /api/v1/xxx に変換されます。
それ以外の場合は、/apis/{apigroup_name}/{apigroup_version}/xxx になります。

リソースと権限をマッピングする方法がわかったので、次は複数のリソースへのアクセスをグループ化します。 Kubernetes では、リソースと動詞のコレクションはルールと呼ばれ、ルールをリストにグループ化できます。

 ルール:
 - ルール1
 - ルール2

各ルールには、上で説明した apiGroup、リソース、および動詞が含まれています。

 ルール: # 承認ルール
-apiGroups : # 最初のAPI グループ
- '' # 空の文字列はコアAPI グループを指定します。
 リソース：
 - ポッド
- ポッド/ ログ
-サービスアカウント
動詞:
 - 得る
- リスト
- 時計
- apiGroups : # 別のAPI グループ
- cilium .io # カスタムAPI グループ
リソース：
 - ciliumnetworkポリシー
-ciliumnetworkpolicies / ステータス
動詞:
 - 得る

Kubernetes では、ルールのコレクションにはロールと呼ばれる特定の名前が付けられています。

 apiバージョン: rbac .authorization .k8s .io / v1
 種類: 役割
メタデータ:
 名前: 視聴者
ルール: # 承認ルール
-apiGroups : # 最初のAPI グループ
- '' # 空の文字列はコアAPI グループを指定します。
 リソース：
 - ポッド
- ポッド/ ログ
-サービスアカウント
動詞:
 - 得る
- リスト
- 時計
- apiGroups : # 別のAPI グループ
- cilium .io # カスタムAPI グループ
リソース：
 - ciliumnetworkポリシー
-ciliumnetworkpolicies / ステータス
動詞:
 - 得る

これまでに、次のことを定義しました。

· ユーザー、サービスアカウント、およびグループの ID を持ちます。
ロールを持つリソースへの権限。

ついに、両者をつなぐ欠けているピースが見つかりました。

ユーザーに権限を付与する

RoleBinding は、ロールで定義された権限をユーザー、サービスアカウント、またはグループに付与します。例を見てみましょう:

 apiバージョン: rbac .authorization .k8s .io / v1
 種類: RoleBinding
 メタデータ:
 名前: role-binding-for-app1
 ロールリファレンス:
 apiグループ: rbac .authorization .k8s .io
 種類: 役割
名前: 視聴者
科目:
 - 種類: サービスアカウント
名前: sa-for-app1
 名前空間: kube-system

この定義には 2 つの重要なフィールドがあります。

閲覧者ロールを参照する roleRef。
sa-for-app1 サービスアカウントに関連付けられているサブジェクト。

リソースがクラスターに送信されると、サービスアカウントを使用するアプリケーションまたはユーザーは、ロールにリストされているリソースにアクセスできるようになります。

バインディングを削除すると、アプリケーションまたはユーザーはそれらのリソースにアクセスできなくなります (ただし、ロールは常に他のバインディングで使用できる状態になります)。

主題フィールドは、種類、名前空間、名前を含むリストであることに注意してください。

サービスアカウントおよびグループからユーザーを識別するには、kind 属性が必要です。

しかし、名前空間はどうでしょうか?

多くの場合、クラスターを名前空間に分割し、名前空間リソースへのアクセスを特定のアカウントに制限すると役立ちます。

ほとんどの場合、Roles と RoleBindings は名前空間に関連付けられ、特定の名前空間へのアクセスを許可します。

ただし、2 つのリソースを混在させることもできます。その方法については後で説明します。

理論を終えて実践を始める前に、いくつかの科目の例を見てみましょう。

 科目:
 - 種類: グループ
名前: システム: サービスアカウント
apiグループ: rbac .authorization .k8s .io
 # 名前空間フィールドが指定されていない場合、 これはすべての名前空間内のすべてのサービスアカウントを対象とします

複数のグループ、ユーザー、またはサービスアカウントをサブジェクトとして含めることもできます。

 科目:
 - 種類: グループ
name : system : authenticated # 認証されたすべてのユーザー
apiグループ: rbac .authorization .k8s .io
 - 種類: グループ
name : system : unauthenticated #認証されていないすべてのユーザー用
apiグループ: rbac .authorization .k8s .io

これまで学んだことを要約して、アプリケーションにいくつかのカスタムリソースへのアクセスを許可する方法を見てみましょう。

まず、シナリオを紹介しましょう。Cilium によって公開されるリソースにアクセスする必要があるアプリケーションがあります。

API を介してカスタムリソースにアクセスする必要があるアプリケーションがクラスターにデプロイされているとします。
これらの API へのアクセスを許可しないと、リクエストは失敗し、403 Forbidden エラーメッセージが表示されます。

これらのリソースへのアクセスを許可するにはどうすればよいですか?

サービスアカウント、ロール、ロールバインディングを使用します。

まず、ワークロードの ID を作成する必要があります。 Kubernetes では、これはサービスアカウントを作成することを意味します。

次に、権限を定義し、それをロールに含める必要があります。

最後に、RoleBinding を介して ID (サービスアカウント) を権限 (ロール) に関連付けます。

次回アプリケーションが Kubernetes API にリクエストを送信すると、Cilium リソースへのアクセスが許可されます。

名前空間とクラスター全体のリソース

リソースについて説明したとき、エンドポイントの構造は次のようになることを学習しました。

 / api / v1 / 名前空間/{ 名前空間}/ ポッド/{ 名前}
 / api / v1 / 名前空間/{ 名前空間}/ ポッド/{ 名前}/ ログ
/ api / v1 / 名前空間/{ 名前空間}/ サービス アカウント/{ 名前}

しかし、永続ボリュームやノードなど、名前空間のないリソースはどうでしょうか?

名前空間リソースは名前空間内でのみ作成でき、名前空間の名前は HTTP パスに含まれます。

リソースがノードなどのグローバルである場合、名前空間名は HTTP パスに表示されません。

 / api / v1 / ノード/{ 名前}
 / api / v1 / 永続ボリューム/{ 名前}

それらをキャラクターに追加できますか?

はい、追加できます。

結局のところ、Roles と RoleBindings を導入したとき、名前空間の制限については何も説明しませんでした。

次に例を示します。

 apiバージョン: rbac .authorization .k8s .io / v1
 種類: 役割
メタデータ:
 名前: 視聴者
ルール: # 承認ルール
-apiGroups : # 最初のAPI グループ
- '' # 空の文字列はコアAPI グループを指定します。
 リソース：
 -永続ボリューム
- ノード
動詞:
 - 得る
- リスト
- 時計

ただし、その構成をコミットしてサービスアカウントに関連付けようとすると、機能しないことに気付くかもしれません。

PersistentVolume と Node はクラスタースコープのリソースです。

ただし、ロールは名前空間スコープでリソースへのアクセスを許可できます。

クラスター全体に適用されるロールを使用する場合は、ClusterRole (および対応する ClusterRoleBinding を使用してサブジェクトを割り当てる) を使用できます。

以前の構成を次のように変更する必要があります。

 apiバージョン: rbac .authorization .k8s .io / v1
 種類: ClusterRole
 メタデータ:
 名前: 視聴者
ルール: # 承認ルール
-apiGroups : # 最初のAPI グループ
- '' # 空の文字列はコアAPI グループを指定します。
 リソース：
 -永続ボリューム
- ノード
動詞:
 - 得る
- リスト
- 時計

唯一の変更点は kind プロパティであり、その他はすべて同じままであることに注意してください。

ClusterRoles を使用すると、クラスター内のすべての Pod など、すべてのリソースに権限を付与できます。

この機能は、クラスタースコープのリソースに限定されません。

Kubernetes にはすでに多数のロールとクラスターロールが付属しています。

見てみましょう。

 $ kubectl ロールを取得- n kube-system | grep "^system:"
 名前
システム:: リーダーロック Kube コントローラ マネージャー
システム:: リーダーロック Kube スケジューラ
システム: コントローラ: ブートストラップ署名者
システム: コントローラ: クラウドプロバイダー
システム: コントローラ: トークンクリーナー
# 出力が切り捨てられました...

system: プレフィックスは、リソースがクラスターコントロールプレーンによって直接管理されることを示します。

さらに、すべてのデフォルトの ClusterRole と ClusterRoleBinding には、kubernetes.io/bootstrapping=rbac-defaults がマークされています。

ClusterRoles もリストしてみましょう。

 kubectlでクラスターロールを取得します- n kube-system | grep "^system:"
 名前
システム: 集約から管理者へ
システム: 集約して編集
システム: 集約して表示する
システム: 発見
システム: kube-apiserver
 システム: kube-controller-manager
 システム: kube-dns
 システム: kube-scheduler
 # 出力が切り捨てられました...

次のコマンドを使用して、各 Role と ClusterRole の詳細を確認できます。

 $ kubectl get role < ロール> -n kube - system -o yaml
 ＃ または
$ kubectl get クラスターロール< クラスターロール> - n kube-system - o yaml

これまで、Kubernetes RBAC の基礎を学習しました。

上記の内容を通じて、次のことがわかりました。

1. ユーザー、サービスアカウント、グループを使用して ID を作成する方法。
2. ロールを使用して名前空間内のリソースに権限を割り当てる方法。
3. ClusterRole を使用してクラスターリソースに権限を割り当てる方法。
4. ロールと ClusterRoles をサブジェクトに関連付ける方法。

最後に、RBAC の珍しいエッジケースをいくつか見てみましょう。

ロール、ロールバインディング、クラスターロール、クラスターバインディングを理解する

大まかに言えば、Roles と RoleBindings はクラスター内部にあり、特定の名前空間へのアクセスを許可しますが、ClusterRoles と ClusterRoleBinding は名前空間に依存せず、クラスター全体へのアクセスを許可します。

ただし、これら 2 種類のリソースを組み合わせて使用することも可能です。

たとえば、RoleBinding がアカウントを ClusterRole に関連付けると何が起こりますか?

この質問を練習を通して探ってみましょう。

minikube を使用してローカルクラスターを作成しましょう。

 $ ミニキューブを起動
😄 ミニキューブv1.24.0
 ✨ Docker ドライバーを自動的に選択しました
👍 クラスター内のコントロールプレーンノードを起動します
🚜 ベースイメージを取得しています...
 🔥 Docker コンテナを作成しています( CPU = 2 、 メモリ= 4096MB )...
 🐳 Docker 20.10.8 上でKubernetes v1 .22.3 を準備しています...
 ▪ 証明書とキーの生成...
 ▪ コントロールプレーンを起動しています...
 ▪ RBAC ルールの設定...
 🔎 Kubernetes コンポーネントを検証しています...
 ▪ イメージの使用gcr .io / k8s-minikube / storage-provisioner : v5
 🌟 有効なアドオン: storage-provisioner 、 default-storageclass
 🏄 完了！ kubectl はデフォルトでクラスターと「default」 名前空間を使用するように設定されるようになりました。

まず、4 つの名前空間を作成します。

 $ kubectl 名前空間テストを作成します
名前空間/ テストを作成しました
$ kubectl 名前空間test2 を作成します
名前空間/ test2 を作成しました
$ kubectl 名前空間test3 を作成します
名前空間/ test3 を作成しました
$ kubectl 名前空間test4 を作成します
名前空間/ test4 が作成されました

最後に、名前空間にサービスアカウントテストを作成します。

 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 名前: マイアカウント
名前空間: テスト

リソースは以下の方法で送信できます。

 $ kubectl apply -f サービス-account .yaml
 サービスアカウント/ マイアカウントが作成されました

この時点で、クラスターは次のようになります。

シナリオ 1: Role と RoleBinding が同じ名前空間にある

まず、サービスアカウントにテスト名前空間へのアクセスを許可する Role と RoleBinding を作成します。

 種類: 役割
apiバージョン: rbac .authorization .k8s .io / v1
 メタデータ:
 名前: testadmin
 名前空間: テスト
ルール:
 -apiグループ: [ '*' ]
 リソース： [ '*' ]
 動詞: [ '*' ]
 ---
 種類: RoleBinding
 apiバージョン: rbac .authorization .k8s .io / v1
 メタデータ:
 名前: testadminbinding
 名前空間: テスト
科目:
 - 種類: サービスアカウント
名前: マイアカウント
名前空間: テスト
ロールリファレンス:
 種類: 役割
名前: testadmin
 apiグループ: rbac .authorization .k8s .io

構成は次の方法で送信できます。

 $ kubectl apply -f シナリオ1 .yaml
 role .rbac .authorization .k8s .io / testadmin が作成されましたrolebinding .rbac .authorization .k8s .io / testadminbinding が作成されました

クラスターは次のようになります。

すべてのリソース (サービスアカウント、ロール、および RoleBinding) は名前空間内にあります。

ロールはすべてのリソースへのアクセスを許可し、RoleBinding はサービスアカウントをロールに関連付けます。

サービスアカウントがリソースにアクセスできるかどうかをテストするにはどうすればよいですか?

kubectl の 2 つの機能を組み合わせることができます。

1. ユーザー偽装アクセスには kubectl --as=jenkins を使用します (https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)。

2. kubectl auth can-i を使用して API アクセスを確認します (https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access)。

このアクションを許可するには、ユーザーに impersonateverb の権限が必要であることに注意してください。

myaccount サービスアカウントとしてリクエストを行い、名前空間内の Pod を一覧表示できることを確認するには、次のコマンドを使用します。

 $ kubectl auth can-i get pods -n test --as = system : serviceaccount : test : myaccount
 はい

コマンドを分解してみましょう:

· auth can-i にはクエリ認証モデル (RBAC) が必要です。
get pods は動詞であり、リソースでもあります。
-n test は、コマンドを発行する名前空間です。
--as=system:serviceaccount:test:myaccount は、myaccount サービスアカウントを偽装するために使用されます。

--as= フラグでは、サービスアカウントを識別するためにいくつかの追加のヒントが必要であることに注意してください。セクション全体は次のように分類できます。

 --as=system:serviceaccount:{名前空間}:{サービスアカウント名}
 ^^^^^^^^^^^^^^^^^^^^^^^^
 これはサービス アカウントに常に含まれている必要があります。

この Role+ServiceAccount+RoleBindings の組み合わせを通じて、テスト名前空間内のすべてのリソースにアクセスできます。

より複雑な例に移りましょう。

シナリオ 2: 異なる名前空間の Roles と RoleBindings

名前空間 test2 に新しい Role と RoleBinding を作成しましょう。

RoleBinding が test2 のロールと test のサービスアカウントをどのように関連付けるかに注目してください。

 種類: 役割
apiバージョン: rbac .authorization .k8s .io / v1
 メタデータ:
 名前空間: test2
 名前: testadmin
 ルール:
 -apiグループ: [ '*' ]
 リソース： [ '*' ]
 動詞: [ '*' ]
 ---
 種類: RoleBinding
 apiバージョン: rbac .authorization .k8s .io / v1
 メタデータ:
 名前: testadminbinding
 名前空間: test2
 科目:
 - 種類: サービスアカウント
名前: マイアカウント
名前空間: テスト
ロールリファレンス:
 種類: 役割
名前: testadmin
 apiグループ: rbac .authorization .k8s .io

リソースは以下の方法で送信できます。

 $ kubectl apply -f シナリオ2 .yaml
 ロール.rbac .authorization .k8s .io / testadmin が作成されました
rolebinding .rbac .authorization .k8s .io / testadminbinding が作成されました

クラスターは次のようになります。

test のサービスアカウントが test2 のリソースにアクセスできるかどうかをテストしてみましょう。

 $ kubectl auth can-i get pods - n test2 --as = system : serviceaccount : test : myaccount
 はい

サービスアカウントに、それが作成された名前空間外のリソースへのアクセスを許可しました。

RoleBinding の roleRef(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#roleref-v1-rbac-authorization-k8s-io) 属性には名前空間フィールドがないことに注意してください。

 種類: RoleBinding
 apiバージョン: rbac .authorization .k8s .io / v1
 メタデータ:
 名前: testadminbinding
 名前空間: test2
 科目:
 - 種類: サービスアカウント
名前: マイアカウント
名前空間: テスト
ロールリファレンス:
 種類: 役割
名前: testadmin
 apiグループ: rbac .authorization .k8s .io

つまり、RoleBinding は同じ名前空間内の Role のみを参照できます。

シナリオ 3: ClusterRole を RoleBinding と共に使用する

前述したように、ClusterRoles は名前空間に属しません。

つまり、ClusterRole は権限の範囲を単一の名前空間に限定しません。

ただし、ClusterRole が RoleBinding を介してサービスアカウントに関連付けられている場合、ClusterRole の権限は RoleBinding が作成された名前空間にのみ適用されます。

例を見てみましょう。

名前空間に RoleBindingtest3 を作成し、サービスアカウントを ClusterRole cluster-admin に関連付けます。

cluster-admin は、Kubernetes に組み込まれている ClusterRoles の 1 つです。

 種類: RoleBinding
 apiバージョン: rbac .authorization .k8s .io / v1
 メタデータ:
 名前: testadminbinding
 名前空間: test3
 科目:
 - 種類: サービスアカウント
名前: マイアカウント
名前空間: テスト
ロールリファレンス:
 種類: ClusterRole
 名前: クラスター管理者
apiグループ: rbac .authorization .k8s .io

リソースは以下の方法で送信できます。

 $ kubectl apply -f シナリオ3 .yaml
 rolebinding .rbac .authorization .k8s .io / testadminbinding が作成されました

クラスターは次のようになります。

test にあるサービスアカウントが test3 のリソースにアクセスできるかどうかをテストしてみましょう。

 $ kubectl auth can-i get pods - n test3 --as = system : serviceaccount : test : myaccount
 はい

ただし、他の名前空間にはアクセスできません。

 $ kubectl auth can-i get pods - n test4 --as = system : serviceaccount : test : myaccount
 いいえ
$ kubectl auth ポッドを取得できますか--as = system : serviceaccount : test : myaccount
 いいえ

この場合、RoleBindings を使用してサービスアカウントを ClusterRole に関連付けると、ClusterRole は通常のロールと同じように動作します。

RoleBinding が存在する現在の名前空間にのみ権限を付与します。

シナリオ 4: ClusterRole と ClusterRoleBinding を使用してクラスター全体のアクセス権限を付与する

最後のシナリオでは、ClusterRole をサービスアカウントに関連付ける ClusterRoleBinding を作成します。

 apiバージョン: rbac .authorization .k8s .io / v1
 種類: ClusterRoleBinding
 メタデータ:
 名前： testadminclusterbinding
 科目:
 - 種類: サービスアカウント
名前: マイアカウント
名前空間: テスト
ロールリファレンス:
 種類: ClusterRole
 名前: クラスター管理者
apiグループ: rbac .authorization .k8s .io

roleRef には namespace フィールドがないことに注意してください。

つまり、ロールは名前空間に属し、ClusterRoleBinding (およびそれらが参照する ClusterRolnamespace) には名前空間があるため、ClusterRoleBinding は関連付けるロールを識別できません。

リソースは以下の方法で送信できます。

 $ kubectl apply -f シナリオ3 .yaml
 rolebinding .rbac .authorization .k8s .io / testadminbinding が作成されました

クラスターは次のようになります。

ClusterRole も ClusterRole も名前空間を定義していませんが、サービスアカウントはすべてにアクセスできるようになりました。

 $ kubectl auth can-i get pods - n test4 --as = system : serviceaccount : test : myaccount
 はい
$ kubectl auth 名前空間を取得できますか--as = system : serviceaccount : test : myaccount
 警告: リソース'namespaces' は名前空間スコープではありません
はい

これらの例から、RBAC リソースのいくつかの動作と制限を確認できます。

· Roles と RoleBindings は同じ名前空間に存在する必要があります。
RoleBinding は、サービスアカウント内の個別の名前空間に存在できます。
· RoleBindings は ClusterRoles に関連付けることができますが、RoleBinding が存在する名前空間へのアクセスのみを許可します。
ClusterRoleBindings は、アカウントを ClusterRole に関連付け、すべてのリソースへのアクセスを許可します。
ClusterRoleBindings はロールを参照できません。

おそらく、ここで最も興味深い意味は、RoleBinding によって参照される場合、ClusterRole は単一の名前空間で表現される共通の権限を定義できるということです。この方法では、名前空間内に重複したロールを持つ必要がなくなります。

ボーナス＃1：RBACポリシーをより簡潔にする

Role または ClusterRole の一般的なルールセクションは次のようになります。

 ルール:
 -apiグループ:
 - "
 リソース：
 - ポッド
- エンドポイント
- 名前空間
動詞:
 - 得る
- 時計
- リスト
- 作成する
- 消去

ただし、上記の構成は次の形式を使用して書き換えることができます。

 -apiグループ: [ '' ]
 リソース: [ 'サービス' 、 'エンドポイント' 、 '名前空間' ]
 動詞: [ 'get' 、 'list' 、 'watch' 、 'create' 、 'delete' ]

このアプローチにより、行数が大幅に削減され、より簡潔になります。

ただし、データベースからコンテンツを取得する場合、Kubernetes は引き続きコンテンツを YAML リストとして管理します。

したがって、Role を取得するたびに、配列はリストにレンダリングされます。

 $ kubectlはポッドリーダーを取得します-o yaml
 apiバージョン: rbac .authorization .k8s .io / v1
 種類: 役割
ルール:
 - APIGROUPS ：
 - 「」
 リソース：
 - ポッド
＃ 切り捨てられた出力...

ボーナス＃2：サービスアカウントを使用したKubernetesアカウントの作成

サービスアカウントは通常、APIサーバーによって自動的に作成され、クラスターで実行されているポッドに関連付けられます。 3つの別々のコンポーネントがこのタスクを達成します。

1. POD定義にServiceAcCount属性を使用して、ServiceAcCount入学コントローラーを注入します。
2。付随する秘密のオブジェクトを作成するトークンコントローラー。
3. ServiceAcCountコントローラーは、各名前空間にデフォルトのサービスアカウントを作成します。

サービスアカウントをクラスターの外側で使用して、ユーザーのアイデンティティを作成したり、Kubernetes APIと話をしたりしたい長年のジョブを作成できます。

サービスアカウントを手動で作成するには、次のコマンドを使用できます。

 $ kubectl create serviceaccount demo-sa
 ServiceAcCount / Demo-SA 作成
$ kubectl get serviceaccounts demo -sa -o yaml
 APIバージョン: v1
 種類: サービスアカウント
メタデータ:
 名前： Demo-sa
 名前空間: デフォルト
リソースバージョン： "1985126654"
 selflink ： / api / v1 / namespaces / default / serviceaccounts / demo-sa
 UID ： 01B2A3F9 -A373- 6E74 -B3AE- D89F6C0E321F
 秘密:
 - 名前： Demo-sa-token-hrfq2

Secrets ServiceアカウントYAML定義の最後にあるフィールドに気付くかもしれません。

それは何ですか？

サービスアカウントを作成するたびに、Kubernetesは秘密を作成します。

秘密は、サービスアカウントのトークンを保持しており、これをKubernetes APIと呼ぶために使用できます。

また、APIサーバー用のパブリック認証局（CA）も含まれています。

 $ kubectl get Secret demo-sa-token-hrfq2 - o yaml
 APIバージョン: v1
 データ：
 ca .crt ：（ Apiserver のCA Base64エンコード）
 名前空間： zgvmyxvsda ==
 トークン：（ ベアラートークンBase64 エンコード）
 種類: 秘密
メタデータ:
 ＃ 切り捨てられた出力...
 タイプ： kubernetes .io / service-account-token

トークンは署名されたJWTであり、Kube-Apiserverサービスに対して認証するためにベアラートークンとして使用できます。通常、これらの秘密はポッドに取り付けられ、APIサービスへのアクセスに使用されますが、クラスターの外側から使用できます。

ボーナス＃3：kubernetesデフォルトの役割

いくつかの役割は、kubernetesに組み込まれたデフォルトの役割であり、それらを変更する必要はありません。

デフォルトの役割：

デフォルトのクラスターロール	デフォルトのクラスターロールバインディング	説明する
クラスターアドミン	システム：マスターズグループ	スーパーユーザーは、プラットフォーム上の任意のリソースですべての操作を実行できます。 Clusterrolebindingで使用すると、クラスターおよびすべての名前空間のすべてのリソースの完全な制御を承認できます。ロールバインディングで使用する場合、名前空間自体を含むロールバインディングがある名前空間内のすべてのリソースの制御を承認できます。
管理者	なし	ロールバインディングを使用して名前空間内で承認を実行するように設計された管理者アクセスを許可します。ロールバインディングで使用される場合は、ロールとロールバインディングを作成する機能など、名前空間のほとんどのリソースに読み取り/書き込み許可を付与できます。この役割は、リソースクォータまたは名前空間自体への書き込み操作を許可しません。この役割は、Kubernetes v1.22+によって作成されたエンドポイントへの書き込みも許可していません。詳細については、「エンドポイントの書き込み許可」セクションを参照してください。
編集	なし	名前空間内のほとんどのオブジェクトで操作を読み取り/書き込むことができます。ロールまたはロールバインディングを表示または変更することはできません。ただし、この役割は、名前空間の任意のServiceAcCountとしてポッドを実行して秘密にアクセスできるため、名前空間のすべてのサービスアカウントのAPIアクセスレベルを理解するために使用できます。この役割は、Kubernetes v1.22+によって作成されたエンドポイントへの書き込みも許可していません。詳細については、「エンドポイント書き込み操作」セクションを参照してください。
ビュー	なし	名前空間内のほとんどのオブジェクトに読み取り専用権限を許可します。役割や役割のバインディングの表示を許可しません。秘密のコンテンツを読むと、名前空間のServiceAcCountの資格情報にアクセスすることを意味するため、この役割は秘密を見ることができません。これにより、名前空間のServiceAcCountのIDを使用してAPIへのアクセスが可能になります（これは特権エスカレーションです）。

コアコンポーネントの役割： （https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#core-componentロール）。

デフォルトのクラスターロール	デフォルトのクラスターロールバインディング	説明する
システム：Kube-Scheduler	システム：kube-schedulerユーザー	スケジューラコンポーネントに必要なリソースへのアクセスを可能にします。
システム：ボリュームスケジューラー	システム：kube-schedulerユーザー	Kube-Schedulerコンポーネントが必要とするボリュームリソースへのアクセスを可能にします。
システム：Kube-Controller-Manager	システム：Kube-Controller-Managerユーザー	Controller Managerコンポーネントが必要とするリソースへのアクセスを可能にします。各コントロールループに必要な権限は、コントローラーの役割で説明されています。
システム：ノード	なし	すべての秘密の読み取り操作や、すべてのPOD状態オブジェクトへの操作を書き込むなど、Kubeletに必要なリソースへのアクセスが可能になります。システム：ノードロールの代わりに、ノード認証コンポーネントとNoderestriction Andimingプラグインを使用する必要があります。同時に、kubeletアクセスは、kubeletでスケジュールされた実行されたポッドに基づいてAPIへのアクセスが承認されます。システム：ノードの役割は、v1.8の以前のバージョンからアップグレードされたクラスターとの互換性のためのみです。
システム：ノードプロキシ	システム：Kube-Proxyユーザー	Kube-Proxyコンポーネントに必要なリソースへのアクセスを可能にします。

その他のコンポーネントの役割： （https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#other-componentロール）。

デフォルトのクラスターロール	デフォルトのクラスターロールバインディング	説明する
システム：Auth-Delegator	なし	ID認証と認証検査操作のアウトソーシングが可能になります。この役割は通常、プラグインAPIサーバーで使用され、統一されたID認証と認証を実現します。
システム：Heapster	なし	Heapsterコンポーネント（非推奨）について定義された役割。
システム：Kube-Aggregator	なし	Kube-Aggregatorコンポーネントで定義された役割。
システム：kube-dns	Kube-dnsサービスアカウントKube-System Namespace	Kube-DNSコンポーネントに対して定義された役割。
システム：kubelet-api-admin	なし	Kubelet APIへの完全なアクセスを可能にします。
システム：ノードブートストラッパー	なし	Kubelet TLSブートブートを実行するために必要なリソースへのアクセスを可能にします。
システム：ノードプローム検出器	なし	ノードプローム検出コンポーネントのロール。
システム：Persistent-Volume-Provisioner	なし	動的ボリュームドライバーが必要とするほとんどのリソースにアクセスできます。
システム：監視	システム：監視グループ	コントロールプレーンの監視エンドポイントへのアクセスを読み取ることができます（たとえば、Kube-Apiserver Survival and Ready Endpoints（ /Healthz、 /livez、 /Readyz）、個々の健康チェックエンドポイント（ /Healthz /、 /livez /、 /readyz /*）、および /メトリック）。個々のヘルスチェックエンドポイントとメトリックエンドポイントは、機密情報を公開する可能性があることに注意してください。

組み込みコントローラーの役割： （https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#controller-ロール）。

Kubernetesコントローラーマネージャー内蔵のKubernetesコントロールプレーンを実行するコントローラー。 -Use-Service-Account-Credentialsパラメーターの使用を開始すると、Kube-Controller-Managerは個別のサービスアカウントを使用して各コントローラーを開始します。各組み込みコントローラーには、システムが付いた対応する役割があります：コントローラー：。 Control Managerが起動するときに使用されている-Service-Account-Credentialsが設定されていない場合、独自のID資格情報を使用してすべてのコントローラーを実行し、そのIDはすべての関連する役割に付与されなければなりません。これらの役割には以下が含まれます。

システム：コントローラー：AttachDetach-Controller
システム：コントローラー：証明書制御者
システム：コントローラー：Clusterrole-Aggregation-Controller
システム：コントローラー：Cronjob-Controller
システム：コントローラー：デーモンセットコントローラー
システム：コントローラー：Deployment-Controller
システム：コントローラー：破壊コントローラー
システム：コントローラー：エンドポイントコントローラー
システム：コントローラー：展開コントローラー
システム：コントローラー：generic-garbage-collector
システム：コントローラー：Horizontal-Pod-Autoscaler
システム：コントローラー：ジョブコントローラー
システム：コントローラー：名前空間コントローラー
システム：コントローラー：ノードコントローラー
システム：コントローラー：Persistent-Volume-Binder
システム：コントローラー：Pod-Garbage-Collector
システム：コントローラー：PV保護制御
システム：コントローラー：PVC-Protection-Controller
システム：コントローラー：Replicaset-Controller
システム：コントローラー：レプリケーションコントローラー
システム：コントローラー：ResourceQuota-Controller
システム：コントローラー：root-ca-cert-publisher
システム：コントローラー：ルートコントローラー
システム：コントローラー：Service-Account-Controller
システム：コントローラー：サービスコントローラー
システム：コントローラー：Statefulset-Controller
システム：コントローラー：TTL-Controller

追加＃4：許可のアップグレードの初期化と防止

RBAC APIは、ロールまたはロールバインディングを編集することにより、ユーザーがアクセス許可を高めることを防ぎます。これはAPIレベルで実装されているため、RBAC認証コンポーネントが有効になっていない場合でも適切に機能します。

役割の作成または更新に関する制限

（https://kubernetes.io/zh/docs/reference/access-authn-authz/RBAC/#%E5%AFA2%AFA8%A7%9 2％E8％89％B2％E5％88％9B％E5％BB％BA％E6％88％96％E6％9B％B4％E6％96％B0％E7％9a％84％E9％99％90％E5％88％B6）。

次の条件のいずれかが満たされている場合にのみ、役割を作成/更新できます。

1.既に役割に含まれるすべてのアクセス許可があり、そのスコープはオブジェクトが変更される範囲と同じです。（クラスターロールの場合、それは同じ名前空間または役割のクラスター範囲を意味します）。
2。RBAC.Authorization.K8S.IO APIグループの役割またはClusterRolesリソースにエスカレート動詞を使用することを明示的に許可されています。

たとえば、ユーザー1がクラスター内のすべての秘密の許可を列挙していない場合、その許可を含むクラスターロールを作成することはできません。ユーザーが役割を作成/更新できるようにするには：

1.必要に応じて役割を与え、必要に応じて役割またはクラスターロールオブジェクトを作成/更新できるようにします。

2。作成/更新の役割に特別な権限を含めるための権限を付与します。

・それらを暗黙的に許可します（API要求は、役割またはクラスターロールの許可を作成または変更しようとするが、対応するアクセス許可自体が付与されない場合、API要求は禁止されます）。
・説明承認は、役割またはクラスターロールリソースでエスカレートアクションを実行できるようにすることで完了します。ここの役割とクラスターロールのリソースは、rbac.authorization.k8s.io APIグループに含まれています。

キャラクターのバインディングの作成または更新の制限

（https://kubernetes.io/zh/docs/reference/access-authn-authz/RBAC/#%E5%AFAFAFAB9%E8%A7%92%E8%89%B 2％E7％BB％91％E5％AE％9a％E5％88％9B％E5％BB％BA％E6％88％96％E6％9B％B4％E6％96％B0％E7％9a％84％E9％99％90％E5％88％B6）。

参照される役割に含まれるすべてのアクセス許可が既にある場合、または参照されるロールでバインド動詞を実行する権限がある場合にのみ、ロールバインディングを作成または更新できます。ここでの権限は、役割結合と同じ範囲です。たとえば、ユーザーユーザー1にクラスタースコープ内のすべての秘密を列挙する機能がない場合、許可を付与するためにクラスターロールバインディング参照が参照する役割を作成することはできません。ユーザーがロールバインディングを作成または更新できるようにするには：

1.必要に応じて、ロールバインディングまたはクラスターロールバインディングオブジェクトを作成または更新できるように、役割を提供します。

2.特定の役割をバインドするために必要な権限を許可します。

・暗黙の承認の下で、役割に含まれる許可を付与できます。
・明示的な許可に基づき、特定の役割（またはクラスターロール）でバインド動詞を実行することを許可できます。

たとえば、次のクラスターロールとロールバインディングを使用すると、ユーザー1が名前空間ユーザー1名の役割を他のユーザーに割り当て、編集、および表示することができます。

 apiバージョン: rbac .authorization .k8s .io / v1
 種類: ClusterRole
 メタデータ:
 名前： ロールグランター
ルール:
 - apigroups ：[ "rbac.authorization.k8s.io" ]
 リソース：[ "RoleBindings" ]
 動詞：[ "create" ]
 - apigroups ：[ "rbac.authorization.k8s.io" ]
 リソース：[ "ClusterRoles" ]
 動詞：[ "bind" ]
 ＃ResourceNames を無視するということは、 Clusterroleのバインディングを許可することを意味します
Resourcenames ：[ "admin" 、 "edit" 、 "View" ]
 ---
 apiバージョン: rbac .authorization .k8s .io / v1
 種類: RoleBinding
 メタデータ:
 名前： ロールグランターバインディング
名前空間： user-1-namespace
 ロールリファレンス:
 apiグループ: rbac .authorization .k8s .io
 種類: ClusterRole
 名前： ロールグランター
科目:
 -apigroup ： rbac .authorization .k8s .io
 種類： ユーザー
名前： ユーザー-1

最初の役割と役割のバインディングを起動する場合、最初のユーザーにまだ持っていない権限が付与される必要があります。初期の役割と役割の結合を初期化するときは、次のことが必要です。

・ユーザーグループの資格情報をシステムとして使用します。マスターズ。これは、デフォルトのバインディングによりクラスターアドミンスーパーユーザーの役割に関連付けられています。
・StartupでAPIサーバーが有効になっている場合（-Insecure-Portを使用）、そのポートを介してAPIを呼び出すこともできます。そのような操作は認証または認証をバイパスします。

まとめ

KubernetesのRBACは、特定のユーザーまたはユーザーグループがクラスターまたは特定のクラスター名空間のKubernetesオブジェクトと対話する方法を定義するファイン粒子の特定のアクセス許可セットを構成できるメカニズムです。この記事では、次のことを学びました。

・RBACがより柔軟なモデルを持つユーザーから権限を分離する方法。
・RBACがKubernetes APIと統合する方法。
・ユーザー、サービスアカウント、およびグループを使用して、RBACの主題を特定する方法。
・動詞とAPIグループを使用してリソースをルールにマッピングする方法。
・ルールを役割にグループ化し、これらの役割をロールバインディングを使用してアイデンティティに関連付ける方法。
・役割、ロールバインディング、クラスターロール、クラスターロールバインディングの関係。

参照:

https://cloud.google.com/kubernetes-engine/docs/how-to/role based-access-contol？hl=zh-cn。

https://zh.m.wikipedia.org/zh/%E4%A5%A5%E8%A7%92%E8%89%B2%E7%82%ABA%E5%9FA%E7%A4%8E%E7%9A%84%E5%AD%AD%98%8%8EA28EA5 %8%8Eです。

<<: クラウドネイティブアプリケーションリンク分析の実践を学習しましたか?

>>: Kubernetes 宣言型 API

Kubernetes API

RBAC ロールからユーザーと権限を切り離す

Kubernetes の RBAC

ID の割り当て: ユーザー、グループ、ロボット アカウント

リソースへのアクセスのモデリング

ユーザーに権限を付与する

名前空間とクラスター全体のリソース

ロール、ロールバインディング、クラスターロール、クラスターバインディングを理解する

シナリオ 1: Role と RoleBinding が同じ名前空間にある

シナリオ 2: 異なる名前空間の Roles と RoleBindings

シナリオ 3: ClusterRole を RoleBinding と共に使用する

シナリオ 4: ClusterRole と ClusterRoleBinding を使用してクラスター全体のアクセス権限を付与する

ボーナス＃1：RBACポリシーをより簡潔にする

ボーナス＃2：サービスアカウントを使用したKubernetesアカウントの作成

ボーナス＃3：kubernetesデフォルトの役割

追加＃4：許可のアップグレードの初期化と防止

役割の作成または更新に関する制限

キャラクターのバインディングの作成または更新の制限

まとめ

参照:

推薦する

ID の割り当て: ユーザー、グループ、ロボットアカウント