OIDC を使用して ID とセキュリティを設定する

このページは、インフラストラクチャオペレーターを対象としています。

このページでは、選択した OpenID Connect（OIDC プロバイダ）を使用して Anthos Management Center への認証を有効にする方法について説明します。OIDC は OAuth 2.0 を基に構築された認証レイヤで、RESTful HTTP API を指定し、データ形式として JSON を使用します。

OIDC では、既存の ID プロバイダを使用してユーザーとグループの認証を管理できます。OIDC を使用すると、組織内の標準的な手順に従ってクラスタへのアクセスを管理し、アカウントの作成、有効化、無効化を行うことが可能です。

始める前に

OIDC の設定に先立ち、次のものが必要です。

インフラストラクチャオペレーターが提供する、Management Center へのアクセスに使用するドメイン名（例: anthos.example.com）。
Microsoft Active Directory フェデレーションサービス（ADFS）、Google SSO、Keycloak などの OIDC プロバイダ。クラスタとブラウザの両方が OIDC プロバイダに接続できる必要があります。OIDC プロバイダをクラスタに直接接続する必要はありません。OIDC プロバイダがない場合は、Keycloak で認証を参照してインストールします。Keycloak はデモ用です。本番環境では推奨されません。

ID プロファイルを作成する

ID プロファイルには、認証に ID プロバイダを使用するために必要な構成が含まれています。ID プロファイルを作成するには、次の手順に従います。

Management Center Console で、[ID とアクセス] メニューを開きます。
[ID] タブで、[Anthos Identity Service（OIDC）を設定] をクリックします。
[プロファイル名] フィールドに、ユーザーにとってわかりやすいプロファイル名を割り当てます。プロファイルは、この名前で参照されます。
ご利用の OIDC プロバイダの [OIDC プロバイダ URL]、[クライアント ID]、[クライアントシークレット] を入力します。
[ユーザー名クレーム] フィールドを設定します。ユーザー名クレームは、ユーザー名を保持する OIDC トークンのクレームです。たとえば、ユーザー名クレームが email の場合、ユーザーは OIDC トークンのユーザーフィールドによって識別されます。

このクレームを設定するときは、要求されたスコープ内にクレームが存在していることを確認してください。
[Username Prefix] フィールドを設定します。ユーザー名の接頭辞は、異なる ID プロバイダのユーザーを区別するために使用されます。ユーザーに RBAC 権限を割り当てる場合は、ユーザー接頭辞も含める必要があります。

たとえば、ユーザー名クレームが email で、ユーザー接頭辞が prefix- の場合、ユーザーは prefix-sally@example.com として識別されます。ユーザーが sally@example.com であり、異なる ID プロバイダを区別するために、接頭辞 prefix- はユーザーの接頭辞になります。

注: 切断モードで動作している Anthos では、接頭辞とユーザー名の間に区切り文字を挿入しないため、読みやすくするために - などの区切り文字を接頭辞の末尾に挿入します。それ以外のモードの場合、prefix と sally@example.com は prefixsally@example.com として識別されます。
[グループのクレーム] フィールドを設定します。切断モードで動作している Anthos でのデフォルト値は groups です。グループのロールへのバインディングの詳細については、ロールバインディングをご覧ください。
[Group Prefix] フィールドを設定します。グループ接頭辞は、異なる ID プロバイダのグループを区別するために使用されます。RBAC 権限をグループに割り当てるときは、グループ接頭辞も含める必要があります。

たとえば、グループクレームが groups で、グループ接頭辞が groupprefix- の場合、グループは groupprefix-group として識別されます。グループは group で、接頭辞 groupprefix- はグループの接頭辞になります。手順 6 でユーザー名の接頭辞を設定する手順に従って、接頭辞の末尾に区切り文字を挿入することをおすすめします。
（省略可）スコープが openid email profile でない場合は、[Scopes] フィールドを設定します。

スコープは、ID トークンでリクエストするアクセス権限を指定するために使用される識別子です。
- OIDC は openid に必要です。
- profile には、ユーザーのデフォルトの profile クレームが含まれます。
- 通常、email には、email クレームと email_verified クレームが含まれます。
OIDC プロバイダ（Google SSO など）に追加パラメータが必要な場合は、[追加パラメータ] フィールドを設定します。

たとえば、[追加のパラメータ] フィールドを prompt=consent,access_type=offline に設定すると、アクセスのスコープの承認をリクエストする前に、毎回同意画面が表示されます。
OIDC プロバイダの /.well-known/openid-configuration ページや JWKS ページへの HTTPS 接続が、信頼できない証明書（自己署名証明書など）によって保護されている場合は、[OIDC プロバイダ証明書] フィールドに OIDC プロバイダが使用する HTTPS 証明書を記載する必要があります。
- OIDC プロバイダの PEM エンコード証明書を base64 でエンコードします。文字列を作成するには、ヘッダーを含めた証明書を base64 でエンコードします。結果の文字列は 1 行に含めます。
- 例: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==
- このフィールドの設定例については、Keycloak による認証をご覧ください。
[Submit] をクリックし、[Identity and Access] タブに戻ります。
コールバック URL を OIDC プロバイダに登録します。

[Identity Profile] タブで [Add] をクリックして、追加の ID プロファイルを作成します。

管理クラスタに ID プロファイルを適用する

ID プロファイルは、作成後にクラスタに適用する必要があります。

[ID プロファイル] タブで、[クラスタに適用] をクリックします。
[管理クラスタ] タブをクリックします。[Profiles] プルダウンリストで、以前に作成したプロファイルの名前を選択します。クラスタに適用する複数のプロファイルを選択できます。
プロファイルのドメイン名を確認します。これは、ID プロバイダプロファイルにマッピングされているドメイン名です。認証されていないユーザーがドメインのパスにアクセスしようとすると、この ID プロバイダを使用してログインするように指示されます。このドメイン名は、インフラストラクチャオペレータによって割り当てられます。

一度に複数のプロファイルを適用する場合は、プロファイルごとに異なるドメイン名を割り当てる必要があります。

ドメイン名の構成について詳しくは、Management Center にアクセスするためのドメイン名を構成するをご覧ください。
プラットフォーム管理者のアクセス権が付与される初期ユーザー名を入力します（例: alice@example.com,bob@example.com）。ユーザー名には、プロファイルで設定されたユーザー接頭辞を付加する必要があります。たとえば、接頭辞が prefix- の場合、[Initial Platform Admin] フィールドのユーザー名は prefix-alice@example.com のようになります。プラットフォーム管理者と承認の詳細については、認可ロールをご覧ください。
設定を適用して数分待ちます。構成が適用されサービスが再起動します。

これで、ドメイン名を使用して Management Center にアクセスできるようになりました。ログインしていない場合は、ログインするために OIDC プロバイダへリダイレクトされます。

API を介して OIDC を構成する

Management Center で OIDC を構成する代わりに、API を介して設定することもできます。OIDC 認証を構成するには、管理クラスタの ClientConfig CRD に認証の詳細を構成する必要があります。これを行うには、次の内容を含むファイルを作成します（例: admin-cluster-oidc-config.yaml）。

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos private mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

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

CONFIGURATION_NAME: 作成する OIDC 構成の名前。
CLIENT_ID: OpenID プロバイダへの認証リクエストを行うクライアントアプリケーションの ID。
CLIENT_SECRET: クライアントアプリケーション用の Secret。
EXTRA_PARAMS: OpenID プロバイダに送信する追加の Key-Value パラメータ（カンマ区切り）。
ISSUER_URI: OpenID に認可リクエストが送信される URL。
SCOPES: OpenID プロバイダに送信する追加のスコープ（カンマ区切り）。
USER_CLAIM: ユーザー名として使用する JWT クレーム。OpenID プロバイダによっては、email や name などの他のクレームを選択できます。ただし、名前が競合しないように、email 以外のクレームには発行者の URL が先頭に付加されます。
GROUPS_CLAIM: ユーザーのグループ情報を保持する OIDC ID トークンに含まれるクレームの名前。
CERT_AUTHORITY_DATA: Base64 でエンコードされた OIDC プロバイダの PEM エンコード証明書（省略可）。不要な場合は削除します。文字列を作成するには、ヘッダーを含めた証明書を base64 でエンコードします。結果の文字列は certificateAuthorityData に 1 行で含めます。

必要な構成でファイルを編集した後、次のコマンドを実行します。

kubectl patch --kubeconfig=ADMIN_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

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

ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
OIDC_CONFIG: 作成した構成ファイルへのパス。

OIDC を設定すると、ユーザーは [ID とアクセス] ページから admin-actl-auth-login-config.yaml をダウンロードできます。

[ID とアクセス] ページで、[ID] タブをクリックし、つづいて [クラスタ] タブをクリックします。
admin という名前のクラスタを見つけて、[構成の詳細を表示] をクリックします。
[ログイン構成をダウンロード] をクリックして、管理クラスタの Kubernetes API サーバーに ID でログインするために使用される構成をダウンロードします。

重要: OIDC の設定後は、緊急時シナリオでのみ ${ADMIN_KUBECONFIG} を使用してください。${ADMIN_KUBECONFIG} は、管理クラスタで匿名の cluster-admin としてユーザーを認証するため、ユーザー名を含む監査ログを保持するには、管理者を含むすべてのユーザーに、各自のアカウントにログインして操作を行うように依頼します。
出力ファイル admin-actl-auth-login-config.yaml には、ユーザーが管理クラスタで認証するために必要な構成が含まれています。admin-actl-auth-login-config.yaml は、クラスタにアクセスする必要がある信頼できるユーザーと共有してください。
admin-actl-auth-login-config.yaml を取得すると、actl auth login ユーザーはコマンドを使用してログインできます。ユーザーがブラウザで正常にログインすると、kubeconfig が作成されます。ユーザーはこの新しいファイルを使用して、連携認証情報を使用しているクラスタにアクセスできます。
```
# Where to store the new kubeconfig
export ADMIN_OIDC_KUBECONFIG=$(pwd)/admin-oidc-kubeconfig

actl auth login --login-config=admin-actl-auth-login-config.yaml --cluster=admin \
  --kubeconfig=${ADMIN_OIDC_KUBECONFIG} \
  --preferred-auth="CONFIGURATION_NAME"
```
CONFIGURATION_NAME は、認証に使用する ID プロファイル名に置き換えます。
ユーザーが、${ADMIN_OIDC_KUBECONFIG} を使用して管理クラスタのリソースにアクセスできるようになりました。次に例を示します。
```
kubectl get pods -n anthos-management-center --kubeconfig=${ADMIN_OIDC_KUBECONFIG}
```
重要: ADMIN_OIDC_KUBECONFIG には認証情報が含まれているため、誰とも共有しないでください。
また、${ADMIN_OIDC_KUBECONFIG} は、次のように actl CLI コマンドを認証するためにも使用できます。次に例を示します。
```
actl platform management-center describe --kubeconfig=${ADMIN_OIDC_KUBECONFIG}
```

認証構成ファイルをリセットする

プラットフォーム管理者が認証設定の誤りで Management Center にアクセスできない場合は、次のコマンドを実行して OIDC 認証を元の設定にリセットし、Management Center の新しいアクセス URL を取得します。

actl auth reset --kubeconfig=ADMIN_KUBECONFIG

# Get the new access URL to management center.
actl platform management-center describe --kubeconfig=ADMIN_KUBECONFIG

次のステップ

認可ロールを構成する方法を確認する。