Google Cloud プロジェクトを作成した時点で、プロジェクトに参加しているのは作成したそのユーザーのみです。デフォルトの場合、他のユーザーはプロジェクトや Google Kubernetes Engine(GKE)などのリソースにアクセスできません。GKE では、ロールベースのアクセス制御(RBAC)を使用して、プロジェクトとクラスタ内のリソースへのアクセス権を管理する複数のオプションをサポートしています。
こうしたメカニズムは機能的に重複していますが、さまざまな種類のリソースを対象としています。それぞれについて、以下のセクションで簡単に説明します。
Kubernetes RBAC は、Kubernetes に組み込まれており、Kubernetes クラスタ内のオブジェクトに詳細な権限を付与します。権限は、クラスタ内に ClusterRole オブジェクトまたは Role オブジェクトとして存在します。RoleBinding オブジェクトは、Kubernetes ユーザー、Google Cloud ユーザー、IAM サービス アカウント、または Google グループにロールを付与します。
主に GKE を使用していて、クラスタ内のすべてのオブジェクトとオペレーションに対してきめ細かいアクセス許可が必要な場合は、Kubernetes RBAC が最善の選択です。
IAM は、クラスタを含む Google Cloud リソース、クラスタ内のオブジェクトのタイプを管理します。権限は IAM のプリンシパルに割り当てられます。
IAM 内の特定の Kubernetes オブジェクトに権限を付与するメカニズムはありません。たとえば、CustomResourceDefinition(CRD)を作成するユーザー権限を付与することはできますが、特定の CustomResourceDefinition を 1 つのみの作成や、プロジェクト内の特定の Namespace や特定のクラスタに対してのみ作成できるようにする限定のユーザー権限は付与できません。ロールがフォルダレベルで適用される場合、IAM のロールはプロジェクト内のすべてのクラスタ、またはすべての子プロジェクト内の全クラスタに対して権限を付与します。
複数の Google Cloud コンポーネントを使用していて、Kubernetes 固有のきめ細かい権限を管理する必要がない場合は、IAM が最適です。
Kubernetes RBAC
Kubernetes には RBAC のサポートが組み込まれているため、Kubernetes クラスタ内できめ細かい役割を作成できます。Role では、特定の Kubernetes オブジェクトや Kubernetes オブジェクト タイプにスコープを設定し、そのオブジェクトに関連して Role が許可するアクション(動詞)を定義できます。RoleBinding は Kubernetes オブジェクトでもあり、ロールをユーザーに付与します。GKE ユーザーは以下のいずれかになります。
- Google Cloud ユーザー
- IAM サービス アカウント
- Kubernetes ServiceAccount
- Google Workspace ユーザー
- Google Workspace Google グループ
- X509 クライアント証明書を使用して認証されたユーザー
詳細については、ロールベースのアクセス制御をご覧ください。
IAM
IAM では、プリンシパルにロールを付与できます。ロールは権限の集合体であり、ロールをプリンシパルに付与することで、1 つ以上の Google Cloud リソースへのアクセス権を制御できます。次のタイプのロールを使用できます。
- 基本ロールは、オーナー、編集者、閲覧者に限定された大まかな権限を提供します。
- 事前定義ロール(GKE 用に事前定義されたロールなど)は、基本ロールよりもきめ細かいアクセス権限を提供し、一般的な多くのユースケースに対応します。
- カスタムロールを使用すると、権限を独自に組み合わせて作成できます。
プリンシパルは次のいずれかです。
- ユーザー アカウント
- サービス アカウント
- Google Workspace Google グループ
- Google Workspace ドメイン
- Cloud Identity ドメイン
IAM ポリシーのタイプ
IAM は、次のポリシータイプをサポートしています。
- 許可ポリシー: プリンシパルにロールを付与します。詳しくは、許可ポリシーをご覧ください。
- 拒否ポリシー: プリンシパルが付与されているロールに関係なく、プリンシパルが特定の IAM 権限を使用できないようにします。詳細については、拒否ポリシーをご覧ください。
IAM 許可ポリシーで関連する権限を含むロールをプリンシパルに付与している場合でも、拒否ポリシーを使用すると、特定のプリンシパルがプロジェクト、フォルダ、組織で特定のアクションを実行できないように制限できます。
IAM の推奨事項
次の IAM 事前定義ロールを使用して、一般的なシナリオを促進することを検討してください。
- Kubernetes Engine クラスタ閲覧者(
roles/container.clusterViewer
): クラスタに接続することだけが必要な DevOps、エンジニア、アプリケーション デベロッパー。 - Kubernetes Engine クラスタ管理者(
roles/container.clusterAdmin
): Google Cloud プロジェクトで 1 つ以上のクラスタを管理する必要があるプラットフォーム管理者とクラスタ オペレーター。
使用可能な IAM 事前定義ロールの一覧については、GKE の事前定義ロールをご覧ください。
また、Compute Engine のデフォルトのサービス アカウントの代わりに、ノードで使用するカスタム IAM サービス アカウントを作成することも検討してください。カスタム サービス アカウントには、GKE が機能するために必要な最小限の権限を付与します。手順については、最小権限の IAM サービス アカウントを使用するをご覧ください。
IAM と Kubernetes RBAC の連携
IAM と Kubernetes RBAC は連携して、クラスタへのアクセスを管理します。IAM はプロジェクト レベルでアクセスを制御するのに対し、RBAC はクラスタレベルと名前空間レベルでアクセスを制御します。エンティティには、いずれのレベルでも、クラスタ内のリソースを操作するための十分な権限が必要です。
次のステップ
- GKE セキュリティの概要を確認する。
- Kubernetes RBAC を使用する方法を学ぶ。
- GKE の IAM ポリシーを作成する方法を学ぶ。
- ロードバランサの IAM Conditions を使用する方法を学ぶ。