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 権限も必要です。