このページでは、Google Kubernetes Engine(GKE)クラスタに対して認証を行うように外部 ID プロバイダを構成する方法について説明します。
概要
GKE 用 Identity Service は、既存の ID ソリューションを GKE クラスタに拡張します。OpenID Connect(OIDC)のサポートにより、組織内のユーザー アカウントの作成、有効化、無効化の標準的な手順で Kubernetes クラスタへのアクセスを管理できます。GKE 用 Identity Service は OIDC ID プロバイダに限定されています。
始める前に
このトピックでは、次の認証と OpenID のコンセプトを理解していることを前提としています。
ヘッドレス システムはサポートされていません。ブラウザベースの認証フローが使用されて、プロンプトで同意が求められ、ユーザー アカウントを承認します。
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API が有効になっていることを確認します。 Google Kubernetes Engine API の有効化
- Google Cloud CLI がインストールされていることを確認します。
- 次のいずれかの方法で、プロジェクトにデフォルトの Google Cloud CLI 設定をセットアップします。
- プロジェクトのデフォルトの設定全般を確認する場合は、
gcloud init
を使用します。 gcloud config
を使用して、プロジェクト ID、ゾーン、リージョンを個別に設定します。-
gcloud init
を実行して、次の操作を行います。gcloud init
リモート サーバーで SSH を使用している場合は、
--console-only
フラグを指定して、コマンドがブラウザを起動しないようにします。gcloud init --console-only
- Google Cloud アカウントを使用できるように、gcloud CLI の承認手順を行います。
- 新しい構成を作成するか、既存の構成を選択します。
- Google Cloud プロジェクトを選択します。
- デフォルトの Compute Engine ゾーンを選択します。
- デフォルトの Compute Engine リージョンを選択します。
- デフォルトのプロジェクト ID を設定します。
gcloud config set project PROJECT_ID
- デフォルトの Compute Engine リージョン(例:
us-central1
)を設定します。gcloud config set compute/region COMPUTE_REGION
- デフォルトの Compute Engine ゾーン(例:
us-central1-c
)を設定します。gcloud config set compute/zone COMPUTE_ZONE
gcloud
を最新バージョンに更新します。gcloud components update
gcloud init
gcloud config
デフォルトの場所を設定することで、gcloud CLI のエラー(One of [--zone, --region] must be supplied: Please specify location
など)を防止できます。
GKE 用 Identity Service を使用するユーザー
このドキュメントのタスクは、次のいずれかに該当する方を対象としています。
クラスタ管理者: 1 つ以上のユーザー クラスタを作成し、クラスタを使用する開発者用の認証構成ファイルを作成します。
デベロッパー: 1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。
仕組み
GKE クラスタで GKE 用 Identity Service を設定して使用するには、クラスタ管理者が次の手順を行います。
クラスタ管理者が GKE 用 Identity Service を構成すると、デベロッパーはクラスタにログインして認証できるようになります。
クラスタで 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 によって作成された Kubernetes オブジェクト
次の表は、クラスタで GKE 用 Identity Service を有効にするときに作成される Kubernetes オブジェクトを示したものです。
Kubernetes オブジェクト | |
---|---|
anthos-identity-service |
Namespace GKE 用 Identity Service のデプロイに使用されます。 |
kube-public |
Namespace default クライアント構成ファイルに使用されます。 |
gke-oidc-envoy |
LoadBalancer OIDC リクエストのエンドポイント。デフォルトは External です。限定公開クラスタまたは厳格なネットワーク ポリシーを持つクラスタで作成された場合、エンドポイントはクラスタの Virtual Private Cloud の内部になります。 anthos-identity-service 名前空間に作成されます。 |
gke-oidc-service |
ClusterIP gke-oidc-envoy Deployment と gke-oidc-service Deployment との間の通信を容易にします。anthos-identity-service 名前空間に作成されます。 |
gke-oidc-envoy |
Deployment gke-oidc-envoy LoadBalancer に公開されたプロキシを実行します。gke-oidc-service と通信して ID トークンを検証します。Kubernetes API サーバーのプロキシとして機能し、API サーバーにリクエストを渡すときにユーザーになりすます。anthos-identity-service 名前空間に作成されます。 |
gke-oidc-service |
Deployment ID トークンを検証し、 ClientConfig リソース用の検証用アドミッション Webhook を提供します。anthos-identity-service 名前空間に作成されます。 |
gke-oidc-operator |
Deployment クライアント構成と gke-oidc-envoy LoadBalancer を調整します。anthos-identity-service 名前空間に作成されます。 |
gke-oidc-certs |
Secret LoadBalancer 用のクラスタ認証局(CA)と TLS 証明書が含まれています。 anthos-identity-service 名前空間に作成されます。 |
default |
ClientConfig CRD 推奨される認証方法、ID プロバイダの構成、ユーザーとグループのクレームのマッピングなどの OIDC パラメータが含まれています。ID トークンの検証に使用されます。クラスタ管理者がデベロッパーに配布する前に OIDC 設定を構成するために使用します。 kube-public 名前空間に作成されます。 |
GKE 用 Identity Service を構成する
このセクションは、クラスタ管理者を対象としています。
default
ClientConfig をダウンロードして変更することで、GKE 用 Identity Service を構成できます。
default
ClientConfig をダウンロードします。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 として、OIDC プロバイダに URL を登録する必要があります。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
ロードバランサの背後でリクエストを処理します。client-config.yaml
構成ファイルのコピーを作成します。cp client-config.yaml login-config.yaml
spec.authentication.oidc
セクションのclientSecret
設定でlogin-config.yaml
構成ファイルを更新します。clientSecret: CLIENT_SECRET
CLIENT_SECRET
は、OIDC クライアント アプリケーションと OIDC プロバイダの間での共有シークレットに置き換えます。更新した
login-config.yaml
ファイルをデベロッパーに配布します。
厳格なポリシーを持つクラスタで GKE 用 Identity Service を構成する
限定公開クラスタなど、厳格なネットワーク ポリシーが設定されているクラスタで想定どおりに動作するように GKE 用 Identity Service を構成するには、次の手順を行います。
- TCP ポート
15000
にファイアウォール ルールを追加して、コントロール プレーンがClientConfig
検証 Webhook と通信できるようにします。 gke-oidc-envoy
が内部ロードバランサとして作成されている場合は、VPC で公開します。- クラスタ内のトラフィックを拒否するポリシーが存在する場合は、TCP ポート
8443
にファイアウォール ルールを追加して、gke-oidc-envoy
Deployment がgke-oidc-service
Deployment と通信できるようにします。
ロードバランサにカスタム プロパティを追加する
GKE 用 Identity Service を構成すると、静的 IP アドレスなどのカスタム アノテーションとプロパティを gke-oidc-envoy
ロードバランサに追加できます。gke-oidc-envoy
Service を編集するには、次のコマンドを実行します。
kubectl edit service gke-oidc-envoy -n anthos-identity-service
GKE の TCP/UDP 負荷分散を構成する方法をドキュメントで確認する。
クラスタの RBAC ポリシーを作成する
このセクションは、クラスタ管理者を対象としています。
管理者は Kubernetes ロールベースのアクセス制御(RBAC)を使用して、認証済みクラスタ ユーザーにアクセスを許可します。クラスタに RBAC を構成するには、各デベロッパーに RBAC ロールを付与する必要があります。特定の Namespace のリソースへのアクセスを許可するには、Role と RoleBinding を作成します。クラスタ全体のリソースへのアクセスを許可するには、ClusterRole と ClusterRoleBinding を作成します。
たとえば、クラスタ全体のすべての Secret オブジェクトを表示する必要があるユーザーについて考えてみましょう。次の手順では、必要な RBAC ロールをこのユーザーに付与します。
次の ClusterRole マニフェストを
secret-viewer-cluster-role.yaml
として保存します。このロールを付与されたユーザーは、クラスタ内の Secret を 取得、閲覧、表示することができます。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
次のステップ
- ワークロードのデプロイの詳細を確認する。
- OpenID Connect の詳細を確認する。
- スコープとクレームについて詳細を確認する。