フリートレベルで 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 クラスタに対してコマンドを実行するために使用する
kubectl
。kubectl
をインストールする必要がある場合は、インストール ガイドをご覧ください。
Google Cloud を操作するシェル環境として Cloud Shell を使用する場合は、これらのツールがインストールされます。
- 最新バージョンの Google Cloud CLI、Google Cloud とやり取りするためのコマンドライン ツールである
クラスタが登録されているプロジェクトで使用するために、gcloud CLI が初期化済みであることを確認します。
プロジェクト オーナーでない場合、設定ステップを完了するにはクラスタを登録するプロジェクトで GKE Hub 管理者のロールが必要です。
API を有効にする
コンソール
クラスタが登録されているプロジェクトを選択していることを確認します。
-
Enable the GKE Hub and Kubernetes Engine 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 を有効にする
Google Cloud コンソールで、GKE Enterprise の [機能] ページに移動します。
[機能] テーブルの [Identity Service] 行で [有効にする] をクリックし、表示されたペインで [有効にする] を再度クリックします。これにより、フリートのクラスタ内で GKE Identity Service のライフサイクルを管理する新しい GKE Identity Service コントローラ インスタンスが作成されます。
クラスタを選択
- [機能] のテーブルに戻り、[Identity Service] 行の [詳細] をクリックして、サービスの詳細ペインを開きます。これには、プロジェクトのクラスタとそのフリートレベルの GKE Identity Service のステータスが表示されます。
- [ID サービスを更新する] をクリックして、設定ペインを開きます。
- 構成するクラスタを選択します。選択できるのはサポートされているクラスタタイプのみです。個々のクラスタを選択するか、すべてのクラスタを同じ ID 構成にするように指定できます。
- [ID プロバイダ] プルダウンで、クラスタの構成方法を選択します。クラスタに既存の GKE Identity Service 構成がある場合は、それを更新することもできます。既存の登録済みクラスタに使用する GKE Identity Service 構成がある場合は、その構成を選択したクラスタにコピーできます。まったく新しい構成を作成するには、次のセクションで説明するように、選択したプロバイダの手順に沿って操作します。
プロバイダの詳細を設定する
追加する必要があるプロバイダの詳細は、構成に使用する ID プロバイダの種類によって異なります。
OIDC
- [新しい OpenID Connect] を選択して、新しい OIDC 構成を作成します。
- この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。この名前は、先頭が文字で、その後に最大 39 文字の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません構成を作成した後は、この名前を編集することはできません。
- プロバイダに GKE Identity Service を登録するときに返されたクライアント ID を、[クライアント ID] フィールドに指定します。
- [Client Secret] 欄で、クライアント アプリケーションと ID プロバイダの間で共有する必要があるクライアント シークレットを指定します。
- [Issuer URL] には、ID プロバイダに対して認可リクエストを行う URI を指定します。
- [次へ] をクリックして OIDC 属性を設定します。
Azure AD
- [新しい Azure Active Directory] を選択して、新しい Azure AD 構成を作成します。
- この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。この名前は、先頭が文字で、その後に最大 39 文字の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません構成を作成した後は、この名前を編集することはできません。
- プロバイダに GKE Identity Service を登録するときに返されたクライアント ID を、[クライアント ID] フィールドに指定します。
- [Client Secret] 欄で、クライアント アプリケーションと ID プロバイダの間で共有する必要があるクライアント シークレットを指定します。
- 認証する Azure AD アカウントであるテナントを [テナント] で指定します。
- [次へ] をクリックして、Azure AD 属性を設定します。
LDAP
- [LDAP] を選択して、新しい LDAP 構成を作成します。
- この構成を識別するために使用する名前を [プロバイダ名] フィールドで指定します。通常は ID プロバイダ名を指定します。この名前は、先頭が文字で、その後に最大 39 文字の小文字、数字、ハイフンで構成します。末尾をハイフンにすることはできません構成を作成した後は、この名前を編集することはできません。
- [次へ] をクリックします。
- LDAP サーバーのホスト名(必須)、LDAP 接続タイプ、base64 でエンコードされた CA 証明書を指定します。
- [次へ] をクリックしてサーバーを構成します。
- ユーザーの識別名、フィルタ、ログイン属性、識別子属性を指定します。
- [次へ] をクリックして、ユーザーの詳細を設定します。
- グループを使用する場合は、グループの識別名、フィルタ、ID 属性を指定します。
- [次へ] をクリックして、グループの詳細を設定します。
- サービス アカウントのユーザー名とパスワードを指定します。
- [完了] をクリックして、サービス アカウント名を設定します。
属性を設定する
追加する必要がある属性は、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(オプション): 構成に必要な追加パラメータ。パラメータ Key と Value で指定されます。[パラメータを追加] をクリックし、必要に応じてパラメータを追加します。
- アクセス トークンを有効にする(省略可): 有効にすると、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
構成の両方を示しています。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: 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)になります。たとえば、loginAttribute を sAMAccountName に、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 を構成するには、次の手順を行います。
fleet-default.yaml
という名前のファイルを作成し、構成ファイルの作成に従って入力します。フリートレベルのデフォルト構成で GKE Identity Service を有効にします。
gcloud container fleet identity-service enable --fleet-default-member-config=fleet-default.yaml
既存のフリートレベルのデフォルト構成を変更するには、またはフリートレベルのデフォルト構成なしでフリートで GKE Identity Service がすでに有効になっている場合に追加するには、次のコマンドを実行します。
gcloud container fleet identity-service apply --fleet-default-member-config=default-config.yaml
フリートレベルのデフォルト構成が構成される前に登録されたクラスタは、デフォルト構成を自動的に継承しません。このクラスのクラスタに属するクラスタにデフォルト構成を適用する場合は、次のコマンドを実行します。
gcloud container fleet identity-service apply --origin=fleet --membership=CLUSTER_NAME
フリートレベルのデフォルト構成を削除するには、次のコマンドを実行します。
gcloud container fleet identity-service delete --fleet-default-member-config
ID サービスの構成を確認する
フリートレベルの設定が完了したら、指定した ID サービス構成でフリート内のクラスタが正常に構成されているかどうかを確認できます。
コンソール
Google Cloud コンソールで、GKE Enterprise の [機能] ページに移動します。
有効なすべての機能は、[機能] リストで [有効] として表示されます。
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 管理は、次のようにして無効にします。
コンソール
Google Cloud コンソールで、GKE Enterprise の [機能] ページに移動します。
[機能] の表で、[Identity Service] 行の [詳細] をクリックして、表示されたペインの [GKE Identity Service を無効にする] をクリックします。
gcloud
次のコマンドを実行します。
gcloud container fleet identity-service disable
フリート機能を無効にすると、Google Cloud コンソールまたは gcloud
によるクラスタの GKE Identity Service の状態の表示や更新ができなくなります。
トラブルシューティング
この設定中に問題が発生した場合は、トラブルシューティング ガイドをご覧ください。