The product described by this documentation, Anthos Clusters on AWS (previous generation), is now in maintenance mode. All new installs must use the current generation product, Anthos clusters on AWS.

OpenID Connect（OIDC）による認証

ユーザークラスタの認証に OpenID Connect（OIDC）を使用するよう GKE on AWS を構成する方法について学びます。このトピックでは、任意の OpenID プロバイダを使用して GKE on AWS を構成するプロセスについて説明します。

OIDC 認証を使用するクラスタを Kubernetes 1.21 にアップグレードするには、1.21 にアップグレードするをご覧ください。

GKE on AWS 認証フローの概要については、認証をご覧ください。

概要

GKE on AWS は、ユーザークラスタの Kubernetes API サーバーとやり取りする認証メカニズムの一つとして OIDC をサポートしています。OIDC を使用すると、組織内のユーザーアカウントの作成、有効化、無効化の標準的な手順を使用して、Kubernetes クラスタへのアクセスを管理できます。

始める前に

このトピックは、次の認証と OpenID のコンセプトを理解していることを前提としています。
Google Cloud CLI を各デベロッパーのローカルマシンにインストールする必要があります。
ヘッドレスシステムはサポートされていません。認証するには、gcloud CLI を実行しているローカルマシンでブラウザを開く必要があります。ブラウザにユーザーアカウントの承認を求めるメッセージが表示されます。
Google Cloud Console で認証するには、OIDC 認証用に構成する各クラスタを Google Cloud に登録する必要があります。

ペルソナ

このトピックでは、次の 3 つのペルソナについて説明します。

組織管理者: OpenID プロバイダを選択し、クライアントアプリケーションをプロバイダに登録します。
クラスタ管理者: 1 つ以上のユーザークラスタを作成し、クラスタを使用する開発者用の認証構成ファイルを作成します。
デベロッパー: 1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。

OpenID プロバイダを選択する

このセクションは、組織管理者を対象としています。

任意の OpenID プロバイダを使用できます。認定プロバイダのリストについては、OpenID 認定資格をご覧ください。

リダイレクト URL を作成する

このセクションは、組織管理者を対象としています。

OpenID プロバイダは、リダイレクト URL を使用して ID トークンを返します。gcloud CLI と Google Cloud コンソールの両方にリダイレクト URL を作成する必要があります。

gcloud CLI リダイレクト URL を設定する

OpenID プロバイダを構成するときは、CLI のリダイレクト URL を http://localhost:PORT/callback として指定します。

PORT は、1024 より大きいポート番号に置き換えます。

Google Cloud コンソールのリダイレクト URL を設定する

Google Cloud コンソールのリダイレクト URL は次のとおりです。

https://console.cloud.google.com/kubernetes/oidc

OIDC プロバイダを構成するときに、リダイレクト URL の 1 つとして https://console.cloud.google.com/kubernetes/oidc を指定します。

OpenID プロバイダでクライアントアプリケーションを登録する

このセクションは、組織管理者を対象としています。

デベロッパーが Google Cloud CLI または Google Cloud コンソールで OpenID プロバイダを使用する前に、この 2 つのクライアントを OpenID プロバイダに登録する必要があります。登録手順は以下のとおりです。

プロバイダの発行者 URI を確認します。gcloud CLI または Google Cloud コンソールからこの URI に認証リクエストが送信されます。
gcloud CLI のリダイレクト URL（ポート番号を含む）を使用してプロバイダを構成します。
Google Cloud コンソールのリダイレクト URL を使用して、プロバイダを構成します（https://console.cloud.google.com/kubernetes/oidc）。
プロバイダが Google Cloud CLI と Google Cloud コンソールの両方の識別に使用するクライアント ID を 1 つ作成します。
gcloud CLI と Google Cloud コンソールで OpenID プロバイダの認証に使用するクライアントシークレットを 1 つ作成します。
gcloud CLI または Google Cloud コンソールで、ユーザーのセキュリティグループのリクエストに使用できるカスタムスコープを作成します。
プロバイダがユーザーのセキュリティグループを返すために使用するカスタムクレーム名を作成します。

クラスタを構成する

このセクションは、クラスタ管理者を対象としています。

OIDC 認証を構成するには、クラスタの認証情報を使用して、ユーザークラスタの AWSCluster リソースを構成する必要があります。AWSCluster の詳細は、Google Cloud コンソールと GKE Enterprise 用 Authentication プラグインの両方に OIDC を構成するために使用されます。構成には、次の OIDC 情報が含まれています。

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

認証のフィールド

次の表に、authentication.awsIAM.adminIdentityARNs オブジェクトのフィールドを示します。

次の表に、oidc オブジェクトのフィールドを示します。

フィールド	必須	説明	形式
adminIdentityARNs	OIDC を構成する場合は必須。	GKE on AWS によってクラスタ管理者アクセス権が付与された AWS IAM の ID（ユーザーまたはロール）の Amazon Resource Name（ARN）。例: `arn:aws:iam::123456789012:group/Developers`	文字列

フィールド	必須	説明	形式
certificateAuthorityData	×	Base64 でエンコードされた OIDC プロバイダの PEM エンコード証明書。文字列を作成するには、ヘッダーを含めた証明書を base64 でエンコードします。結果の文字列は `certificateAuthorityData` に 1 行で含めます。例: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	文字列
clientID	○	OpenID プロバイダへの認証リクエストを行うクライアントアプリケーションの ID。	文字列
clientSecret	×	OIDC クライアントアプリケーションと OIDC プロバイダ間の共有シークレット。	文字列
extraParams	×	OpenID プロバイダに送信する追加の Key-Value パラメータ。グループを承認する場合は、`resource=token-groups-claim` を渡します。 Microsoft Azure と Okta の認証で認可サーバーが同意を求めるプロンプトを表示する場合は、`extraParams` を `prompt=consent` に設定します。Cloud Identity の場合は、`extraParams` を `prompt=consent,access_type=offline` に設定します。	カンマ区切りのリスト
groupsClaim	×	プロバイダがセキュリティグループを返すために使用する JWT クレーム。	文字列
groupPrefix	×	既存の名前と競合しないように、グループクレームの先頭に付加される接頭辞。たとえば、`foobar` という名前の 2 つのグループに接頭辞 `gid-` を追加した場合、結果のグループは `gid-foobar` になります。	文字列
issuerURI	○	認可リクエストが OpenID に送信される URL（`https://example.com/adfs` など）。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。URI には HTTPS を使用する必要があります。	URL 文字列
kubectlRedirectURI	○	「kubectl」が認可に使用するリダイレクト URL。	URL 文字列
scopes	○	OpenID プロバイダに送信する追加のスコープ。Microsoft Azure と Okta には `offline_access` スコープが必要です。	カンマ区切りのリスト
userClaim	×	ユーザー名として使用する JWT クレーム。OpenID プロバイダによっては、email や name などの他のクレームを選択できます。ただし、名前が競合しないように、email 以外のクレームには発行者の URL が先頭に付加されます。	文字列
userPrefix	×	既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。	文字列

例: ユーザーとグループの承認

多くのプロバイダは、ユーザー識別プロパティ（メールやユーザー ID など）をトークンにエンコードします。ただし、これらのプロパティには認証ポリシーに関する潜在的なリスクがあります。

ユーザー ID を使用すると、ポリシーの読み取りと監査が困難になることがあります。
メールアドレスを使用すると、可用性リスク（ユーザーがメインのメールアドレスを変更した場合）とセキュリティリスク（メールを再割り当てできる場合）の両方が発生する可能性があります。

ユーザー ID を割り当てるのではなく、永続的で監査しやすいグループポリシーを使用することをおすすめします。

プロバイダが、次のフィールドを含む ID トークンを作成したとします。

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

このトークン形式では、構成ファイルの oidc 仕様を次のように指定します。

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

ユーザークラスタを作成したら、Kubernetes のロールベースのアクセス制御（RBAC）を使用して、認証済みユーザーに特権アクセスを付与します。

次の例では、クラスタの Secret への読み取り専用アクセス権をユーザーに付与する ClusterRole を作成し、ClusterRoleBinding リソースを作成して認証済みグループにロールをバインドします。

ClusterRole を定義します。次の YAML を secret-reader-role.yaml というファイルにコピーします。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

ClusterRoleBinding を定義します。次の YAML を secret-reader-admins.yaml というファイルにコピーします。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

kubectl を使用して secret-reader-role.yaml と secret-reader-admins.yaml をクラスタに適用します。
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml
```
これで、read-secrets-admins でアクセス権が付与されたユーザーが、クラスタ内の Secret を読み取ることができます。

ログイン構成の作成

このセクションは、クラスタ管理者を対象としています。

ユーザークラスタを作成した後、gcloud anthos create-login-config を使用してそのクラスタの構成ファイルを生成する必要があります。

anthos-aws ディレクトリから anthos-gke を使用して、コンテキストをユーザークラスタに切り替えます。
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
CLUSTER_NAME は、ユーザークラスタ名に置き換えます。
gcloud anthos で構成を作成します。
```
gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
```
usercluster-kubeconfig は、ユーザークラスタの kubeconfig ファイルのパスに置き換えます。Linux と macOS の場合、このファイルはデフォルトで ~/.kube/config にあります。

このコマンドは、デベロッパーが gcloud CLI でクラスタを認証するために使用する構成情報を含むファイル（kubectl-anthos-config.yaml）を生成します。このファイルは変更しないでください。

kubectl-anthos-config.yaml の内容の詳細については、付録をご覧ください。

ユーザークラスタの認証が必要なユーザーに構成ファイルを配布します。構成は次の方法で配布できます。

デフォルトのディレクトリにファイルを配置します。
ファイルを安全に配布します。
HTTPS サーバーでファイルをホストします。

ログイン構成のデフォルトディレクトリ

各 OS の構成ファイルを保存するデフォルトの場所は次のとおりです。

Linux: $HOME/.config/google/anthos/kubectl-anthos-config.yaml（$HOME はユーザーのホームディレクトリです）。
macOS: $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml（$HOME はユーザーのホームディレクトリです）。
Windows: %APPDATA%/google/anthos/kubectl-anthos-config.yaml（%APPDATA% はユーザーのアプリケーションデータディレクトリです）。

ログイン構成が配布されると、デベロッパーはクラスタにアクセスするように gcloud CLI を構成できます。

Kubernetes 1.21 にアップグレードした後でクラスタを変更する

クラスタを Kubernetes 1.21 にアップグレードした後、GKE Identity Service を構成し、クラスタの構成から OIDC 情報を削除する必要があります。構成の更新手順は次のとおりです。

クラスタをアップグレードするの説明に従います。
anthos-aws ディレクトリから anthos-gke を使用して、コンテキストをユーザークラスタに切り替えます。
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
CLUSTER_NAME は、ユーザークラスタ名に置き換えます。
テキストエディタで AWSCluster を含むマニフェストを開きます。ファイルを開いたまま、oidc オブジェクトの値を使用して、GKE Identity Service 用にクラスタを構成するの説明に従って操作します。
anthos-aws ディレクトリから anthos-gke を使用して、コンテキストを管理サービスに切り替えます。
```
cd anthos-aws
anthos-gke aws management get-credentials
```
注: anthos-gke では、aws configure を実行したときに指定した認証情報を使用します。
AWSCluster を作成した YAML ファイルをテキストエディタで開きます。最初の YAML ファイルがない場合は、kubectl edit を使用できます。
YAML を編集する
ユーザークラスタの作成の手順を行っている場合、YAML ファイルの名前は cluster-0.yaml です。このファイルをテキストエディタで開きます。
kubectl edit
kubectl edit を使用して AWSCluster を編集するには、次のコマンドを実行します。
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name
```
cluster-name を AWSCluster に置き換えます。たとえば、デフォルトのクラスタ cluster-0 を編集するには、次のコマンドを実行します。
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0
```
クラスタのマニフェストから oidc オブジェクトを削除します。
ファイルを保存します。kubectl edit を使用している場合は、kubectl が変更を自動的に適用します。YAML ファイルを編集する場合は、次のコマンドを使用して管理サービスに適用します。
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml
```
これで、管理サービスにより AWSCluster が更新されます。

クラスタにアクセスするための gcloud の構成

このセクションは、開発者またはクラスタ管理者を対象としています。

要件

このセクションを終了するには、次の内容についての作業を完了する必要があります。

ログイン構成。
anthos-auth コンポーネントを含む gcloud CLI の更新バージョン。
```
gcloud components update
gcloud components install anthos-auth
```
次のコマンドを実行して、gcloud CLI が正常にインストールされたことを確認します。必要な引数と使用可能なオプションの詳細が返されます。
```
gcloud anthos auth
```

クラスタに対して認証する

クラスタに対して次の方法で認証を行うことができます。

ローカルマシンの gcloud CLI を使用する。
SSH トンネルを使用してリモートマシンで gcloud CLI を使用する。
Google Cloud コンソールで Connect を使用する。

gcloud local

gcloud anthos auth login を使用して、ログイン構成でクラスタに対する認証を行います。

ログイン構成をデフォルトの場所に配置し、クラスタ名が構成されている場合は、オプションなしで gcloud anthos auth login を使用できます。また、オプションのパラメータを使用して、クラスタ、ユーザー、その他の認証の詳細を構成することもできます。

デフォルト

gcloud anthos auth login --cluster CLUSTER_NAME

CLUSTER_NAME は、クラスタの完全修飾名に置き換えます。例: projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a

オプションパラメータ

gcloud anthos auth login は、次のオプションのパラメータをサポートしています。

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

パラメータについては、次の表をご覧ください。

パラメータ	説明
`cluster`	認証先のクラスタの名前。デフォルトは「kubectl-anthos-config.yaml」内のクラスタです。
`user`	`kubeconfig` の認証情報のユーザー名。デフォルトは `{cluster-name}-anthos-default-user` です。
`login-config`	開発者のためにクラスタ管理者が生成した構成ファイルのパス、またはファイルをホストする URL です。デフォルトは `kubectl-anthos-config.yaml` です。
`login-config-cert`	`login-config` に URL を使用する場合、HTTPS 接続を確立するための CA 証明書ファイルのパス。
`kubeconfig`	トークンを含む kubeconfig ファイルへのパス。デフォルトは $HOME/.kube/config` です。
dry-run	構成やクラスタを変更せずにコマンドラインオプションをテストします。

gcloud anthos login コマンドは、企業の認証情報でログインするようユーザーに求めるブラウザを起動し、OIDC 認証情報の交換を実行して、関連するトークンを取得します。gcloud CLI がトークンを kubeconfig ファイルに書き込みます。kubectl は、このファイルを使用してユーザークラスタを認証します。

認証が成功したことを確認するには、kubeconfig ファイルを使用して任意の kubectl コマンドを実行します。

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

gcloud tunnel

リモートマシンからユーザークラスタで認証を行う場合は、SSH トンネルを使用して認証を行うことができます。トンネルを使用するには、認証構成ファイルがリモートマシン上にある必要があります。また、ローカルマシンから Open ID プロバイダにアクセスできる必要があります。

ローカルマシンで、次のコマンドを実行します。

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

次のように置き換えます。

USERNAME は、リモートマシンへの SSH アクセス権を持つユーザーで置き換えます。
REMOTE_MACHINE は、リモートマシンのホスト名または IP アドレスに置き換えます。
LOCAL_PORT は、ssh がリモートマシンへのトンネリングに使用するローカルマシン上のポートに置き換えます。
REMOTE_PORT は、OIDC リダイレクト URL 用に構成したポートです。ポート番号は、認証構成ファイルの kubectlRedirectURI フィールドに含まれています。

SSH シェルで次のコマンドを実行して、認証を開始します。

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

AUTH_CONFIG_FILE は、リモートマシン上の認証構成ファイルのパスに置き換えます。gcloud CLI は、リモートマシンでウェブサーバーを実行します。

ローカルマシンのブラウザで http://localhost:LOCAL_PORT/login に移動し、OIDC ログインフローに従います。

これで、リモートマシンの kubeconfig ファイルに、ユーザークラスタにアクセスするためのトークンが用意されました。

SSH シェルで、ユーザークラスタにアクセスできることを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

コンソール

Google Cloud コンソールで認証を行い、Google Cloud コンソールの Kubernetes クラスタのページから認証フローを開始できます。

Google Cloud コンソールを開きます。

[Kubernetes クラスタ] ページに移動
リストで GKE on AWS クラスタを見つけて、[ログイン] をクリックします。
[クラスタ用に構成された ID プロバイダで認証] を選択し、[ログイン] をクリックします。

ID プロバイダにリダイレクトされます。ここで、ログイン、または Google Cloud コンソールがアカウントにアクセスすることへの同意が必要となる場合があります。その後、Google Cloud コンソールの Kubernetes クラスタのページにリダイレクトされます。

OIDC 構成の更新

クラスタの OIDC 構成を更新するには、kubectl edit コマンドを使用します。

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

kubectl ツールは、デフォルトのエディタに ClientConfig リソースを読み込みます。構成を更新するには、ファイルを保存します。kubectl ツールは、クラスタの ClientConfig リソースを更新します。

ClientConfig リソースの内容については、次のセクションをご覧ください。

付録: ログイン構成の例

kubectl-anthos-config.yaml の例を示します。この例は、ファイルの内容を理解するためのものです。必ず gcloud anthos create-login-config を使用してファイルを生成してください。

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

フィールドの内容の説明については、認証のフィールドをご覧ください。

次のステップ

GKE on AWS に最初のワークロードをデプロイする。

OpenID Connect（OIDC）による認証

概要

始める前に

ペルソナ

OpenID プロバイダを選択する

リダイレクト URL を作成する

gcloud CLI リダイレクト URL を設定する

Google Cloud コンソールのリダイレクト URL を設定する

OpenID プロバイダでクライアント アプリケーションを登録する

クラスタを構成する

認証のフィールド

例: ユーザーとグループの承認

ログイン構成の作成

ログイン構成の配布

ログイン構成のデフォルト ディレクトリ

Kubernetes 1.21 にアップグレードした後でクラスタを変更する

YAML を編集する

kubectl edit

クラスタにアクセスするための gcloud の構成

要件

クラスタに対して認証する

gcloud local

デフォルト

オプション パラメータ

gcloud tunnel

コンソール

OIDC 構成の更新

付録: ログイン構成の例

次のステップ

OpenID プロバイダでクライアントアプリケーションを登録する

ログイン構成のデフォルトディレクトリ

オプションパラメータ