このページでは、外部 ID プロバイダ（IdP）から Google Kubernetes Engine（GKE）クラスタへの認証を構成する方法について説明します。
このページは、OpenID Connect（OIDC）または Security Assertion Markup Language（SAML）2.0 をサポートする外部 IdP を使用するプラットフォーム管理者、オペレーター、ID 管理者、アカウント管理者を対象としています。
このページを読む前に、次の認証と OpenID のコンセプトを理解しておいてください。
GKE の外部 IdP 認証方法
推奨 - Workforce Identity 連携
Workforce Identity 連携は、OIDC または SAML 2.0 をサポートする任意の外部 IdP から Google Cloud への認証を可能にする IAM 機能です。Workforce Identity 連携では、クラスタ内インストールは不要で、Autopilot クラスタと Standard クラスタで動作し、 Google Cloudに組み込まれています。詳細については、Workforce Identity 連携に関する IAM ドキュメントをご覧ください。
非推奨 - GKE 用 Identity Service
GKE Standard クラスタでのみ、GKE は Identity Service for GKE もサポートしています。Identity Service for GKE は OIDC IdP に限定されており、クラスタに追加のコンポーネントをインストールします。GKE では、Identity Service for GKE ではなく Workforce Identity 連携を使用することを強く推奨しています。
始める前に
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateを実行して最新のバージョンを取得する。
考慮事項
ヘッドレス システムは、Workforce Identity 連携と Identity Service for GKE の両方でサポートされていません。ブラウザベースの認証フローで、同意を求められ、ユーザー アカウントを承認します。
GKE で Workforce Identity 連携を使用する
GKE クラスタで Workforce Identity 連携を使用するには、次の操作を行います。
- 組織と外部 IdP の Workforce Identity 連携を設定します。手順については、Workforce Identity 連携を構成するをご覧ください。
- 外部 IdP から Google Cloud Workforce Identity 連携コンソールへのアクセスを設定します。詳細については、コンソール（連携）へのユーザー アクセスを設定するをご覧ください。
次のいずれかの認証メカニズムを使用して、ユーザー アクセスを構成します。
次の手順に沿ってクラスタにアクセスするよう、ユーザーに伝えます。
- フェデレーション ID を使用して gcloud CLI にログインします。
gcloud container clusters get-credentialsを実行して、特定のクラスタに対して認証するように kubectl を構成します。
RBAC を使用してクラスタへのユーザー アクセスを構成する
Google Cloud は、プリンシパル ID を使用して、Workforce Identity プール内のユーザーを識別します。これらのプリンシパル ID は、Kubernetes RBAC ポリシーまたは IAM ポリシーで参照できます。次の例のように、個人またはユーザーのグループに権限を付与できます。
| ID | プリンシパル ID |
|---|---|
| シングル ユーザー | principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE 次のように置き換えます。
次に例を示します。 principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com |
| グループ内のすべてのユーザー | principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME 次のように置き換えます。
次に例を示します。 principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre |
Workforce Identity 連携がサポートするプリンシパル ID については、IAM ポリシーで Workforce プール ユーザーを表すをご覧ください。
次の例は、full-time-employees Workforce プールのエンティティのうち、IdP トークンに access_level="sensitive" 属性があるエンティティに、Secret に対するクラスタ全体の読み取り専用アクセス権を付与する方法を示しています。
次の ClusterRole マニフェストを
secret-viewer-cluster-role.yamlとして保存します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-viewer rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]この ClusterRole をバインドするプリンシパルは、Secret を表示できます。
次の ClusterRoleBinding マニフェストを
secret-viewer-cluster-role-binding.yamlとして保存します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: users-view-secrets subjects: - kind: Group name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/attribute.access_level/sensitive apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-viewer apiGroup: rbac.authorization.k8s.ioこの ClusterRoleBinding は、
access_level="sensitive"属性を持つすべてのユーザーにsecret-viewerClusterRole を付与します。ClusterRole と ClusterRoleBinding をデプロイします。
kubectl apply -f secret-viewer-cluster-role.yaml kubectl apply -f secret-viewer-cluster-role-binding.yaml
クラスタにログインして認証する
- Google Cloudで Google Cloud CLI CLI を使用してログインします。
ユーザーは、次の方法でクラスタに対して認証するように kubectl を構成できます。
gcloud container clusters get-credentials
Identity Service for GKE クラスタを Workforce Identity 連携に移行する
既存の GKE クラスタで Identity Service for GKE を使用している場合は、Workforce Identity 連携に移行します。次の表に示すように、これらのメソッドは異なる構文を使用して同じプリンシパルを参照します。
| GKE 用 Identity Service の構文 | Workforce Identity 連携の構文 |
|---|---|
amal@example.com |
principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com
|
sre-group |
principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre-group
|
Workforce Identity 連携を使用するようにクラスタを移行するには、次の操作を行います。
組織と外部 IdP の Workforce Identity 連携を設定します。手順については、Workforce Identity 連携を構成するをご覧ください。
クラスタ内の RoleBinding と ClusterRoleBinding のマニフェストを更新して、Workforce Identity 連携の ID 構文を使用します。次のいずれかのオプションを使用します。
プログラムによる更新:
gke-identity-service-migratorユーティリティをインストールして実行します。手順については、GoogleCloudPlatform/gke-utilitiesリポジトリの README をご覧ください。このユーティリティは、Identity Service for GKE 構文を使用する既存の RBAC バインディングを検索し、対応する Workforce Identity 連携プリンシパル ID を使用する新しいマニフェストを作成します。
手動更新: 認証済みユーザーまたはグループを参照するバインディングごとに、Workforce Identity 連携識別子構文を使用するオブジェクトのマニフェスト ファイルのコピーを個別に作成します。
RoleBinding と ClusterRoleBinding の更新されたマニフェストをクラスタに適用します。
Workforce Identity 連携を使用して認証するときに、ユーザーが同じリソースにアクセスできることをテストします。
クラスタから廃止された RBAC バインディングを削除します。
Identity Service for GKE を使用する
GKE 標準モード クラスタで GKE 用 Identity Service を設定して使用するには、クラスタ管理者が次の手順を行います。
クラスタ管理者が GKE 用 Identity Service を構成すると、デベロッパーはクラスタにログインして認証できるようになります。
GKE 用 Identity Service によって作成された Kubernetes オブジェクト
次の表は、クラスタで GKE 用 Identity Service を有効にするときに作成される Kubernetes オブジェクトを示したものです。
| Kubernetes オブジェクト | |
|---|---|
anthos-identity-service |
NamespaceGKE 用 Identity Service のデプロイに使用されます。 |
kube-public |
Namespacedefaultクライアント構成ファイルに使用されます。 |
gke-oidc-envoy |
LoadBalancerOIDC リクエストのエンドポイント。デフォルトで外部。外部 IP エンドポイントのないクラスタで作成されている場合、エンドポイントはクラスタの Virtual Private Cloud の内部にあります。 anthos-identity-service Namespace に作成されます。 |
gke-oidc-service |
ClusterIPgke-oidc-envoy Deployment と gke-oidc-service Deployment との間の通信を容易にします。anthos-identity-service Namespace に作成されます。 |
gke-oidc-envoy |
Deploymentgke-oidc-envoy LoadBalancer に公開されたプロキシを実行します。gke-oidc-service と通信して ID トークンを検証します。Kubernetes API サーバーのプロキシとして機能し、API サーバーにリクエストを渡すときにユーザーになりすまします。anthos-identity-service Namespace に作成されます。 |
gke-oidc-service |
DeploymentID トークンを検証し、 ClientConfig リソース用の Validating Admission Webhook を提供します。anthos-identity-service Namespace に作成されます。 |
gke-oidc-operator |
Deploymentクライアント構成と gke-oidc-envoy LoadBalancer を調整します。anthos-identity-service Namespace に作成されます。 |
gke-oidc-certs |
SecretLoadBalancer 用のクラスタ認証局（CA）と TLS 証明書が含まれています。 anthos-identity-service Namespace に作成されます。 |
default |
ClientConfig CRD推奨認証方法、ID プロバイダの構成、ユーザーとグループのクレームのマッピングなどの OIDC パラメータが含まれます。ID トークンの検証に使用されます。クラスタ管理者が使用し、OIDC 設定を構成してからデベロッパーに配布します。 kube-public Namespace に作成されます。 |
クラスタで GKE 用 Identity Service を有効にする
デフォルトでは、Identity and Access Management（IAM）がクラスタ認証の ID プロバイダとして構成されます。サードパーティの ID プロバイダで OIDC を使用する場合は、Google Cloud CLI を使用して新規または既存のクラスタで GKE 用 Identity Service を有効にできます。
新しいクラスタで GKE 用 Identity Service を有効にする
GKE 用 Identity Service が有効になったクラスタを作成するには、次のコマンドを実行します。
gcloud container clusters create CLUSTER_NAME \
--enable-identity-service
CLUSTER_NAME は、使用する新しいクラスタの名前に置き換えます。
既存のクラスタで GKE 用 Identity Service を有効にする
既存のクラスタで GKE 用 Identity Service を有効にするには、次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \
--enable-identity-service
CLUSTER_NAME は、使用するクラスタの名前に置き換えます。
GKE 用 Identity Service を構成する
default ClientConfig をダウンロードして変更することで、GKE 用 Identity Service を構成できます。
defaultClientConfig をダウンロードします。kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml使用したい設定で
spec.authenticationセクションを更新します。apiVersion: authentication.gke.io/v2alpha1 kind: ClientConfig metadata: name: default namespace: kube-public spec: name: cluster-name server: https://192.168.0.1:6443 authentication: - name: oidc oidc: clientID: CLIENT_ID certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE extraParams: EXTRA_PARAMS issuerURI: ISSUER_URI cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc kubectlRedirectURI: KUBECTL_REDIRECT_URL scopes: SCOPES userClaim: USER groupsClaim: GROUPS userPrefix: USER_PREFIX groupPrefix: GROUP_PREFIX次のように置き換えます。
CLIENT_ID: OIDC プロバイダに認証リクエストを行うクライアント アプリケーションの ID。OIDC_PROVIDER_CERTIFICATE:（省略可）OIDC プロバイダの PEM 証明書。OIDC プロバイダが自己署名証明書を使用する場合、このフィールドが役立つことがあります。GKE 用 Identity Service には、デフォルトで一連の公開ルートが含まれています。EXTRA_PARAMS: OIDC プロバイダに送信する追加の Key-Value パラメータ。- グループを承認するには、
resource=token-groups-claimを使用します。 - Microsoft Azure と Okta を認証するには、
prompt=consentを使用します。 - Cloud Identity の場合は、
prompt=consent,access_type=offlineを使用します。
- グループを承認するには、
ISSUER_URI: OIDC 認可リクエストを送信する URL（たとえば、https://example.com/adfs）。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。URI には HTTPS を使用する必要があります。Cloud Identity の場合は、https://accounts.google.comを使用します。KUBECTL_REDIRECT_URL:kubectl oidc loginが認証に使用するリダイレクト URL。通常は、http://localhost:PORT/callbackという形式です。ここで、PORTはデベロッパー ワークステーションで使用可能な1024を超えるポートです（例:http://localhost:10000/callback）。この URL は、クライアント アプリケーションの承認済みのリダイレクト URL として OIDC プロバイダに登録する必要があります。Google Identity を OIDC プロバイダとして使用する場合は、リダイレクト URI を設定するで手順をご覧ください。SCOPES: OIDC プロバイダに送信する追加のスコープ。- Microsoft Azure と Okta には
offline_accessスコープが必要です。 - Cloud Identity の場合は、
openid, emailを使用して、emailクレーム内のメールアドレスを含む ID トークンを取得します。
- Microsoft Azure と Okta には
USER: ID トークンのユーザー クレーム。GROUPS: ID トークンのグループ クレーム。USER_PREFIX: 既存の名前と競合しないように、ユーザー クレームの先頭に付加される接頭辞。デフォルトでは、発行元の接頭辞が Kubernetes API サーバーに渡されたuserIDに追加されます（ユーザー クレームがemailの場合を除く）。生成されるユーザー ID はISSUER_URI#USERです。接頭辞を使用することをおすすめしますが、USER_PREFIXを-に設定すると接頭辞を無効にできます。GROUP_PREFIX: 既存の名前と競合しないように、グループ クレームの先頭に付加される接頭辞。たとえば、foobarという名前の 2 つのグループがある場合、接頭辞gid-を追加します。結果のグループはgid-foobarです。
更新した構成を適用します。
kubectl apply -f client-config.yamlこの構成を適用すると、GKE 用 Identity Service がクラスタ内で実行され、
gke-oidc-envoyロードバランサの背後でリクエストを処理します。spec.serverフィールドの IP アドレスは、ロードバランサの IP アドレスにする必要があります。spec.serverフィールドを変更すると、kubectlコマンドが失敗する可能性があります。client-config.yaml構成ファイルのコピーを作成します。cp client-config.yaml login-config.yamlspec.authentication.oidcセクションのclientSecret設定でlogin-config.yaml構成ファイルを更新します。clientSecret: CLIENT_SECRETCLIENT_SECRETは、OIDC クライアント アプリケーションと OIDC プロバイダの間での共有シークレットに置き換えます。更新した
login-config.yamlファイルをデベロッパーに配布します。
厳格なポリシーを持つクラスタで GKE 用 Identity Service を構成する
厳格なネットワーク ポリシーが設定されているクラスタで想定どおりに動作するように GKE 用 Identity Service を構成するには、次の手順を行います。
- TCP ポート
15000のファイアウォール ルールを追加して、コントロール プレーンがClientConfig検証 Webhook と通信できるようにします。 gke-oidc-envoyが内部ロードバランサとして作成されている場合は、VPC に公開します。- クラスタ内のトラフィックを拒否するポリシーが存在する場合は、TCP ポート
8443にファイアウォール ルールを追加して、gke-oidc-envoyDeployment がgke-oidc-serviceDeployment と通信できるようにします。
Identity Service for GKE コンポーネント バージョン 0.2.20 以降では、TCP ポート 15000 を使用しません。コンポーネントのバージョンが 0.2.20 以降の場合、ポート 15000 のファイアウォール ルールを追加する必要はありません。コンポーネントのバージョンを確認するには、次のコマンドを実行します。
kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
| grep "components.gke.io/component-name: gke-oidc" -A1
ロードバランサにカスタム プロパティを追加する
GKE 用 Identity Service を構成すると、静的 IP アドレスなどのカスタム アノテーションとプロパティを gke-oidc-envoy ロードバランサに追加できます。gke-oidc-envoy Service を編集するには、次のコマンドを実行します。
kubectl edit service gke-oidc-envoy -n anthos-identity-service
GKE の TCP / UDP ロード バランシングの構成の詳細については、LoadBalancer Service のパラメータをご覧ください。
クラスタの RBAC ポリシーを作成する
管理者は Kubernetes ロールベースのアクセス制御（RBAC）を使用して、認証済みクラスタ ユーザーにアクセスを許可します。クラスタに RBAC を構成するには、各デベロッパーに RBAC ロールを付与する必要があります。特定の Namespace のリソースへのアクセスを許可するには、Role と RoleBinding を作成します。クラスタ全体のリソースへのアクセスを許可するには、ClusterRole と ClusterRoleBinding を作成します。
たとえば、クラスタ全体のすべての Secret オブジェクトを表示する必要があるユーザーを考えてみましょう。次の手順では、必要な RBAC ロールをこのユーザーに付与します。
次の ClusterRole マニフェストを
secret-viewer-cluster-role.yamlとして保存します。このロールを付与されたユーザーは、クラスタ内の Secret に対して get、watch、list オペレーションを行えます。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-viewer rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]ClusterRole マニフェストを適用します。
kubectl apply -f secret-viewer-cluster-role.yaml次の ClusterRoleBinding マニフェストを
secret-viewer-cluster-role-binding.yamlとして保存します。このバインディングでは、クライアント構成ファイルで定義されているユーザー名にsecret-viewerロールを付与します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: people-who-view-secrets subjects: - kind: User name: ISSUER_URI#USER apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-viewer apiGroup: rbac.authorization.k8s.io次のように置き換えます。
ISSUER_URI: クライアント構成ファイルのspec.authentication.oidc.issuerURIにある発行者 URI。USER: クライアント構成ファイルのspec.authentication.oidc.userClaimで構成されたクレーム名の下のトークンのユーザー ID。
ClusterRoleBinding マニフェストを適用します。
kubectl apply -f secret-viewer-cluster-role-binding.yaml
クラスタにログインして認証する
管理者から OIDC 構成ファイルを受け取ったデベロッパーは、クラスタに対する認証を行うことができます。
管理者から提供された
login-config.yamlファイルをダウンロードします。個別の OIDC コンポーネントを提供する Google Cloud CLI SDK をインストールします。これをインストールするには、次のコマンドを実行します。
gcloud components install kubectl-oidcクラスタに対する認証を行います。
kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yamlウェブブラウザが開き、認証プロセスが完了します。
認証されたら、次のような
kubectlコマンドを実行できます。kubectl get pods
GKE 用 Identity Service を無効にする
gcloud CLI を使用して、GKE 用 Identity Service を無効にできます。GKE 用 Identity Service を無効にするには、次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \
--no-enable-identity-service
次のステップ
- Workforce Identity 連携について学習する。
- ワークロードのデプロイの詳細を確認する。