CKA 試験に合格する可能性を高めます。この記事では、RBAC 権限制御について包括的に理解できます。

1. RBAC の概要

RBAC では、4 つの新しいトップレベル リソース オブジェクトが導入されています。ロール、ClusterRole、RoleBinding、ClusterRoleBinding。他の API リソース オブジェクトと同様に、ユーザーは kubectl または API 呼び出しを使用してこれらのリソース オブジェクトを操作できます。 Kubernetes クラスターに関連するすべてのやり取りは、apiserver を通じて完了します。このような集中管理型システムの場合、バージョン 1.6 以降、K8S は RBAC アクセス制御ポリシーをデフォルトで有効にします。現在、RBAC は安定した機能となっています。起動ファイル kube-apiserver.service で -authorization-mode=RBAC を設定して RABC を有効にします。 RBAC API では、次の手順で認証が実行されます。

• 「ロールの定義」: ロールを定義するときに、このロールのリソース アクセス制御のルールが指定されます。
• 「ロールをバインド」: サブジェクトをロールにバインドし、ユーザーにアクセスを許可します。

RBAC リソース オブジェクト

Kubernetes では、RBAC はクラスター リソースへのアクセス許可を管理するための強力なアクセス制御メカニズムです。 RBAC を使用すると、管理者は Kubernetes API のリソースに対してユーザー、ServiceAccounts、またはその他のエンティティが持つ権限を正確に制御できます。 RBAC ロールベースの承認モデルを使用すると、管理者はロールとロール バインディングを定義して、さまざまなユーザーまたはエンティティのアクセス権を制御できます。 RBAC は 4 つの基本概念で構成されています。

• 「ロール」: ロールは、名前空間内のリソースの読み取り、作成、削除などの一連の操作権限を定義します。
• 「RoleBinding」: ロール バインディングは、ユーザー、グループ、または ServiceAccount に特定のロールを付与し、それによって対応する権限を付与します。
• ClusterRole: ロールに似ていますが、範囲が広く、クラスター全体のリソースを操作する権限を付与できます。
• ClusterRoleBinding: クラスター ロールをユーザー、グループ、または ServiceAccount にバインドして、クラスター全体の権限を付与します。

3. 役割

ロールは権限の集合です。ここでのすべての権限は許可の形式であり、「拒否ルールはありません。」ロールは常に名前空間内のアクセス権限を設定するために使用されます。ロールを作成するときは、そのロールが属する名前空間を指定する必要があります。対照的に、ClusterRole はクラスター スコープのリソースです。 Kubernetes オブジェクトは名前空間スコープまたはクラスター スコープのいずれかであり、両方ではないため、2 つのリソースの名前は異なります (Role と ClusterRole)。 ClusterRole にはいくつかの用途があります。以下の用途に使用できます:

• 名前空間ドメイン内のオブジェクトへのアクセス権を定義し、個々の名前空間内でアクセス権を付与します。
• 名前空間スコープのオブジェクトに対するアクセス権限を設定し、すべての名前空間にわたってアクセス権限を付与します。
• クラスタースコープのリソースに対するアクセス権限を定義します。

名前空間内でロールを定義する場合は、Role を使用する必要があります。クラスター全体のロールを定義する場合は、ClusterRole を使用する必要があります。

1. 役割の例

（１）コマンドで作成

コマンド方法を忘れた場合は、次に示すように、kubectl create role --help を使用してヘルプを表示することもできます。

ヘルプ

kubectl create role pod-reader \ --verb=get,list,watch \ --resource=pods

• 動詞: get、list、watch など、このロールに含まれる操作を指定します。
• リソース: このロールが操作できるリソースオブジェクト（ポッドなど）を指します。
• resource-name: 特定のリソース インスタンスに対するアクセス権限を指定します。

（２）リソースリストを使って作成する

以下は、Pod への読み取りアクセスを許可するために使用できる、デフォルトの名前空間内のロールの例です。

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

2. ClusterRoleの例

ClusterRole は、Role が付与できる権限を付与するためにも使用できます。 ClusterRole はクラスター全体にわたるため、次のリソースへのアクセスも許可できます。

• クラスター全体のリソース（ノードなど）
• 非リソースエンドポイント (/healthz など)
• 名前空間を越えてアクセスされる名前空間スコープのリソース（Pod など）

たとえば、ClusterRole を使用して、特定のユーザーが kubectl get pods --all-namespaces を実行できるようにすることができます。以下は、特定の名前空間内の Secret への読み取りアクセス、または名前空間間のアクセス (ロールのバインド方法によって異なります) を許可するために使用できる ClusterRole の例です。

コマンドラインの作成:

 kubectl create clusterrole secret-reader \ --verb=get,watch,list \ --resource=secrets

リソース リストの作成:

 apiVersion:rbac.authorization.k8s.io/v1 kind:ClusterRole metadata: # "namespace" 被忽略，因为ClusterRoles 不受名字空间限制name:secret-reader rules: -apiGroups:[""] # 在HTTP 层面，用来访问Secret 资源的名称为"secrets" resources:["secrets"] verbs:["get","watch","list"]

3. ロールバインディングとクラスターロールバインディング

ロール バインディングは、ロールで定義された権限を 1 人またはユーザー グループに付与することです。これには、いくつかの「サブジェクト」(ユーザー、グループ、またはサービス アカウント) のリストと、これらのサブジェクトに付与されたロールへの参照が含まれています。 RoleBinding は特定の名前空間で認証を実行しますが、ClusterRoleBinding はクラスター全体で認証を実行します。 RoleBinding は、同じ名前空間内の任意の Role を参照できます。あるいは、RoleBinding は ClusterRole を参照し、その ClusterRole を RoleBinding が存在する名前空間にバインドすることもできます。 ClusterRole をクラスター内のすべての名前空間にバインドする場合は、ClusterRoleBinding を使用する必要があります。

ロールバインディングの例

次の例の RoleBinding は、デフォルトの名前空間でユーザー jane に pod-reader Role を付与します。このようにして、ユーザー jane には、デフォルトの名前空間内のすべての Pod を読み取る権限が与えられます。

コマンドラインの作成:

 kubectl create rolebinding read-pods \ --role=pod-reader \ --user=jance \ --namespace=default

詳細については、ヘルプ ファイル kubectl create rolebinding --help を使用してください。

リソース リストの作成:

 apiVersion:rbac.authorization.k8s.io/v1 # 此角色绑定允许"jane" 读取"default" 名字空间中的Pod # 你需要在该名字空间中有一个名为“pod-reader” 的Role kind:RoleBinding metadata: name:read-pods namespace:default subjects: # 你可以指定不止一个“subject（主体）” -kind:User name:jane# "name" 是区分大小写的apiGroup:rbac.authorization.k8s.io roleRef: # "roleRef" 指定与某Role 或ClusterRole 的绑定关系kind:Role# 此字段必须是Role 或ClusterRole name:pod-reader# 此字段必须与你要绑定的Role 或ClusterRole 的名称匹配apiGroup:rbac.authorization.k8s.io

4. ClusterRoleBinding の例

クラスター全体にアクセス権限を付与するには、ClusterRoleBinding を使用できます。次の ClusterRoleBinding は、マネージャー グループ内のすべてのユーザーが任意の名前空間の Secrets にアクセスできるようにします。

コマンドラインの作成:

 kubectl create clusterrolebinding read-secrets-global\ --group=manager \ --clusterrole=secret-reader

リソース リストの作成:

 apiVersion:rbac.authorization.k8s.io/v1 # 此集群角色绑定允许“manager” 组中的任何人访问任何名字空间中的Secret 资源kind:ClusterRoleBinding metadata: name:read-secrets-global subjects: -kind:Group name:manager# 'name' 是区分大小写的apiGroup:rbac.authorization.k8s.io roleRef: kind:ClusterRole name:secret-reader apiGroup:rbac.authorization.k8s.io

5. リソース

Kubernetes API では、ほとんどのリソースはオブジェクト名の文字列表現を使用して表示およびアクセスされます。たとえば、Pod の場合は pods を使用します。 RBAC は、対応する API エンドポイントの URL に表示されている名前を使用してリソースを参照します。一部の Kubernetes API には、Pod ログなどのサブリソースが含まれます。 Pod ログのリクエストは次のようになります。

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

ここで、pods は名前空間スコープの Pod リソースに対応し、log は pods のサブリソースです。 RBAC ロールがサブリソースを表す場合、リソースとサブリソースを区切るためにスラッシュ (/) が使用されます。サブジェクトがポッドを読み取り、それらのポッドのログ サブリソースにアクセスできるようにするには、次のように記述します。

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

一部のリクエストでは、resourceNames リストを介してリソースを名前で参照することもできます。指定すると、リクエストの範囲をリソースの単一インスタンスに限定できます。次の例では、my-configmap という名前の ConfigMap へのアクセスと更新を制限します。

コマンドラインの作成:

 kubectl create role configmap-updater \ --verb=update,get \ --resource=configmaps \ --resource-name=my-configmap

リソース リストの作成:

 apiVersion:rbac.authorization.k8s.io/v1 kind:Role metadata: namespace:default name:configmap-updater rules: -apiGroups:[""] # 在HTTP 层面，用来访问ConfigMap 资源的名称为"configmaps" resources:["configmaps"] resourceNames:["my-configmap"] verbs:["update","get"]

6. 主題

RoleBinding または ClusterRoleBinding は、ロールを「Subject」にバインドできます。プリンシパルは、グループ、ユーザー、またはサービス アカウントにすることができます。 K8s ユーザーには、通常のユーザーと ServiceAccounts の 2 種類があります。

1. 一般ユーザー

通常のユーザーは、外部または独立したサービスによって管理されると想定されます。管理者は秘密鍵を割り当てます。よく使用される kubectl コマンドは、通常、一般ユーザーによって実行されます。ユーザーに権限が必要な場合、ユーザーが使用できるように、ロールがユーザー (またはグループ) にバインドされます (そのためには、ユーザー/グループを作成する必要があります)。

2. サービスアカウント

ServiceAccount は、Kubernetes API によって管理されるユーザーです。これらは特定の名前空間にバインドされており、API サーバーによって自動的に作成されるか、API 呼び出しによって手動で作成されます。

サービス アカウントは、シークレットとして保存される一連の資格情報に関連付けられており、これらの資格情報は、クラスター プロセスが Kubernetes API と通信できるようにポッドにマウントされます。 （ダッシュボードにログインする際はServiceAccountを使用します）

プログラムに権限が必要な場合は、プログラムで使用するためのロールと ServiceAccount を指定します (これには、ServiceAccount を作成し、展開で ServiceAccount を指定する必要があります)。

次の例は RoleBinding からのスニペットであり、subjects 部分のみを示しています。

[email protected] という名前のユーザーの場合:

 subjects: -kind:User name:"[email protected]" apiGroup:rbac.authorization.k8s.io

frontend-admins という名前のユーザー グループの場合:

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

任意の名前空間のサービス アカウントの場合:

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

7. CKAの実際の質問

CKAの実際の質問

• 「コンテキスト:」デプロイメント パイプラインの新しい ClusterRole を作成し、特定の名前空間にスコープ設定された特定の ServiceAccount にバインドします。
• 「タスク:」 「Deployment、Daemonset、Statefulset」にのみ「create」権限を許可する「deployment-clusterrole」という名前の clusterrole を作成し、既存の名前空間 app-team1 に「cicd-token」という名前の新しい ServiceAccount を作成します。
• 名前空間 app-team1 に「限定」し、新しい ClusterRole の deployment-clusterrole を新しい ServiceAccount の cicd-token にバインドします。

この質問は、RBAC 承認モデルに関する理解度をテストします。 RBAC に関する情報については、公式 Web サイトのドキュメントを参照するか、-h help を使用してください。

 #考试时务必执行，切换集群。 kubectl config use-context k8s #创建一个名称为deployment-clusterrole的clusterrole kubectl create clusterrole deployment-clusterrole \ -verb=create -resource=deployments,daemonsets,statefulsets #在命名空间app-team1创建一个名为cicd-token kubectl create sa cicd-token -n app-team1 #题目中写了“限于namespace app-team1 中”，则创建rolebinding。没有写的话，则创建clusterrolebinding。 kubectl create rolebinding cicd-token-rolebinding \ --clusterrole=clusterrole --serviceaccount=app-team1:cicd-token --namespace=app-team1 # rolebinding 后面的名字cicd-token-rolebinding 随便起的，因为题目中没有要求，如果题目中有要求，就不能随便起了。

次のコマンドで確認できます。

 kubectl -n app-team1 describe rolebindings cicd-token-rolebinding

次の図は、証明書が正常に作成されたことを示しています。