Logging in to a cluster from Cloud Console

This page explains how to log in to registered Kubernetes clusters from Google Cloud Console for Anthos customers who have the anthos.googleapis.com API enabled.

Overview

You can log in to registered clusters via Google Cloud Console using a bearer token. Many kinds of bearer tokens, as specified in Kubernetes Authentication, are supported. The easiest method is to create a Kubernetes service account (KSA) in the cluster, and use its bearer token to log in.

All accounts logging in to a cluster need to hold at least the following Kubernetes RBAC roles in the cluster:

Before you begin

You need to complete the following steps once per cluster.

Register the cluster

You need to register your cluster with Google Cloud before you can use Cloud Console to log in to it. Registering a cluster deploys the Connect Agent, a Kubernetes Deployment resource that establishes a long-lived connection between the cluster and Google Cloud. The Connect Agent makes it possible to log in to clusters.

Create and apply node-reader role-based access control (RBAC) role

You need to a create a ClusterRole RBAC resource, node-reader, in the cluster. node-reader grants its users the get, list, and watch permissions on the cluster's nodes, which allow them to see details about the cluster's nodes. Creating this ClusterRole allows you to bind it to users.

  1. Create the node-reader ClusterRole and apply it using the following command:

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

Setting up

You or a cluster administrator should create a service account for each user logging in to the cluster. Using a bearer token is like using a password, so each user should have their own. Logging in with the KSA's bearer token causes all operations to be executed as the KSA, restricted by the RBAC roles held by the KSA.

The KSA needs to hold at least the following RBAC roles in the cluster:

Creating and authorizing a KSA

To create a KSA and bind permissions to it, perform the following steps:

  1. Create the KSA and ClusterRoleBinding resources to bind the view and node-reader Kubernetes RBAC ClusterRoles to the 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 [NODE_READER_BINDING_NAME] \
--clusterrole node-reader --serviceaccount default:${KSA_NAME}

    where:

    • [KSA_NAME] is the name you chose for the KSA.
    • [VIEW_BINDING_NAME] is the name you choose for the view ClusterRoleBinding resource. You can name it anything you want, but you might find it easiest to name it after the KSA.
    • [NODE_READER_BINDING_NAME] is the name you choose for the node-reader ClusterRoleBinding resource. You can also name this anything you want.

  2. Depending on what access the service account should have, bind additional roles to the KSA. See the Kubernetes default roles for some options.

    For example, if you want to deploy a Kubernetes application from Cloud Marketplace, you must bind the cluster-admin role to the KSA:

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

    where [BINDING_NAME] is the name of the cluster role binding for the service account.

Authorizing other accounts

For every other user or service account gaining access to the cluster, you need to create ClusterRoleBinding resources to bind the view and node-reader roles to their account:

  1. To bind the view and node-reader ClusterRoles:

    ACCOUNT_NAME=[ACCOUNT_NAME]
kubectl create clusterrolebinding [VIEW_BINDING_NAME] \
--clusterrole view --serviceaccount default:${ACCOUNT_NAME}
kubectl create clusterrolebinding [NODE_READER_BINDING_NAME] \
--clusterrole node-reader --serviceaccount default:${ACCOUNT_NAME}

    where:

    • [VIEW_BINDING_NAME] is the name you choose for the view ClusterRoleBinding resource. You can name it anything you want, but you might find it easiest to name it after the user or service account.
    • [NODE_READER_BINDING_NAME] is the name you choose for the view ClusterRoleBinding resource. You can also name this anything you want.
    • [ACCOUNT_NAME] is the email address of the user or service account.

  2. Bind additional roles, depending on what access the account should have. See the Kubernetes default roles for some options.

    For example, to bind the cluster-admin role:

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

    where [BINDING_NAME] is the name of the cluster role binding for the service account.

Getting the KSA's bearer token

To acquire the KSA's bearer token, run the following command:

SECRET_NAME=$(kubectl get serviceaccount [KSA_NAME] -o jsonpath='{$.secrets[0].name}')
kubectl get secret ${SECRET_NAME} -o jsonpath='{$.data.token}' | base64 --decode

where [KSA_NAME] is the name you choose for the KSA.

From this command's output, copy the token and save it for use in the next section.

Logging in to a cluster

To log in to a cluster, perform the following steps:

  1. Visit the GKE menu in Cloud Console.

    Visit the GKE menu

  2. From the list of clusters, click the Login button beside the registered cluster.

  3. Choose how you'd like to log in:

    1. If you are using a KSA token to log in, select Token, fill the Token field with the KSA's bearer token, and then click Login.
    2. If you are using basic authentication, select Basic authentication, fill the Username and Password fields, and then click Login.
    3. If you are using OpenID Connect (OIDC), select OpenID Connect, then click Login.

If you authenticate successfully, you are able to inspect the cluster and get details about its nodes.

What's next