ユーザークラスタで OIDC 認証を構成する

このページはプラットフォーム管理者を対象としています。

このページでは、ユーザークラスタで OpenID Connect（OIDC）認証を有効にし、ロールベースのアクセス制御（RBAC）を設定する方法について説明します。OIDC による認証の詳細については、ベアメタル版 Anthos クラスタでの OIDC による ID 管理をご覧ください。

ユーザークラスタで OIDC 認証を有効にする

OIDC 認証は、ユーザークラスタの作成時に有効にすることも、既存のユーザークラスタに対して有効にすることもできます。OIDC 認証を設定する前提条件は、クラスタに適用する ID プロファイルがすでに存在していることです。ID プロファイルの作成をご覧ください。

クラスタ作成時に ID プロファイルを設定する

Anthos Management Center Console でユーザークラスタを作成する手順については、ユーザークラスタを作成するをご覧ください。[クラスタ構成] ページで、ユーザークラスタを作成するには、[AIS 構成] プルダウンリストから ID プロファイルを選択します。これらの ID プロファイルは、ユーザークラスタに適用されます。

クラスタ作成時に ID プロファイルを適用する

既存のユーザークラスタに ID プロファイルを設定する

[Identity and Access] ページに移動
[Apply profiles to clusters] をクリックします。
[プロファイル] プルダウンリストから、適用する ID プロファイルを選択します。
ID プロファイルを適用するクラスタを [Clusters] プルダウンリストから選択します。

ユーザークラスタに適用されている ID プロファイルを表示する

ユーザークラスタに適用された ID プロファイルは、[ID とアクセス] ページから表示できます。

[Clusters] タブを選択し、表示するユーザークラスタを見つけて、そのユーザークラスタの [View Configuration Details] をクリックします。

ユーザークラスタの ID 構成を表示する

ユーザークラスタのログイン構成をダウンロードする

[View Configuration Details] スライドアウトページで、[Download login config] をクリックします。

ファイルから OIDC 構成を指定する

以下を含むファイルを作成します。このファイルを user-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 running in
      # disconnected 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=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

以下を置き換えます。

USER_CLUSTER_KUBECONFIG: ユーザークラスタ Kubeconfig ファイルへのパス。
OIDC_CONFIG: 作成した構成ファイルへのパス。

ユーザークラスタでの RBAC の設定

このセクションでは、RBAC を設定して個々の名前空間へのアクセスを許可する方法について説明します。詳細については、Kubernetes RBAC のドキュメントをご覧ください。

workload-a と workload-b の 2 つの Namespace があるとします。目標は、Namespace workload-a のリソースをユーザー alice@example.com による読み取りと書き込みを可能にし、workload-b をユーザー bob@example.com による読み取りを可能にすることです。alice@example.com は workload-b にアクセスできず、bob@example.com は workload-a にアクセスできません。

ユーザークラスタに Namespace を作成します。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

各 Namespace へのアクセスを制限するには、各 Namespace に対して権限を定義する必要があります。Kubernetes では、これは Role を作成することで実施できます。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

foo-full-access に定義された verbs は、このロールで Namespace に対して実行できるすべてのアクションを定義します。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

b-read-access のために定義された動詞は、ロールがリソースを照会することのみを許可します。

ユーザーに権限を付与するには、RoleBinding を作成する必要があります。RoleBinding には、個々のユーザーとグループを含めることができます。この例では、個々のユーザーを示します。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: prefix-alice@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

上の RoleBinding（a-full-access-users）は、a-full-access ロールで定義された権限をユーザー alice@example.com に付与します。つまり、ユーザー alice@example.com は workload-a Namespace 内のリソースの読み取りと書き込みが可能になります。

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: bob@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

この RoleBinding（b-read-access-users）は、b-read-access ロールで定義された権限をユーザー bob@example.com に付与します。その結果、ユーザー bob@example.com は workload-b Namespace からのリソースの読み取りのみが可能になります。

OIDC プロバイダによるログイン

ユーザークラスタの管理者は、ログインするユーザークラスタのすべてのユーザーで使用するログイン構成ファイルを取得します。Anthos の Management Center からログイン構成を取得するには、ユーザークラスタのログイン構成ファイルをダウンロードするをご覧ください。また、次のコマンドを実行してログイン構成ファイルを作成することもできます。

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=USER_CLUSTER_NAME-actl-auth-login-config.yaml

ユーザークラスタのユーザーに USER_CLUSTER_NAME-actl-auth-login-config.yaml を配布します。

OIDC プロバイダで認証を行い、コマンドラインの指示に従います。

actl auth login --login-config=USER_CLUSTER_NAME-actl-auth-login-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
  --preferred-auth="CONFIGURATION_NAME"

USER_CLUSTER_NAME を、管理コンソールに表示されるユーザークラスタの名前に置き換えます。--kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig は、出力 Kubeconfig ファイル名です。CONFIGURATION_NAME は、認証に使用する ID プロファイル名に置き換えます。USER_CLUSTER_NAME-actl-auth-login-config.yaml を開いて、プロファイル名を確認します。

次のように、kubectl で新しい Kubeconfig を使用します。

kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A

次のステップ

監査ログの表示方法を確認する。

ユーザー クラスタで OIDC 認証を構成する

ユーザー クラスタで OIDC 認証を有効にする

クラスタ作成時に ID プロファイルを設定する

既存のユーザー クラスタに ID プロファイルを設定する

ユーザー クラスタに適用されている ID プロファイルを表示する

ユーザー クラスタのログイン構成ファイルをダウンロードする