署名なしトークンを使用して認証する

このページでは、署名なしトークンを使用して認証を設定し、Google Cloud の外部で登録されているクラスタにログインする方法について説明します。設定後は、クラスタ管理者が Google Cloud コンソールからクラスタにログインできます。Kubernetes 認証で指定された、さまざまな種類の署名なしトークンがサポートされています。最も簡単な方法は、クラスタ内に Kubernetes サービス アカウント(KSA)を作成し、その署名なしトークンを使用してログインすることです。

他の認証方式

署名なしトークンを使用した認証の設定に代えて、組織のニーズに応じて次のいずれかの認証方式を設定できます。

  • Google ID。ユーザーは、Google Cloud ID を使用してログインできます。すでにユーザーが Google ID で Google Cloud にアクセスできる場合は、この方法を使用します。

  • OIDC ID プロバイダを使用するようにクラスタが構成されている場合は、それを使用して Google Cloud コンソールからそのクラスタを認証できます。GKE クラスタに対する OIDC の設定方法については、以下のガイドをご覧ください。

    • OIDC で GKE Identity Service のクラスタを構成するこのガイドでは、すべての GKE クラスタタイプについて、クラスタごとに OIDC 認証を設定する方法を説明します。
    • フリートの GKE Identity Service を設定する。この方法を使用すると、サポートされているクラスタタイプのフリートレベルで OIDC を設定できます。フリートレベルの設定は、Google Cloud 上の GKE クラスタ、すべての GKE クラスタタイプ、AWS の EKS 接続クラスタでサポートされています。

Google 提供の認証方法が組織に適していない場合は、このページの手順に沿って、署名なしトークンを使用した認証を設定します。

Google Cloud コンソールを介してアクセスするための IAM ロールを付与する

Google Cloud コンソールを使用して接続されたクラスタを表示するには、少なくとも次の IAM ロールが必要です。

  • roles/container.viewer。このロールを使用すると、GKE クラスタページを含む Google Cloud コンソールでコンテナ リソースを表示できます。このロールに含まれる権限の詳細については、IAM のドキュメントの Kubernetes Engine のロールをご覧ください。

  • roles/gkehub.viewer。このロールを使用すると、ユーザーは Google Cloud コンソールで Google Cloud 外のクラスタを表示できます。フリートに Google Cloud 外のクラスタが含まれていない場合、このロールは必要ありません。このロールに含まれる権限の詳細については、IAM のドキュメントの GKE Hub のロールをご覧ください。

以下のコマンドを実行して、これらのロールを付与します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/gkehub.viewer

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

  • PROJECT_ID: フリート ホスト プロジェクトのプロジェクト ID。

  • EMAIL_ADDRESS: ユーザーの Google Cloud アカウントに関連付けられたメールアドレス。

IAM ロールの付与について詳しくは、IAM のドキュメントのプロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

ロールベース アクセス制御を構成する

クラスタへのアクセスは、Kubernetes のロールベースのアクセス制御(RBAC)を使用して管理されます。

KSA は、ユーザーまたはクラスタ管理者が、クラスタにログインするユーザーごとに作成することをおすすめします。署名なしトークンの使用は、パスワードの使用と同じようなものであるため、各ユーザーは自分のアカウントを持つ必要があります。KSA の署名なしトークンを使用してログインすると、すべてのオペレーションが KSA として実行され、KSA が保持する RBAC ロールによって制限されます。

KSA は、コンソールからクラスタにアクセスするために、クラスタ内に少なくとも次の RBAC ロールを保持する必要があります。

cloud-console-reader RBAC ロールを作成して適用する

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

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

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

このロールは、次のセクションで説明するように KSA に付与できます。

KSA を作成して承認する

kubectl

KSA を作成して、それに権限をバインドするには、次の手順を行います。

  1. KSA および ClusterRoleBinding リソースを作成して view および cloud-console-reader Kubernetes RBAC ClusterRoles を KSA にバインドします。

    KSA_NAME=KSA_NAME
    kubectl create serviceaccount ${KSA_NAME}
    kubectl create clusterrolebinding VIEW_BINDING_NAME \
       --clusterrole view --serviceaccount default:${KSA_NAME}
    kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
       --clusterrole cloud-console-reader --serviceaccount default:${KSA_NAME}
    

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

    • KSA_NAME: KSA に付ける名前。
    • VIEW_BINDING_NAME: view ClusterRoleBinding リソースに付ける名前。任意の名前を付けることができますが、KSA にちなんだ名前を付けるのが最も簡単です。
    • CLOUD_CONSOLE_READER_BINDING_NAME: cloud-console-reader ClusterRoleBinding リソースに付ける名前。任意の名前を付けることもできます。
  2. サービス アカウントに必要な権限に応じて、追加のロールを KSA にバインドします。オプションについては、Kubernetes のデフォルトのロールをご覧ください。

    たとえば、Cloud Marketplace から Kubernetes アプリケーションをデプロイする場合は、cluster-admin ロールを KSA にバインドします。

    kubectl create clusterrolebinding BINDING_NAME \
       --clusterrole cluster-admin --serviceaccount default:KSA_NAME
    

    BINDING_NAME は、サービス アカウントのクラスタ ロール バインディングの名前に置き換えます。

他のアカウントを承認する

kubectl

クラスタにアクセスする他のすべてのユーザーまたはサービス アカウントが ClusterRoleBinding リソースを作成して、view ロールと cloud-console-reader ロールをそれらのアカウントにバインドします。

  1. viewcloud-console-reader ClusterRoles をバインドします。

    ACCOUNT_NAME=ACCOUNT_NAME
    kubectl create clusterrolebinding VIEW_BINDING_NAME \
       --clusterrole view --serviceaccount default:${ACCOUNT_NAME}
    kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
       --clusterrole cloud-console-reader --serviceaccount default:${ACCOUNT_NAME}
    

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

    • ACCOUNT_NAME: Kubernetes サービス アカウント
    • VIEW_BINDING_NAME: view ClusterRoleBinding リソースに付ける名前。任意の名前を付けることができますが、ユーザーまたはサービス アカウントにちなんだ名前を付けるのが最も簡単です。
    • CLOUD_CONSOLE_READER_BINDING_NAME: view ClusterRoleBinding リソースに付ける名前。任意の名前を付けることもできます。
  2. アカウントに付与するアクセス権に応じて、追加のロールをバインドします。オプションについては、Kubernetes のデフォルトのロールをご覧ください。

    たとえば、cluster-admin ロールをバインドするには、次のコマンドを実行します。

    kubectl create clusterrolebinding BINDING_NAME \
       --clusterrole cluster-admin --serviceaccount default:ACCOUNT_NAME
    

    BINDING_NAME は、サービス アカウントのクラスタ ロール バインディングの名前に置き換えます。

KSA の署名なしトークンを取得する

kubectl

KSA の署名なしトークンを取得するには、次のコマンドを実行します。

SECRET_NAME=KSA_NAME-token

kubectl apply -f - << __EOF__
apiVersion: v1
kind: Secret
metadata:
  name: "${SECRET_NAME}"
  annotations:
    kubernetes.io/service-account.name: "${KSA_NAME}"
type: kubernetes.io/service-account-token
__EOF__

until [[ $(kubectl get -o=jsonpath="{.data.token}" "secret/${SECRET_NAME}") ]]; do
  echo "waiting for token..." >&2;
  sleep 1;
done

kubectl get secret ${SECRET_NAME} -o jsonpath='{$.data.token}' | base64 --decode

KSA_NAME は、KSA に付ける名前に置き換えます。

このコマンドの出力から、トークンをコピーして保存します。これにより、ユーザーはトークンを使用して Google Cloud コンソールにログインできます。