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

このページでは、署名なしトークンを使用して認証を設定し、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 コンソールにログインできます。