標準クラスタへのアクセスを管理する

このドキュメントでは、gdcloud CLI を使用して、Google Distributed Cloud(GDC)エアギャップの標準クラスタの権限を管理する方法について説明します。標準クラスタは、プロジェクト スコープの構成可能な Kubernetes 環境です。デフォルトのサービスは最小限に抑えられており、カスタム ワークロードに対してより高い柔軟性と制御を提供します。

標準クラスタと他のクラスタタイプについて詳しくは、Kubernetes クラスタ構成をご覧ください。

このドキュメントは、GDC プロジェクト内のリソースを管理して保護する必要がある、デベロッパー オペレーションやデータ サイエンティストなどのアプリケーション オペレーター グループ内のユーザーを対象としています。詳細については、GDC エアギャップ環境のユーザー向けドキュメントをご覧ください。

始める前に

標準クラスタへのアクセスを管理する前に、必要な権限を取得し、環境を準備する必要があります。

IAM ロールをリクエストする

組織の IAM 管理者に連絡して、実行する必要があるタスクに基づいて次のロールをリクエストします。

  • プロジェクト IAM 管理者project-iam-admin): プロジェクト内の標準クラスタのロール バインディングを作成、更新、削除します。
  • 標準クラスタ管理者standard-cluster-admin): 特定の標準クラスタ内でロール バインディングを作成、更新、削除します。

環境を準備する

標準クラスタ アクセスの権限を付与する

プロジェクト IAM 管理者(project-iam-admin)ロールを持つユーザーは、標準クラスタ内のアクセスを管理するために必要なロールを他のユーザーに付与できます。

  1. gdcloud CLI を使用して、構成済みの ID プロバイダでログインします。

  2. プロジェクトに対する標準クラスタ管理者(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 プロバイダの接頭辞がプロジェクト foofop- であると仮定して、user@example.com に標準クラスタ管理者ロールを付与します。

    gdcloud projects add-iam-policy-binding foo \
      --role=standard-cluster-admin \
      --member=user:fop-user@example.com
    

標準クラスタ内のアクセスを管理する

標準クラスタ管理者(standard-cluster-admin)ロールを持つユーザーは、標準クラスタ内で次のアクセス権を付与できます。

  1. gdcloud CLI を使用して、構成済みの ID プロバイダでログインします。

  2. --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: 標準クラスタが存在するプロジェクトの名前。
  3. 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 名前空間に RoleRoleBindingtest-role という名前)を作成します。これにより、ID プロバイダの接頭辞 fop- を持つユーザー alice@example.com と、default Namespace の 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