About Kubeconfig

Kubernetes configuration file

Kubernetes uses a YAML file called kubeconfig to store cluster authentication information for kubectl. kubeconfig contains a list of contexts to which kubectl refers when running commands. By default, the file is saved at $HOME/.kube/config.

A context is a group of access parameters. Each context contains a Kubernetes cluster, a user, and a namespace. The current context is the cluster that is currently the default for kubectl: all kubectl commands run against that cluster.

After you create a cluster, follow Generate a kubeconfig entry to add the context of the cluster to your local kubeconfig.

Private endpoints

All clusters have a canonical endpoint. The endpoint exposes the Kubernetes API server that kubectl and other services use to communicate with your cluster control plane over TCP port 443. On AWS, this endpoint is a DNS name that is only resolvable inside the cluster— for example gke-abcdefghijk-cp-ffabcdef123456.elb.us-west-1.amazonaws.com. This endpoint is not accessible on the public internet. You can get the private cluster endpoint address from the endpoint field in the output of the gcloud container aws clusters describe command.

Connect gateway endpoint

By default, the gcloud container aws clusters get-credentials command generates a kubeconfig that uses Connect gateway. With this kubeconfig, kubectl uses Connect, which then securely forwards the traffic to the private endpoint on your behalf. When you use Connect gateway, the endpoint looks like https://connectgateway.googleapis.com/v1/projects/PROJECT_NUMBER/memberships/CLUSTER_NAME, where PROJECT_NUMBER is your project number and CLUSTER_NAME is your cluster name.

If you have access to your cluster's private endpoint through your VPC, you can connect directly to the private endpoint. To generate a kubeconfig using the private endpoint, use the gcloud container aws clusters get-credentials --private-endpoint command.

About authentication for kubectl

All GKE on AWS are configured to accept Google Cloud user and service account identities, by validating the credentials presented by kubectl and retrieving the email address associated with the user or service account identity. As a result, the credentials for those accounts must include the userinfo.email OAuth scope in order to successfully authenticate.

When you use gcloud to set up your environment's kubeconfig for a new or existing cluster, gcloud gives kubectl the same credentials used by gcloud itself. For example, if you use gcloud auth login, your personal credentials are provided to kubectl, including the userinfo.email scope. This allows the GKE on AWS to authenticate the kubectl client.

Once users or Google Cloud service accounts are authenticated, they must also be authorized to perform any action on a GKE on AWS. The cluster admin is responsible for setting up the appropriate Role-Based Access Control to configure authorization.