このドキュメントでは、gdcloud CLI を使用して、Google Distributed Cloud(GDC)エアギャップの標準クラスタの権限を管理する方法について説明します。標準クラスタは、プロジェクト スコープの構成可能な Kubernetes 環境です。デフォルトのサービスは最小限に抑えられており、カスタム ワークロードに対してより高い柔軟性と制御を提供します。
標準クラスタと他のクラスタタイプについて詳しくは、Kubernetes クラスタ構成をご覧ください。
このドキュメントは、GDC プロジェクト内のリソースを管理して保護する必要がある、デベロッパー オペレーションやデータ サイエンティストなどのアプリケーション オペレーター グループ内のユーザーを対象としています。詳細については、GDC エアギャップ環境のユーザー向けドキュメントをご覧ください。
始める前に
標準クラスタへのアクセスを管理する前に、必要な権限を取得し、環境を準備する必要があります。
IAM ロールをリクエストする
組織の IAM 管理者に連絡して、実行する必要があるタスクに基づいて次のロールをリクエストします。
- プロジェクト IAM 管理者(
project-iam-admin): プロジェクト内の標準クラスタのロール バインディングを作成、更新、削除します。 - 標準クラスタ管理者(
standard-cluster-admin): 特定の標準クラスタ内でロール バインディングを作成、更新、削除します。
環境を準備する
標準クラスタ アクセスの権限を付与する
プロジェクト IAM 管理者(project-iam-admin)ロールを持つユーザーは、標準クラスタ内のアクセスを管理するために必要なロールを他のユーザーに付与できます。
gdcloud CLI を使用して、構成済みの ID プロバイダでログインします。
プロジェクトに対する標準クラスタ管理者(
standard-cluster-admin)ロールをユーザーに付与します。このコマンドは、ユーザーをロールにバインドし、標準クラスタ内のアクセスを管理できるようにします。ロールの詳細については、事前定義ロールの説明とプロジェクトのロール定義をご覧ください。
gdcloud projects add-iam-policy-binding PROJECT \ --role=ROLE \ --member=user:USER_ACCOUNT次の変数を置き換えます。
PROJECT: 標準クラスタが存在するプロジェクトの名前。ROLE: 付与するロールの名前(standard-cluster-adminなど)。USER_ACCOUNT: ロールを付与するユーザー アカウント。組織に関連付けられた ID プロバイダの接頭辞(idpprefix-user@example.comなど)を含みます。使用される接頭辞は、組織の IdP 構成によって異なります。詳細については、ID プロバイダに接続するをご覧ください。
次の例では、ID プロバイダの接頭辞がプロジェクト
fooのfop-であると仮定して、user@example.comに標準クラスタ管理者ロールを付与します。gdcloud projects add-iam-policy-binding foo \ --role=standard-cluster-admin \ --member=user:fop-user@example.com
標準クラスタ内のアクセスを管理する
標準クラスタ管理者(standard-cluster-admin)ロールを持つユーザーは、標準クラスタ内で次のアクセス権を付与できます。
gdcloud CLI を使用して、構成済みの ID プロバイダでログインします。
--standardフラグを使用して、標準クラスタの kubeconfig ファイルを生成します。標準クラスタをターゲットにするには、このフラグが必要です。export KUBECONFIG=KUBECONFIG_FILE gdcloud clusters get-credentials STANDARD_CLUSTER_NAME --standard --project=PROJECT次の変数を置き換えます。
KUBECONFIG_FILE:standard-cluster-kubeconfig.yamlなどの kubeconfig ファイルのパス。STANDARD_CLUSTER_NAME: Standard クラスタの名前。PROJECT: 標準クラスタが存在するプロジェクトの名前。
kubectlを使用して、標準クラスタ内で権限を定義します。standard-cluster-admin権限を持つユーザーは、カスタムのRoleオブジェクトとClusterRoleオブジェクトを作成できます。これらの権限を付与するには、対応するRolebindingオブジェクトとClusterRoleBindingオブジェクトを作成して、ロールをユーザーやサービス アカウントなどの特定のサブジェクトにバインドします。次の例では、
kubectlを使用して、test名前空間にtest-roleという名前のカスタムRoleのサンプルを作成します。kubectl apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: test-role namespace: test rules: - apiGroups: - "" resources: - configmaps verbs: - get EOF次の例では、
test名前空間にRoleのRoleBinding(test-roleという名前)を作成します。これにより、ID プロバイダの接頭辞fop-を持つユーザー alice@example.com と、defaultNamespace のmy-service-accountという名前のServiceAccountに権限が付与されます。kubectl apply -f - <<EOF apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: test-role-binding namespace: test subjects: - kind: User name: fop-alice@example.com apiGroup: rbac.authorization.k8s.io - kind: ServiceAccount name: my-service-account namespace: default roleRef: kind: Role name: test-role apiGroup: rbac.authorization.k8s.io EOF