フリートレベルの認証管理を設定する

このドキュメントでは、クラスタ管理者が フリートを使用して、サードパーティの ID プロバイダからの認証用に複数のクラスタを設定する方法について説明します。 Google Cloud はフリート内のクラスタの構成を管理するため、個々のクラスタを設定するよりも、設定プロセスが簡単になります。サードパーティ プロバイダの認証プロセスの詳細については、サードパーティ ID を使用した認証についてをご覧ください。

始める前に

  1. Google Cloud CLI をインストールして構成します。

    1. Google Cloud CLI をインストールします。

    2. 外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。

    3. gcloud CLI を初期化するには、次のコマンドを実行します: 

      gcloud init

    4. gcloud CLI を初期化した後に更新して、必要なコンポーネントをインストールします。 

      gcloud components update
gcloud components install kubectl
    5. gcloud CLI で、フリート ホスト プロジェクトを選択します。 
      gcloud config set project FLEET_HOST_PROJECT_ID
       FLEET_HOST_PROJECT_ID は、フリート ホスト プロジェクトのプロジェクト ID に置き換えます。

  2. 必要な API を有効にします。

    1. Google Cloud コンソールで、プロジェクトの選択ページに移動します。

      プロジェクト セレクタに移動

    2. フリート ホスト プロジェクトを選択します。

    3. GKE Hub API と Kubernetes Engine API を有効にします。

      API を有効にするために必要なロール

      API を有効にするには、serviceusage.services.enable 権限を含む Service Usage 管理者 IAM ロール（roles/serviceusage.serviceUsageAdmin）が必要です。詳しくは、ロールを付与する方法をご覧ください。

      API を有効にする

  3. 選択したプロトコルに必要なプロバイダ情報がすべてプラットフォーム管理者から提供されていることを確認します。詳細については、次のドキュメントをご覧ください。

必要なロール

フリートレベルでクラスタを設定するために必要な権限を取得するには、フリート ホスト プロジェクトに対するフリート管理者 （roles/gkehub.admin）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

フリートレベルの Identity Service 機能を有効にする

フリートレベルの ID サービス機能は、コントローラを使用してフリート内の各クラスタの構成を管理します。フリートレベルの機能は、フリート ホスト プロジェクトでのみ有効にする必要があります。

フリートレベルの機能を有効にするには、次のいずれかのオプションを選択します。

コンソール

  1. コンソールで、[GKE Identity Service] ページに移動します。 Google Cloud

    GKE Identity Service に移動

  2. [Identity Service を有効にする] をクリックします。

gcloud

フリートレベルの Identity Service 機能を有効にします。

gcloud container fleet identity-service enable

クラスタを構成する

クラスタを構成するには、次の情報を指定する必要があります。

  • クライアント ID やシークレットなどの ID プロバイダに関する情報。
  • ID プロバイダが認証に使用する JSON ウェブトークン（JWT）に関する情報。
  • ID プロバイダに固有の追加のスコープまたはパラメータ。

プラットフォーム管理者または組織の ID 管理者から取得する必要がある情報の詳細については、次のドキュメントをご覧ください。

OIDC プロバイダにクラスタレベルの構成がある場合、クラスタにフリートレベルの構成を適用すると、既存のすべての認証仕様が上書きされます。また、フリートレベルの構成で、サポートされていないプロバイダ用にクラスタレベルの構成が存在する場合、この設定は失敗します。フリートレベルの構成を適用するには、既存のプロバイダ構成を削除する必要があります。

クラスタを構成する手順は次のとおりです。

コンソール

  1. 構成するクラスタを選択します。

    1. Google Cloud コンソールで、[GKE Identity Service] ページに移動します。

      機能マネージャーに移動

    2. 構成するクラスタのチェックボックスを 1 つ以上オンにします。個々のクラスタを選択するか、すべてのクラスタを同じ ID 構成にするように指定できます。フリートレベルのデフォルトを構成している場合、構成はデフォルトに再調整されます。

    3. [構成の更新] をクリックします。[Identity Service クラスタ構成の編集] ペインが開きます。

    4. [ID プロバイダ] セクションで、クラスタの構成方法を選択します。既存の構成を更新したり、別のクラスタから構成をコピーしたり、新しい構成を作成したりできます。新しい構成を作成するには、[ID プロバイダを追加] をクリックします。[新しい ID プロバイダ] セクションが表示されます。

  2. [新しい ID プロバイダ] セクションで、プロバイダの詳細を設定します。

    OIDC

    1. [新しい OpenID Connect] を選択して、新しい OIDC 構成を作成します。
    2. この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。この名前の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。構成を作成した後は、この名前を編集することはできません。
    3. [クライアント ID] フィールドに、ID プロバイダのクライアント ID を指定します。
    4. [クライアント シークレット] フィールドに、クライアント アプリケーションと ID プロバイダの間で共有する必要があるクライアント シークレットを指定します。
    5. [発行元（URL）] には、ID プロバイダに対して認可リクエストを行う URI を指定します。
    6. [次へ] をクリックして、OIDC 属性を設定します。

    Azure AD

    1. [新しい Azure Active Directory] を選択して、新しい Azure AD 構成を作成します。
    2. この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。この名前の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。構成を作成した後は、この名前を編集することはできません。
    3. [クライアント ID] フィールドに、ID プロバイダのクライアント ID を指定します。
    4. [クライアント シークレット] フィールドに、クライアント アプリケーションと ID プロバイダの間で共有する必要があるクライアント シークレットを指定します。
    5. [テナント] に、認証する Azure AD アカウントであるテナントを指定します。
    6. [次へ] をクリックして、Azure AD 属性を設定します。

    LDAP

    1. [LDAP] を選択して、新しい LDAP 構成を作成します。
    2. この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。この名前の先頭は英字で、それに続く最大 39 文字の英小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。構成を作成した後は、この名前を編集することはできません。
    3. [次へ] をクリックします。
    4. ホスト名（必須）、LDAP 接続タイプ、LDAP サーバーの base64 でエンコードされた CA 証明書を指定します。
    5. [次へ] をクリックしてサーバーを構成します。
    6. ユーザーの識別名、フィルタ、ログイン属性、識別子属性を指定します。
    7. [次へ] をクリックして、ユーザーの詳細を設定します。
    8. グループを使用する場合は、グループの識別名、フィルタ、識別子属性を指定します。
    9. [次へ] をクリックして、グループの詳細を設定します。
    10. サービス アカウントのユーザー名とパスワードを指定します。
    11. [完了] をクリックして、サービス アカウント名を設定します。

  3. [次へ] をクリックします。[属性の設定] セクションが開きます。

  4. ID プロバイダの属性を設定します。OIDC または Azure AD の属性を表示するには、次のいずれかのオプションを選択します。

    OIDC

    • kubectl リダイレクト URI: gcloud CLI で使用され、プラットフォーム管理者が登録時に指定したリダイレクト URL とポート（通常は http://localhost:PORT/callback の形式）。
    • 認証局（省略可）: プラットフォーム管理者が指定した場合は、ID プロバイダ用の PEM エンコードの証明書の文字列。
    • グループ クレーム（省略可）: プロバイダがアカウントのセキュリティ グループを返すために使用する JWT クレーム（フィールド名）。
    • グループ接頭辞（省略可）: 複数の ID プロバイダの構成がある場合に、アクセス制御ルールの既存の名前と競合しないように、セキュリティ グループ名に追加する接頭辞（通常はプロバイダ名）。
    • プロキシ（省略可）: ID プロバイダへの接続に使用するプロキシ サーバーのアドレス（該当する場合）。たとえば、クラスタがプライベート ネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に設定する必要があります。例: http://user:password@10.10.10.10:8888。
    • スコープ（省略可）: ID プロバイダが必要とする追加のスコープ。Microsoft Azure と Okta には offline_access スコープが必要です。必要に応じてさらにスコープを追加するには、[スコープを追加] をクリックします。
    • ユーザー クレーム（省略可）: プロバイダがアカウントを識別するために使用する JWT クレーム（フィールド名）。ここに値を指定しない場合、クラスタは「sub」を使用します。これは多くのプロバイダで使用されるユーザー ID クレームです。OpenID プロバイダによっては、email や name などのクレームを選択することもできます。名前が競合しないように、email 以外のクレームには、発行元の URL が先頭に付加されます。
    • ユーザー接頭辞（省略可）: デフォルトの接頭辞を使用しない場合に、既存の名前との競合を避けるために、ユーザー クレームに追加する接頭辞。
    • Extra Params（省略可）: 構成に必要な追加パラメータ。パラメータ Key と Value で指定します。[param を追加] をクリックして、必要に応じてパラメータを追加します。
    • アクセス トークンの有効化（省略可）: 有効にすると、Okta などの OIDC プロバイダのグループをサポートできます。
    • Google Cloud コンソール プロキシをデプロイする（省略可）: 有効にすると、 Google Cloud コンソールを、インターネット経由で一般公開されていないオンプレミスの ID プロバイダに接続できるプロキシがデプロイされます。

    Azure AD

    • kubectl リダイレクト URI: gcloud CLI で使用され、プラットフォーム管理者が登録時に指定したリダイレクト URL とポート（通常は http://localhost:PORT/callback の形式）。
    • ユーザー クレーム（省略可）: プロバイダがアカウントを識別するために使用する JWT クレーム（フィールド名）。ここに値が指定されていない場合、クラスタは、email、preferred_username、sub の値を順に使用してユーザーの詳細情報を取得します。
    • プロキシ（省略可）: ID プロバイダへの接続に使用するプロキシ サーバーのアドレス（該当する場合）。たとえば、クラスタがプライベート ネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に設定する必要があります。例: http://user:password@10.10.10.10:8888。

  5. [完了] をクリックします。

  6. 省略可: 構成にプロバイダを追加するには、[ID プロバイダを追加] をクリックして上記の手順を繰り返します。

  7. [構成の更新] をクリックします。

これにより、必要に応じて必要なコンポーネントがインストールされ、選択したクラスタにクライアント構成が適用されます。

gcloud

gcloud CLI を使用してフリートを構成するには、クラスタが ID プロバイダとやり取りするために必要なすべての情報のフィールドを含む ClientConfig という Kubernetes カスタム リソースを作成します。ClientConfig を作成して使用する手順は次のとおりです。

  1. auth-config.yaml という名前のファイルに ClientConfig 仕様を作成します。OIDC、SAML、LDAP の構成例を表示するには、次のいずれかのオプションを選択します。他の ID プロバイダの構成については、プロバイダ固有の構成をご覧ください。

    OIDC

    次の ClientConfig の例は、oidc 構成と azuread 構成の両方を示しています。oidc または azuread の使用方法の詳細については、プロバイダ固有の構成をご覧ください。

    apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    proxy: PROXY_URL
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
  - name: azure
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_UUID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM

    oidc オブジェクトのフィールドの詳細については、ClientConfig OIDC フィールドをご覧ください。

    SAML

    次の ClientConfig の例は、saml 構成を示しています。

        apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
    metadata:
      name: default
      namespace: kube-public
    spec:
      authentication:
      - name: NAME
        saml:
          idpEntityID: ENTITY_ID
          idpSingleSignOnURI: SIGN_ON_URI
          idpCertificateDataList: IDP_CA_CERT
          userAttribute: USER_ATTRIBUTE
          groupsAttribute: GROUPS_ATTRIBUTE
          userPrefix: USER_PREFIX
          groupPrefix: GROUP_PREFIX
          attributeMapping:
            ATTRIBUTE_KEY_1 : ATTRIBUTE_CEL_EXPRESSION_1
            ATTRIBUTE_KEY_2 : ATTRIBUTE_CEL_EXPRESSION_2
        certificateAuthorityData: CERTIFICATE_STRING
        preferredAuthentication: PREFERRED_AUTHENTICATION
        server: <>

    これらのフィールドの詳細については、ClientConfig SAML フィールドをご覧ください。

    LDAP

    次の ClientConfig の例は、ldap 構成を示しています。

    apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: ldap
    ldap:
      server:
        host: HOST_NAME
        connectionType: CONNECTION_TYPE
        certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      user:
        baseDn: BASE_DN
        loginAttribute: LOGIN_ATTRIBUTE
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE
      group:
        baseDn: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE
      serviceAccount:
        simpleBindCredentials:
          dn: DISTINGUISHED_NAME
          password: PASSWORD

    これらのフィールドの詳細については、ClientConfig LDAP フィールドをご覧ください。

    同じ ClientConfig に複数の ID プロバイダ構成を追加できます。クラスタは、定義された順序で各構成による認証を試行し、認証が最初に成功した時点で停止します。

  2. ClientConfig をクラスタに適用します。

    gcloud container fleet identity-service apply \
    --membership=CLUSTER_NAME \
    --config=auth-config.yaml

    CLUSTER_NAME は、フリート内のクラスタの一意の名前に置き換えます。

クラスタは、必要なコンポーネントをインストールし、作成した ClientConfig を使用します。フリートレベルのコントローラは、クラスタの構成を管理します。クラスタ構成に対するローカルの変更は、コントローラによってフリートレベルの構成に調整されます。

クラスタのバージョンによっては、フリートレベルの構成を適用すると、デフォルトでクラスタに authentication 構成も追加されます。これにより、クラスタは Google ID でログインするユーザー アカウントの Google グループ情報を取得できます。この構成は、Google Distributed Cloud 上のクラスタ（VMware とベアメタルの両方）に適用されます。Google グループ機能の詳細については、Google グループで Connect Gateway を設定するをご覧ください。

フリートレベルのコントローラが構成を管理する必要がなくなった場合（たとえば、別の認証オプションを使用する場合）は、フリートレベルの ID 管理の無効化の手順に沿って、この機能を無効にできます。

プロバイダ固有の構成

このセクションでは、OIDC プロバイダ（Azure AD や Okta など）の構成ガイダンスについて説明します。これには独自の詳細をコピーして編集できる構成例も含まれます。

Azure AD

これは、Azure AD で認証を設定するためのデフォルトの構成です。この構成を使用すると、クラスタで Azure AD からユーザーとグループの情報を取得できます。また、グループに基づいて Kubernetes のロールベース アクセス制御（RBAC）を設定できます。ただし、この構成を使用すると、ユーザーごとに取得できるグループに約 200 個の上限が設定されます。

ユーザーあたり 200 個を超えるグループを取得する必要がある場合は、Azure AD（上級）の手順をご覧ください。

...
spec:
  authentication:
  - name: oidc-azuread
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      extraParams: prompt=consent, access_type=offline
      issuerURI: https://login.microsoftonline.com/TENANT_ID/v2.0
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: openid,email,offline_access
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Azure AD（上級）

Azure AD のこのオプション構成では、ユーザーあたりのグループ数に制限はありません。クラスタで Microsoft Graph API を使用して、ユーザーとグループの情報を取得できます。この構成をサポートするプラットフォームについては、ID プロバイダの設定情報をご覧ください。

ユーザーあたり 200 個未満のグループを取得する必要がある場合は、ClientConfig の oidc アンカーを使用してデフォルト構成を使用することをおすすめします。詳細については、Azure AD の手順をご覧ください。

構成例のすべてのフィールドは必須です。

...
spec:
  authentication:
  - name: azure
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_UUID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

GROUP_FORMAT は、グループ情報を取得する形式に置き換えます。このフィールドには、ユーザー グループの ID または NAME に対応する値を指定できます。この設定は、Google Distributed Cloud（オンプレミス）デプロイのクラスタでのみ使用できます。

Okta

以下では、Okta を ID プロバイダとし、ユーザーとグループの両方を使用して認証を設定する手順について説明します。この構成により、クラスタはアクセス トークンと Okta の userinfo エンドポイントを使用して、ユーザーとグループのクレームを取得します。

...
spec:
  authentication:
  - name: okta
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      enableAccessToken: true
      extraParams: prompt=consent
      groupsClaim: groups
      issuerURI: https://OKTA_ISSUER_URI/
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: offline_access,email,profile,groups
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

フリートレベルのデフォルトを構成する

認証のフリートレベルのデフォルト構成を指定できます。この設定を使用すると、フリートに登録するすべての新しいクラスタで、指定した認証構成が自動的に使用されます。

フリートレベルのデフォルト構成を指定しても、既存のフリート メンバー クラスタは自動的に更新されません。必要に応じて、これらのクラスタにデフォルトの構成を適用できます。フリートレベルの構成の管理の詳細については、フリートレベルで機能を管理するをご覧ください。

フリートレベルのデフォルトを設定すると、フリート コントローラがクラスタをデフォルト構成と調整するときに、個々のクラスタの認証構成に対するローカル変更が上書きされます。

フリートレベルのデフォルト構成を構成する手順は次のとおりです。

  1. fleet-default.yaml という名前のファイルに ClientConfig を作成します。ファイルの作成方法の詳細については、クラスタを構成するセクションの gcloud CLI の手順をご覧ください。

  2. フリートレベルのデフォルト構成を適用するには、次のいずれかのコマンドを実行します。

    • フリートレベルの ID サービス機能が有効になっていない場合は、機能を有効にして、フリートレベルのデフォルト構成を指定します。

      gcloud container fleet identity-service enable --fleet-default-member-config=fleet-default.yaml

    • フリートレベルの ID サービス機能が有効になっている場合は、新しいフリートレベルのデフォルト構成を適用します。

      gcloud container fleet identity-service apply --fleet-default-member-config=default-config.yaml

    フリートに登録する新しいクラスタは、デフォルトでこの構成を使用します。既存のフリート メンバー クラスタは、新しいデフォルト構成を自動的に継承しません。

  3. 既存のフリート メンバー クラスタにデフォルトの構成を適用するには、次のコマンドを実行します。

    gcloud container fleet identity-service apply --origin=fleet --membership=CLUSTER_NAME

フリートレベルのデフォルト構成を削除する

デフォルト構成を削除するには、次のコマンドを実行します。

gcloud container fleet identity-service delete --fleet-default-member-config

フリートに登録した新しいクラスタは、認証構成を自動的に使用しません。

ID サービスの構成を確認する

フリートレベルの設定が完了したら、指定した ID サービス構成でフリート内のクラスタが正常に構成されているかどうかを確認できます。

コンソール

  1. Google Cloud コンソールで、[機能マネージャー] ページに移動します。

    機能マネージャーに移動

    有効な機能は、パネルで [有効] と表示されます。

  2. [Identity Service] パネルで [詳細] をクリックします。詳細パネルに、登録済みクラスタのステータスが表示されます。

gcloud

次のコマンドを実行します。

gcloud container fleet identity-service describe

次のステップ

クラスタを構成したら、ユーザー アクセスを設定するに進みます。