Kubernetes RBAC とは何ですか?なぜそれが必要なのですか?

翻訳者 |李睿

レビュー |チョンロウ

Kubernetes RBAC とは何ですか?

組織が Kubernetes の導入を開始するときは通常、インフラストラクチャを保護するために最小限の権限ロールと適切な承認を実装する必要があります。ここで、Kubernetes RBAC が役立ち、デプロイメントの詳細、永続的なストレージ設定、シークレットなどの機密データなどの Kubernetes リソースを保護します。 Kubernetes RBAC は、各 API リソースにアクセスできるユーザーとその方法を制御する機能を提供します。組織は、人間のユーザー (個人またはグループ) と人間以外のユーザー (サービスアカウント) の両方に対して RBAC を使用して、さまざまな Kubernetes リソースへのアクセスの種類を定義できます。

たとえば、開発、ステージング、本番環境という 3 つの異なる環境があり、開発者、DevOps 担当者、SRE、アプリケーション所有者、製品マネージャーなどのチームにこれらの環境へのアクセスを提供する必要があります。

始める前に、抽象的な観点から、ユーザーとサービスアカウントは同じように扱われることを強調することが重要です。つまり、ユーザーからであろうとサービスアカウントからであろうと、すべてのリクエストは最終的には HTTP リクエストです。 Kubernetes のユーザーとサービスアカウント (人間以外のユーザー用) は根本的に異なることが知られています。

Kubernetes RBAC を有効にする方法

認証モードフラグを使用して API サーバーを起動すると、Kubernetes で RBAC を有効にすることができます。ユーザーに RBAC を適用するために使用される Kubernetes リソースは次のとおりです。

役割
クラスターロール
ロールバインディング
クラスターロールバインディング

1. サービスアカウント

ユーザーを管理するために、Kubernetes は認証メカニズムを提供しますが、一般的には、Kubernetes を Active Directory や LDAP などのエンタープライズユーザー ID 管理と統合することが推奨されます。 Kubernetes クラスター内の人間以外のユーザー (またはマシンやサービス) に関しては、サービスアカウントの概念が関係してきます。

たとえば、アプリケーションをデプロイするには、Spinnaker や Argo などの継続的デリバリー (CD)アプリケーションから Kubernetes リソースにアクセスする必要があります。また、サービス A の 1 つのポッドがサービス B の別のポッドと通信する必要があります。この場合、サービスアカウントを使用して、人間以外のユーザーのアカウントを作成し、必要な承認を指定します (ロールバインディングまたはクラスターロールバインディングを使用)。

次のような yaml を作成することでサービスアカウントを作成できます。

 YAML apiVersion: v1 kind: ServiceAccount metadata: name: nginx-sa spec: automountServiceAccountToken: false

それからそれを適用します。

 Shell $ kubectl apply -f nginx-sa.yaml serviceaccount/nginx-sa created

ここで、デプロイメントリソース内のポッドにサービスアカウントを提供する必要があります。

 YAML kind: Deployment metadata: name: nginx1 labels: app: nginx1 spec: replicas: 2 selector: matchLabels: app: nginx1 template: metadata: labels: app: nginx1 spec: serviceAccountName: nginx-sa containers: - name: nginx1 image: nginx ports: - containerPort: 80

デプロイメントリソースでサービスアカウント名 (serviceAccountName) を指定しない場合、ポッドはデフォルトのサービスアカウントに属します。各名前空間にはデフォルトのサービスアカウントがあり、クラスターにもデフォルトのサービスアカウントがあることに注意することが重要です。デフォルトのサービスアカウントのすべてのデフォルトの承認ポリシーは、サービスアカウント情報が指定されていないポッドに適用されます。

以下では、ロールバインディングとクラスターロールバインディングを使用して、サービスアカウントにさまざまな権限を割り当てる方法を説明します。

2. ロールとクラスターロール

Role と ClusterRole は、それぞれユーザーが名前空間またはクラスター内で実行できる操作のリストを定義する Kubernetes リソースです。

Kubernetes では、アクター (ユーザー、グループ、サービスアカウントなど) はサブジェクトと呼ばれます。作成、読み取り、書き込み、更新、削除などのサブジェクトのアクションは、操作と呼ばれます。

 YAML apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: read-only namespace: dev-namespace rules: - apiGroups: - "" resources: ["*"] verbs: - get - list - watch

上記のロールリソースでは、読み取り専用ロールが deb-ns 名前空間と名前空間内のすべてのリソースにのみ適用されるように指定されています。読み取り専用ロールにバインドされたすべてのサービスアカウントまたはユーザーは、取得、一覧表示、監視などの操作を実行できます。

同様に、クラスターロール (リソースにより、クラスターに関連するロールの作成が可能になります) 。次に例を示します。

 YAML apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: chief-role rules: - apiGroups: - "" resources: ["*"] verbs: - get - list - watch - create - update - patch - delete

chief-role にバインドされたユーザー/グループ/サービスアカウントは、クラスター内で任意のアクションを実行できます。

次のセクションでは、ロールバインディングとクラスターロールバインディングを使用してトピックにロールを付与する方法について説明します。

さらに、Kubernetes では、Role リソースを使用してカスタムロールを構成したり、次に示すようにデフォルトのユーザー指向のロールを使用したりできます。

クラスター-管理者: クラスター管理者に対して、Kubernetes はスーパーユーザーロールを提供します。クラスター管理者は、クラスター内の任意のリソースに対して任意の操作を実行できます。クラスターロールバインディングでスーパーユーザーを使用すると、クラスター内のすべてのリソース (およびすべての名前空間) に対する完全な制御を付与できます。また、ロールバインディングでスーパーユーザーを使用すると、それぞれの名前空間内のすべてのリソースに対する完全な制御を付与できます。
管理者: Kubernetes は、名前空間内のリソースへの無制限の読み取り/書き込みアクセスを許可する管理者ロールを提供します。管理者ロールは、特定の名前空間内でロールとロールバインディングを作成できます。名前空間自体への書き込みアクセスは許可されません。これは、キャラクターリグのアセットで使用できます。
編集: 編集ロールは、指定された Kubernetes 名前空間内での読み取り/書き込みアクセスを許可します。ロールまたはロールバインディングを表示または変更することはできません。
ビュー: ビューロールは、指定された名前空間内での読み取り専用アクセスを許可します。ロールまたはロールバインディングを表示または変更することはできません。

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

サブジェクト (ユーザー/グループ/サービスアカウント) にロールを適用するには、ロールバインディングを定義する必要があります。これにより、ロール構成で定義された権限を使用して、名前空間内の必要なリソースへの最小限の権限アクセスがユーザーに提供されます。

 YAML apiVersion: rbac.authorization.k8s.io/v1beta1 kind: RoleBinding metadata: name: Role-binding-dev roleRef: kind: Role name: read-only #The role name you defined in the Role configuration apiGroup: rbac.authorization.k8s.io subjects: - kind: User name: Roy #The name of the user to give the role to apiGroup: rbac.authorization.k8s.io - kind: ServiceAccount name: nginx-sa#The name of the ServiceAccount to give the role to apiGroup: rbac.authorization.k8s.io

同様に、クラスターロールバインディングリソースを作成して、ユーザーのロールを定義することもできます。カスタムロールの代わりに、Kubernetes によって提供されるデフォルトのスーパーユーザークラスターロール参照が使用されることに注意することが重要です。これはクラスター管理者が使用できます。

 YAML apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: superuser-binding roleRef: kind: ClusterRole name: superuser apiGroup: rbac.authorization.k8s.io subjects: - kind: User name: Aditi apiGroup: rbac.authorization.k8s.io

Kubernetes RBAC の利点

Kubernetes RBAC の利点は、クラスター内のさまざまなユーザーとマシンに対して最小権限を「ネイティブ」に実装できることです。主な利点は次のとおりです。

1. 適切な承認

さまざまなユーザーやサービスアカウントにKubernetes リソースへの最小限の権限を付与することは、DevOps とアーキテクトがゼロトラストを実装するために使用できる主要な柱の 1 つです。組織は、データ侵害やデータ漏洩のリスクを軽減できるだけでなく、社内従業員による重要なリソースの誤った削除や操作も回避できます。

2. 職務の分離

Kubernetes リソースに RBAC を適用すると、組織内のユーザー (開発者、DevOps、テスター、SRE など) の職務の分離に常に役立ちます。たとえば、開発環境で新しいリソースを作成/削除する場合、開発者は管理者に依存すべきではありません。同様に、新しいアプリケーションをテストサーバーにデプロイし、テスト後にポッドを削除することは、DevOps やテスターにとってボトルネックになってはなりません。ユーザー (開発者や CI/CD デプロイメントエージェントなど) に独自のワークスペース (名前空間やクラスターなど) への承認と権限を適用すると、依存関係が減り、余裕が減ります。

3.規制への100%の遵守

多くの業界規制 (HIPAA、GDPR、SOX など) では、ソフトウェア分野で厳格な認証および承認メカニズムが求められています。 Kubernetes RBAC を使用すると、DevOps とアーキテクトは Kubernetes クラスターに RBAC を迅速に実装し、これらの標準に準拠するようにセットアップを改善できます。