ID とセキュリティを構成する

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

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

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

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

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

ユーザークラスタの作成方法については、Management Center UI からユーザークラスタを作成するをご覧ください。[クラスタ構成] ページで、ユーザークラスタを作成するには、[AIS 構成] プルダウンリストから 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 isolated 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 UI からログイン構成を取得するには、ユーザークラスタのログイン構成ファイルをダウンロードするをご覧ください。また、次のコマンドを実行してログイン構成ファイルを作成することもできます。

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=user-cluster-anthos-config.yaml

ユーザークラスタのユーザーに user-cluster-anthos-config.yaml を配布します。

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

actl auth login --login-config=user-cluster-anthos-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./user-cluster-oidc-kubeconfig

USER_CLUSTER_NAME を、管理コンソールに表示されるユーザークラスタの名前に置き換えます。--kubeconfig=user-cluster-oidc-kubeconfig は、出力 Kubeconfig ファイル名です。

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

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

Google SSO での認証

Google SSO は分離モードでは使用できません。このセクションは、デモとテストのみを目的としています。Google SSO を使用する場合は、クラスタとブラウザの両方が Google の SSO サーバーにアクセスできる必要があります。Google の SSO サーバーでは、ユーザークラスタへの接続は必要ありません。

Google Cloud Console にログインし、有効なプロジェクトを選択します。
[API とサービス] > [OAuth 同意画面] のセクションにアクセスします。
新しい OAuth 同意画面を作成します。この情報は通常、ユーザーに表示されます。
1. [アプリケーションのホームページ] を管理 URL に設定します。
[API とサービス] > [認証情報] で、次の操作を行います。
1. [認証情報を作成] をクリックします。
2. 新しい OAuth クライアント ID を作成します。
3. [アプリケーションの種類] を [ウェブアプリケーション] に設定します。
4. 関連する名前を選択します。
5. JavaScript 生成元に https://anthos.example.com を設定します（https://anthos.example.com は Management Center のドメイン名であることを前提としています）。
6. [承認済みのリダイレクト URI] には、次のように設定します。
  - https://anthos.example.com/_gcp_anthos_oidc_callback
  - http://localhost:9879/callback
ClientID とクライアント Secret を AdminUI 構成にコピーします。
OIDC プロバイダの URL を https://accounts.google.com に設定します。
Username Claim を email に、Scopes を openid email に設定します。
追加パラメータを prompt=consent,access_type=offline に設定します。設定しないと、Kubernetes API サーバーでログインできません。
プラットフォーム管理者権限を付与する、最初のメールアドレスのリスト（複数の場合はカンマで区切ります）を追加します。
[Save] をクリックします。

Google SSO

監査ロギング

Anthos プライベートモードでは、Kubernetes の監査が有効になっており、プラットフォームに対する管理を目的としたアクセスとアクションを確認できます。

現在、監査ロギングは、保持期間、リフレッシュレート、チャンクサイズなどのパラメータ向けにカスタマイズできません。監査レベルは Metadata です。これは、リクエストメタデータ（リクエストのユーザー、タイムスタンプ、リソース、動詞）をログに記録しますが、リクエストとレスポンスの本文は記録しません。

Anthos プライベートモードでは、デフォルトで監査ログが有効になっています。監査ログへのアクセスに関する詳細な手順については、ロギングとモニタリングをご覧ください。

ID とセキュリティを構成する

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

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

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

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

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