AWS の Anthos クラスタ(GKE on AWS)の新しいバージョンが 3 月 31 日にリリースされました。詳細については、リリースノートをご覧ください。

OpenID Connect(OIDC)による認証

ユーザー クラスタの認証に OpenID Connect(OIDC)を使用するために AWS 上の Anthos クラスタ(GKE on AWS)を構成する方法について学びます。このトピックでは、OpenID プロバイダを構成する方法の理解に役立つ一般的な手順を説明します。

AWS 上の Anthos クラスタの認証フローの概要については、認証をご覧ください。

概要

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

始める前に

  • このトピックは、次の認証と OpenID のコンセプトを理解していることを前提としています。

  • Cloud SDK と gcloud コマンドライン ツールは、各デベロッパーのローカルマシンにインストールする必要があります。

  • ヘッドレス システムはサポートされていません。認証するには、gcloud ツールを実行しているローカルマシンでブラウザを開く必要があります。ブラウザにユーザー アカウントの承認を求めるメッセージが表示されます。

  • Google Cloud Console で認証するには、OIDC 認証用に構成する各クラスタを Google Cloud に登録する必要があります。

ペルソナ

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

  • 組織管理者: OpenID プロバイダを選択し、クライアント アプリケーションをプロバイダに登録します。

  • クラスタ管理者: 1 つ以上のユーザー クラスタを作成し、クラスタを使用する開発者用の認証構成ファイルを作成します。

  • 開発者: 1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。

OpenID プロバイダの選択

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

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

リダイレクト URL の作成

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

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

gcloud ツールのリダイレクト URL の設定

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

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

Cloud Console リダイレクト URL の設定

Cloud Console のリダイレクト URL は次のとおりです。

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

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

OpenID プロバイダへのクライアント アプリケーションの登録

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

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

  • プロバイダの発行者 URI を確認します。gcloud ツールまたは Cloud Console がこの URI に認証リクエストを送信します。

  • gcloud ツールのリダイレクト URL(ポート番号を含む)を使用してプロバイダを構成します。

  • Cloud Console のリダイレクト URL でプロバイダを構成します(https://console.cloud.google.com/kubernetes/oidc)。

  • プロバイダが gcloud コマンドライン ツールと Cloud Console の両方の識別に使用するクライアント ID を 1 つ作成します。

  • gcloud ツールと Cloud Console で OpenID プロバイダの認証に使用する単一のクライアント シークレットを作成します。

  • gcloud ツールまたは Cloud Console でユーザーのセキュリティ グループのリクエストに使用できるカスタム スコープを作成します。

  • プロバイダがユーザーのセキュリティ グループを返すために使用するカスタム クレーム名を作成します。

クラスタの構成

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

OIDC 認証を構成するには、ユーザー クラスタの AWSCluster CRD にクラスタの認証情報を構成する必要があります。AWSCluster の詳細は、Cloud Console と Anthos 用 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 を構成する場合は必須。 AWS 上の Anthos クラスタによってクラスタ管理者アクセス権が付与された 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 の認証で認可サーバーが同意を求めるプロンプトを表示する場合は、extraParamsprompt=consent に設定します。Cloud Identity の場合は、extraParamsprompt=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 リソースを作成して認証済みグループにロールをバインドします。

  1. 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"]
    
  2. 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
    
  3. kubectl を使用して secret-reader-role.yamlsecret-reader-admins.yaml をクラスタに適用します。

    env HTTP_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 を使用してそのクラスタの構成ファイルを生成する必要があります。

  1. anthos-aws ディレクトリから anthos-gke を使用して、コンテキストをユーザー クラスタに切り替えます。

    cd anthos-aws
    env HTTP_PROXY=http://localhost:8118 \
    anthos-gke aws clusters get-credentials CLUSTER_NAME

  2. gcloud anthos で構成を作成します。

    gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
    

    usercluster-kubeconfig は、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。Linux と macOS の場合、このファイルはデフォルトで ~/.kube/config にあります。

このコマンドは、デベロッパーが gcloud ツールでクラスタを認証するために使用する構成情報を含むファイル(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 ツールを構成できます。

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

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

要件

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

  • ログイン構成
  • gcloud ツールの更新バージョン。anthos-auth コンポーネントを含みます。

    gcloud components update
    gcloud components install anthos-auth
    
  • 次のコマンドを実行して、gcloud CLI が正常にインストールされたことを確認します。必要な引数と使用可能なオプションの詳細が返されます。

    gcloud anthos auth
    

認証

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

  • ローカルマシン上の gcloud ツール。
  • SSH トンネルを使用したリモートマシンの gcloud ツール。
  • Google Cloud Console の 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 ツールは、トークンを kubeconfig ファイルに書き込みます。kubectl はこのファイルを使用してユーザー クラスタを認証します。

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

env HTTP_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 ツールは、リモートマシンでウェブサーバーを実行します。

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

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

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Console

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

  1. Cloud Console を開きます。

    [Kubernetes クラスタ] ページに移動

  2. リストで AWS 上の Anthos クラスタを見つけて、[ログイン] をクリックします。

  3. [クラスタ用に構成された ID プロバイダで認証] を選択し、[ログイン] をクリックします。

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

付録: ログイン構成の例

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:   AUTHORITY_DATA
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

次のステップ

AWS 上の Anthos クラスタに最初のワークロードをデプロイする。