GKE Identity Service のユーザーアクセスを設定する

このドキュメントは、フリートレベルの GKE Identity Service のクラスタを構成するクラスタ管理者か OIDC で GKE Identity Service のクラスタを構成するの手順に沿って GKE Identity Service のクラスタをすでに構成しているクラスタ管理者を対象としています。ここでは、組織のデベロッパーと他のクラスタユーザー用に構成したクラスタへのアクセスを設定（および制限）する方法を説明しています。

ファイルアクセスを使用して認証する

クラスタを構成したら、ログイン構成ファイルを生成してクラスタユーザーに配布する必要があります。このファイルは、GKE Identity Service を使用したクラスタへのアクセスで説明されているように、ユーザーが選択したプロバイダでコマンドラインからクラスタにログインできるようにします。

OIDC プロバイダの場合にのみ、ユーザーはログインファイルなしで Google Cloud コンソールからクラスタにログインすることもできます。詳しくは、Google Cloud コンソールからクラスタを操作するをご覧ください。

ログイン構成ファイルを生成する

コンソール

（フリートレベルの設定のみ）

表示された gcloud コマンドをコピーして実行し、ファイルを生成します。

gcloud

gcloud CLI を使用してクラスタを構成した場合や、ファイルを再度生成する必要がある場合は、次のコマンドを実行してファイルを生成します。

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

ここで、KUBECONFIG はクラスタの kubeconfig ファイルのパスです。kubeconfig に複数のコンテキストがある場合は、現行のコンテキストが使用されます。コマンドを実行する前に、現在のコンテキストを正しいクラスタにリセットすることが必要になる場合があります。

その他のオプションパラメータなど、このコマンドのリファレンス一覧の詳細については、Google Cloud CLI リファレンスガイドをご覧ください。

ログイン構成ファイルのデフォルト名は kubectl-anthos-config.yaml です。これは、Google Cloud CLI がファイルを使用してログインするときに想定する名前です。これをデフォルト以外の名前に変更する場合は、ログイン構成の配布の関連セクションをご覧ください。

ユーザーアクセスに関する問題のトラブルシューティングについては、ユーザーアクセスの問題のトラブルシューティングをご覧ください。

ログイン構成を配布する

構成ファイルは、次のような方法で配布できます。

アクセス可能な URL でファイルをホスティングする。gcloud anthos auth login を実行するときに --login-config フラグを使用してこの場所を指定するだけで、Google Cloud CLI がファイルを取得するように設定できます。

安全なホストでファイルをホスティングすることを検討してください。PEM 証明書を使用して安全な HTTPS アクセスを確立する方法については、gcloud CLI の --login-config-cert フラグをご覧ください。
ファイルを保存したローカルマシン上の場所に関する情報とともに、各ユーザーにファイルを手動で提供する。Google Cloud CLI では、OS 固有のデフォルトの場所にファイルが存在することを想定しています。ファイルにデフォルト以外の名前または場所が指定されている場合、クラスタにコマンドを実行するときに、ユーザーは --login-config フラグを使用して構成ファイルの場所を指定する必要があります。ユーザーがファイルを保存する手順については、GKE Identity Service を使用したクラスタへのアクセスをご覧ください。
内部ツールを使用して認証構成ファイルを各ユーザーのマシンに push します。Google Cloud CLI では、ユーザーの OS 別に次の場所にファイルがあると想定しています。
Linux
```
$HOME/.config/google/anthos/kubectl-anthos-config.yaml
```
macOS
```
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
```
Windows
```
%APPDATA%\google\anthos\kubectl-anthos-config.yaml
```

FQDN アクセスを使用して認証する（推奨）

構成ファイルをすべてのユーザーに配布する代わりに、FQDN アクセスを使用してユーザーログインアクセスを設定できます。ユーザーは、完全修飾ドメイン名（FQDN）を使用して GKE Identity Service サーバーで直接認証できます。SAML プロバイダの場合、ユーザーのログインアクセスは、この認証プロセスでのみサポートされます。

FQDN をユーザーと共有する

クラスタ管理者は、構成ファイルの代わりに GKE Identity Service サーバーの FQDN をユーザーと共有できます。ユーザーはこの FQDN を使用してクラスタにログインできます。ログインの URL 形式は APISERVER-URL です。この URL には、クラスタサーバーの FQDN が含まれます。

APISERVER-URL の形式の例は https://cluster.company.com です。

信頼できる SNI 証明書を使用したユーザーログインアクセス

SNI 証明書は、企業デバイスにすでに存在する信頼できる証明書を活用することで、クラスタへのアクセスを簡素化します。管理者は、クラスタの作成時にこの証明書を使用します。ユーザーは、管理者から提供された FQDN を使用してクラスタにログインする必要があります。認証が成功した後にトークンが保存される安全な kubeconfig ファイルを使用することもできます。

次のコマンドを実行する前に、ユーザーログインアクティビティが実行されるデバイスで、GKE Identity Service サーバーで使用される証明書が信頼されていることを確認します。

gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE

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

APISERVER-URL: GKE Identity Service サーバーの FQDN。
OUTPUT_FILE: このフラグは、kubeconfig ファイルがデフォルト以外の場所にある場合に使用します。このフラグを省略すると、認証トークンがデフォルトの場所にある kubeconfig ファイルに追加されます。例: --kubeconfig /path/to/custom.kubeconfig。

クラスタ CA が発行した証明書を使用したユーザーログインアクセス

ユーザーがクラスタレベルで信頼できる SNI 証明書を使用しない場合、ID サービスで使用される証明書はクラスタの認証局（CA）によって発行されます。管理者は、この CA 証明書をユーザーに配布します。クラスタの CA 証明書を使用して次のコマンドを実行し、クラスタにログインします。

gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

Identity Service オプションを構成する

この認証方法では、トークンの有効期間を構成するオプションを利用できます。ClientConfig CR で、新しいパラメータ sessionDuration とともに新しいセクション IdentityServiceOptions が導入されました。これにより、ユーザーはトークンの有効期間（分単位）を構成できます。sessionDuration パラメータの最小値は 15 分、最大値は 1,440 分（24 時間）です。

ClientConfig CR の例を次に示します。

spec:
    IdentityServiceOptions:
      sessionDuration: INT

ここで、INT はセッション継続時間（分単位）です。

ロールベースアクセス制御（RBAC）を設定する

多くの場合、認証では、Kubernetes のロールベースアクセス制御（RBAC）と組み合わせて、認証済みユーザーとサービスアカウントに対する、より細かいアクセス制御が提供されます。可能であれば、ユーザー ID ではなく、グループ名を使用する RBAC ポリシーを作成することをおすすめします。RBAC ポリシーをグループに明示的にリンクすることで、ID プロバイダでユーザーアクセスを完全に管理できるようになるため、ユーザーの権限が変更されるたびにクラスタを更新する必要がなくなります。なお、OIDC のセキュリティグループのメンバーシップに基づいたアクセス制御を構成するには、ID プロバイダからグループメンバー情報を取得できるように GKE Identity Service を設定する必要があります。

たとえば、特定の認証済みユーザーにクラスタの Pod へのアクセスを許可する場合は、次の例のように、これらのリソースへのアクセスを許可する ClusterRole を作成します。

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

対応する ClusterRoleBinding を作成して、関連するユーザー（ここでは、us-east1-cluster-admins セキュリティグループのメンバーおよび ID が u98523-4509823 のユーザー）に ClusterRole での権限を付与します。

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

次の例では、この ClusterRoleBinding により、ClusterRole の権限が ID 12345678-BBBb-cCCCC-0000-123456789012 の関連グループに付与されています。この設定は Azure AD プロバイダにのみ関連し、Bare Metal クラスタ向けの Google Distributed Cloud Virtual で使用できます。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

RBAC の使用の詳細については、ロールベースアクセス制御を構成すると、RBAC 認証の使用をご覧ください。

Google Cloud コンソールでアクセスするための RBAC ロールを作成する

OIDC プロバイダを使用して認証されたユーザーは、コマンドラインだけでなく、Google Cloud コンソールからクラスタにログインできます。

Google Cloud コンソールでクラスタリソースにアクセスする認証済みユーザーは、関連する Kubernetes 権限を持っている必要があります。そうしたユーザーにクラスタ管理者などのより広範な権限を付与しない場合は、クラスタのノード、永続ボリューム、Pod、ストレージクラスを表示するために必要な最小限の権限を含むカスタム RBAC ロールを作成します。この一連の権限を定義するには、クラスタに ClusterRole RBAC リソース（cloud-console-reader）を作成します。

cloud-console-reader は、クラスタのノード、永続ボリューム、Pod、ストレージクラスに対する get、list、watch の権限をユーザーに付与し、これらのリソースの詳細情報を確認できるようにします。

kubectl

cloud-console-reader ClusterRole を作成してクラスタに適用するには、次のコマンドを実行します。

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

次に、前のセクションで説明したように、権限ポリシーの設定時にこの ClusterRole をユーザーに付与できます。Google Cloud コンソールでクラスタを表示するための IAM 権限も必要です。

GKE Identity Service のユーザー アクセスを設定する

ファイル アクセスを使用して認証する