フリートレベルで GKE Identity Service を構成する

このドキュメントは、クラスタで GKE Identity Service を設定するクラスタ管理者またはアプリケーション オペレータを対象としています。任意の OpenID Connect(OIDC)の ID プロバイダを使用して、クラスタに対してフリートレベルで GKE Identity Service を設定する方法について説明します。このドキュメントの手順では、GKE Identity Service がすでにクライアント アプリケーションとして ID プロバイダに登録されていることを前提としています。

GKE Identity Service や他の設定オプションの詳細については、概要をご覧ください。デベロッパーや他のクラスタ ユーザーとしてこのサービスを使用してクラスタにアクセスする方法については、GKE Identity Service を使用したクラスタへのアクセスをご覧ください。

準備

  • 設定を開始する前に、プラットフォーム管理者から、GKE Identity Service の OIDC プロバイダの構成からのすべての情報(GKE Identity Service のクライアント ID やシークレットなど)が提供されていることを確認します。
  • 構成するクラスタが、フリートレベルの設定に関する前提条件を満たしていることを確認します。他のクラスタタイプと環境については、GKE Identity Service の概要をご覧ください。
  • 次のコマンドライン ツールがインストールされていることを確認します。

    • 最新バージョンの Google Cloud CLI、Google Cloud とやり取りするためのコマンドライン ツールである gcloud が含まれています。Google Cloud CLI をインストールする必要がある場合は、インストール ガイドをご覧ください。
    • Kubernetes クラスタに対してコマンドを実行するために使用する kubectlkubectl をインストールする必要がある場合は、インストール ガイドをご覧ください。

    Google Cloud を操作するシェル環境として Cloud Shell を使用する場合は、これらのツールがインストールされます。

  • クラスタが登録されているプロジェクトで使用するために、gcloud CLI が初期化済みであることを確認します。

  • プロジェクト オーナーでない場合、設定ステップを完了するにはクラスタを登録するプロジェクトで GKE Hub 管理者のロールが必要です。

API を有効にする

コンソール

クラスタが登録されているプロジェクトを選択していることを確認します。

  • Enable the GKE Hub and Kubernetes Engine APIs.

    Enable the APIs

gcloud

次のコマンドを実行して、設定に必要な API を有効にします。

gcloud services enable 
gkehub.googleapis.com
container.googleapis.com

クラスタの構成

選択したプロバイダを使用するようにクラスタを構成するには、ID プロバイダの詳細、ユーザー ID として ID プロバイダが提供する JWT トークンの情報、クライアント アプリケーションとして GKE Identity Service を登録する際に提供されたその他の情報を指定する必要があります。

たとえば、プロバイダが(特に)次のフィールドで ID トークンを作成する場合を考えます。ここで、iss は ID プロバイダの URI、sub はユーザーの指定、groupList はユーザーが属するセキュリティ グループのリストです。

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

ユーザー側の設定には次の対応するフィールドがあります。

issueruri: 'https://server.example.com'
username: 'sub'
group: 'groupList'
...

構成の作成に必要な情報のほとんどは、プラットフォーム管理者または組織の ID 管理者から提供されます。 広く使用されている ID プロバイダの構成の例については、プロバイダ固有の構成をご覧ください。

GKE Identity Service では、Google Cloud コンソールから、または Google Cloud CLI を使用することで、この構成を作成または更新できます。

コンソール

GKE Identity Service を有効にする

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

    GKE Enterprise の [機能] に移動

  2. [機能] テーブルの [Identity Service] 行で [有効にする] をクリックし、表示されたペインで [有効にする] を再度クリックします。これにより、フリートのクラスタ内で GKE Identity Service のライフサイクルを管理する新しい GKE Identity Service コントローラ インスタンスが作成されます。

クラスタを選択

  1. [機能] のテーブルに戻り、[Identity Service] 行の [詳細] をクリックして、サービスの詳細ペインを開きます。これには、プロジェクトのクラスタとそのフリートレベルの GKE Identity Service のステータスが表示されます。
  2. [ID サービスを更新する] をクリックして、設定ペインを開きます。
  3. 構成するクラスタを選択します。選択できるのはサポートされているクラスタタイプのみです。個々のクラスタを選択するか、すべてのクラスタを同じ ID 構成にするように指定できます。
  4. [ID プロバイダ] プルダウンで、クラスタの構成方法を選択します。クラスタに既存の GKE Identity Service 構成がある場合は、それを更新することもできます。既存の登録済みクラスタに使用する GKE Identity Service 構成がある場合は、その構成を選択したクラスタにコピーできます。まったく新しい構成を作成するには、次のセクションで説明するように、選択したプロバイダの手順に沿って操作します。

プロバイダの詳細を設定する

追加する必要があるプロバイダの詳細は、構成に使用する ID プロバイダの種類によって異なります。

OIDC

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

Azure AD

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

LDAP

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

属性を設定する

追加する必要がある属性は、ID プロバイダと、GKE Identity Service のプロバイダを構成するときにプラットフォーム管理者が選択する設定オプションによって変わります。

OIDC

  • 構成属性を入力します。

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

Azure AD

  • 構成属性を入力します。

    • kubectl リダイレクト URI: gcloud CLI で使用され、プラットフォーム管理者が登録時に指定するリダイレクト URL とポート(通常は http://localhost:PORT/callback の形式)。
    • プロキシ(省略可): ID プロバイダへの接続に使用するプロキシ サーバーのアドレス(該当する場合)。たとえば、クラスタがプライベート ネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に、これを設定する必要があります。例: http://user:password@10.10.10.10:8888

ID プロバイダを追加

  • フリートで構成する ID プロバイダが他にある場合は、ここでプロバイダを追加できます。手順に沿って、追加の ID プロバイダを指定します。

構成の更新

  • [構成の更新] をクリックします。これにより、必要に応じて GKE Identity Service をインストールし(EKS クラスタのみ、GKE クラスタにはデフォルトで GKE Identity Service がインストールされています)、クライアント構成を選択したクラスタに適用します。

gcloud

構成ファイルを作成する

GKE Identity Service は、ClientConfig という Kubernetes カスタム リソースタイプ(CRD)を使用してクラスタを構成します。ClientConfigには、GKE Identity Service が ID プロバイダとやり取りするために必要なすべての情報のフィールドが含まれています。以下のセクションでは、構成を使用して auth-config.yaml というファイルを作成する OIDC と LDAP の構成について説明します。

OIDC

次のファイルは、oidc 構成と azuread 構成の両方を示しています。oidcazuread を使用するタイミングについて詳しくは、プロバイダ固有の構成をご覧ください。

  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: NAME
      proxy: PROXY_URL
      azureAD:
        clientID: CLIENT_ID
        clientSecret: CLIENT_SECRET
        tenant: TENANT_UUID
        kubectlRedirectURI: http://localhost:PORT/callback

複数の ID プロバイダを構成している場合は、authentication アンカーの下の auth-config.yaml ファイルで、上記の構成と同じ形式で複数の認証構成を一覧表示できます。

次の表に、ClientConfig oidc オブジェクトと azuread オブジェクトのフィールドを示します。ほとんどのフィールドは省略できます。追加する必要があるフィールドは、ID プロバイダと、GKE Identity Service のプロバイダを構成するときにプラットフォーム管理者が選択する設定オプションによって変わります。

フィールド 必須 説明 形式
name この構成を識別するために使用する名前で、通常は ID プロバイダ名です。構成名は、先頭が文字で、その後に最大 39 文字の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません。 文字列
certificateAuthorityData × プラットフォーム管理者が指定した場合は、ID プロバイダ用の PEM でエンコードされた証明書の文字列。結果の文字列は certificateAuthorityData に 1 行で含めます。 文字列
clientID はい プロバイダに GKE Identity Service を登録するときに返されたクライアント ID。 文字列
clientSecret はい プロバイダに GKE Identity Service を登録するときに返されたクライアント シークレット。 文字列
deployCloudConsoleProxy × Google Cloud コンソールを接続できるようにするプロキシを、インターネット経由で一般公開されていないオンプレミスの ID プロバイダにデプロイするかどうかを指定します。デフォルトは false です。 ブール値
extraParams いいえ ID プロバイダに送信する追加の Key=Value パラメータ。カンマ区切りのリストとして指定します(例:「prompt=consent,access_type=offline」)。 カンマ区切りのリスト
enableAccessToken いいえ 有効になっている場合、GKE Identity Service は、ユーザーがコマンドラインからログインしたときに、ID プロバイダの userinfo エンドポイントを使用してグループ情報を取得できます。これにより、このエンドポイントからグループ要求を提供するプロバイダ(Okta など)がある場合、承認にセキュリティ グループを使用できるようになります。設定されていない場合は、false とみなされます。 ブール値
groupsClaim × JWT クレーム(フィールド名)。プロバイダがアカウントのセキュリティ グループを返すために使用します。 文字列
groupPrefix × 複数の ID プロバイダの構成がある場合に、アクセス制御ルールの既存の名前と競合しないように、セキュリティ グループ名に追加する接頭辞(通常はプロバイダ名)。 文字列
issuerURI ID プロバイダに対して認可リクエストを行う URI。URI には HTTPS を使用する必要があります。 URL 文字列
kubectlRedirectURI gcloud CLI で使用され、プラットフォーム管理者が登録時に指定するリダイレクト URL とポート(通常は「http://localhost:PORT/callback」の形式)。 URL 文字列
scopes OpenID プロバイダに送信する追加のスコープ。たとえば、Microsoft Azure と Okta では、offline_access スコープが必要です。 カンマ区切りのリスト
userClaim × プロバイダがユーザー アカウントの識別に使用する JWT クレーム(フィールド名)。ここで値を指定しない場合、GKE Identity Service は「sub」を使用します。これは多くのプロバイダで使用されるユーザー ID クレームです。OpenID プロバイダによっては、「email」や「name」などの他のクレームを選択できます。名前が競合しないように、「email」以外のクレームには、には発行者の URL が先頭に付加されます。 文字列
userPrefix × デフォルトの接頭辞を使用しない場合にユーザーのクレームの先頭に付加する接頭辞。これにより、既存の名前と競合しないようにします。 文字列
テナント はい 認証する Azure AD アカウントの種類。サポートされる値は、テナント ID または特定のテナントに属するアカウントのテナント名です。テナント名はプライマリ ドメインとしても知られています。これらの値を確認する方法について詳しくは、Microsoft Azure AD テナント ID とプライマリ ドメイン名を確認するをご覧ください。 文字列
proxy × ID プロバイダへの接続に使用するプロキシ サーバーのアドレス(該当する場合)。たとえば、クラスタがプライベート ネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に、これを設定する必要があります。例: http://user:password@10.10.10.10:8888 文字列

LDAP

次のファイルは、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 オブジェクトのフィールドを示します。追加する必要があるフィールドは、ID プロバイダと、GKE Identity Service のプロバイダを構成するときにプラットフォーム管理者が選択する設定オプションによって変わります。

フィールド 必須 説明 形式
name この LDAP 構成を識別する名前 文字列
サーバー
host LDAP サーバーのホスト名または IP アドレス。ポートは省略可能であり、指定しない場合のデフォルトは 389 です。たとえば、ldap.server.example.com や、10.10.10.10:389 です。 文字列
connectionType LDAP サーバーへの接続時に使用する LDAP 接続タイプ。starttls または ldaps が指定されている場合、certificateAuthorityData フィールドは空にできません。 文字列
certificateAuthorityData 特定の LDAP 接続タイプで必須 LDAP サーバー用の Base64 エンコードされた PEM 形式の認証局証明書が含まれます。これは、ldaps 接続と startTLS 接続に対してのみ指定する必要があります。 文字列
ユーザー
baseDN ユーザー エントリを検索する LDAP ディレクトリ内のサブツリーの場所。 DN 形式の文字列。
loginAttribute × 入力ユーザー名と照合する属性の名前。LDAP データベースでユーザーを検索するために使用され(例: (<LoginAttribute>=<username>))ます。また、オプションのフィルタ フィールドと組み合わせて使用されます。デフォルトは userPrincipleName です。 文字列
filter × ユーザーの検索時に適用するオプションのフィルタ。これにより、ログインできるユーザー アカウントをさらに制限できます。指定しない場合は、デフォルトで (objectClass=User) になります。 文字列
identifierAttribute × 認証後にユーザーの ID として使用する属性を指定します。これは、ユーザーがユーザー名を使用してログインできるようにする loginAttribute フィールドとは異なりますが、実際の ID がメールアドレスか完全な識別名(DN)になります。たとえば、loginAttributesAMAccountName に、identifierAttribute を userPrincipleName に設定すると、ユーザーは bsmith としてログインできるようになりますが、ユーザーの実際の RBAC ポリシーは bsmith@example.com として記述されます。ユーザーごとに一意になることから、userPrincipleName の使用をおすすめします。指定しない場合は、デフォルトで userPrincipleName になります。 文字列
group(省略可能な項目)
baseDN グループ エントリを検索する LDAP ディレクトリ内のサブツリーの場所。 文字列
filter × ユーザーが所属するグループを検索するときに使用するフィルタ(省略可)。これを使用することで、特定のグループのみを明示的に照合して、各ユーザーから返されるグループの数を減らすことができます。デフォルトは (objectClass=Group) です。 文字列
identifierAttribute × ユーザーが所属する各グループの識別名。たとえば、これが distinguishedName に設定されている場合、RBAC やその他のグループの期待値は完全な DN として記述する必要があります。指定しない場合は、デフォルトで distinguishedName になります。 文字列
serviceAccount/simpleBindCredentials
dn サービス アカウント ユーザーの識別名。 文字列
password サービス アカウント ユーザーのパスワード。 文字列

GKE Identity Service を有効にする

フリートレベルのデフォルト構成で GKE Identity Service を有効にすることもできます。この設定を使用すると、指定した構成が、フリートに登録されているすべての新しいクラスタに自動的に適用されます。 フリートレベルのデフォルト構成の詳細については、フリートレベルのデフォルトを構成するをご覧ください。

プロジェクトの GKE Identity Service を有効にするには、次のコマンドを実行します。

gcloud container fleet identity-service enable

これにより、フリートのクラスタ内で GKE Identity Service のライフサイクルを管理する新しい GKE Service コントローラ インスタンスが作成されます。このコマンドは、プロジェクトごとに 1 回実行すれば、そのプロジェクト フリートに登録されたすべてのサポートされているクラスタで GKE Identity Service を使用できます。

クラスタに構成を適用する

必要に応じて GKE Identity Service をインストールし(EKS クラスタのみ、Anthos クラスタにはデフォルトで GKE Identity Service がインストールされています)、構成をクラスタに適用します。

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

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

クラスタ構成を適用すると、この構成は GKE Identity Service コントローラによって管理され、「信頼できる情報源」とみなされます。GKE Identity Service のクライアント構成にローカルで加えられた変更は、コントローラによってこの設定に指定された構成に戻されます。

認証オプションに関する既存の構成がクラスタに存在する場合、以下が適用されます。

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

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

プロバイダ特有の構成

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

Azure AD

これは、Azure AD で GKE Identity Service を設定するためのデフォルトの構成です。この構成を使用すると、GKE Identity Service で Azure AD からユーザーとグループの情報を取得できます。また、グループに基づいて Kubernetes のロールベース アクセス制御(RBAC)を設定できます。ただし、この構成を使用することによって、ユーザーごとに取得できるグループに対して約 200 個の上限が設けられます。

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

...
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(Advanced)

Azure AD のこのオプション構成では、ユーザーあたりのグループ数に制限なく、GKE Identity Service で Microsoft Graph API を使用してユーザーとグループの情報を取得できます。この構成をサポートするプラットフォームについては、Azure AD の詳細設定に関するページをご覧ください。

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

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

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

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

Okta

Okta を ID プロバイダとし、ユーザーとグループの両方を使用して認証を設定する手順は次のとおりです。この構成により、GKE Identity Service はアクセス トークンと 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.
...

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

フリートレベルのデフォルト構成で GKE Identity Service を有効にできます。この設定を使用すると、クラスタ作成時に登録された Google Cloud クラスタの新しい GKE または Anthos クラスタではすべて、指定した構成のクラスタで GKE Identity Service が有効になります。フリートレベルの構成の管理の詳細については、フリートレベルの機能の管理をご覧ください。

フリートレベルのデフォルト構成で GKE Identity Service を構成するには、次の手順を行います。

  1. fleet-default.yaml という名前のファイルを作成し、構成ファイルの作成に従って入力します。

  2. フリートレベルのデフォルト構成で GKE Identity Service を有効にします。

    gcloud container fleet identity-service enable --fleet-default-member-config=fleet-default.yaml
  3. 既存のフリートレベルのデフォルト構成を変更するには、またはフリートレベルのデフォルト構成なしでフリートで GKE Identity Service がすでに有効になっている場合に追加するには、次のコマンドを実行します。

    gcloud container fleet identity-service apply --fleet-default-member-config=default-config.yaml
  4. フリートレベルのデフォルト構成が構成される前に登録されたクラスタは、デフォルト構成を自動的に継承しません。このクラスのクラスタに属するクラスタにデフォルト構成を適用する場合は、次のコマンドを実行します。

    gcloud container fleet identity-service apply --origin=fleet --membership=CLUSTER_NAME
  5. フリートレベルのデフォルト構成を削除するには、次のコマンドを実行します。

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

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

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

コンソール

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

    GKE Enterprise の機能の管理に移動

    有効なすべての機能は、[機能] リストで [有効] として表示されます。

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

gcloud

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

gcloud container fleet identity-service describe

ユーザー アクセスを設定する

クラスタを構成したら、ユーザー アクセスの設定を続行します。

フリートレベルの GKE Identity Service 管理を無効にする

Google Cloud で GKE Identity Service の構成とライフサイクルを管理する必要がなくなった場合は、この機能を無効にできます。 フリートレベルの管理を無効にしても、GKE Identity Service や認証構成はクラスタから削除されないため、ユーザーは構成済みのサードパーティ ID プロバイダを使用して、引き続きクラスタに対する認証を行えます。ただし、クラスタ上で GKE Identity Service の構成やリソースを手動で編集した場合、そうした変更が信頼できる唯一の情報源に対応する状態に調整されることはありません。

クラスタのフリートレベルの管理を無効にする

クラスタのフリートレベルの管理を無効にするには、次のコマンドを実行します。

gcloud container fleet identity-service delete --membership=CLUSTER_NAME

ここで、CLUSTER_NAME は、フリート内のクラスタの一意の名前です。

フリートのフリートレベル管理を無効にする

フリートに対するフリートレベルの GKE Identity Service 管理は、次のようにして無効にします。

コンソール

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

    GKE Enterprise の [機能] に移動

  2. [機能] の表で、[Identity Service] 行の [詳細] をクリックして、表示されたペインの [GKE Identity Service を無効にする] をクリックします。

gcloud

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

gcloud container fleet identity-service disable

フリート機能を無効にすると、Google Cloud コンソールまたは gcloud によるクラスタの GKE Identity Service の状態の表示や更新ができなくなります。

トラブルシューティング

この設定中に問題が発生した場合は、トラブルシューティング ガイドをご覧ください。