About Kubeconfig

This page is for IT administrators and Operators who want to set up, monitor, and manage cloud infrastructure. To learn more about common roles and example tasks that we reference in Google Cloud content, see Common GKE Enterprise user roles and tasks.

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 Azure, this endpoint is a single private IP backed by an internal-facing load balancer— for example 10.0.1.5. 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 azure clusters describe command.

Connect gateway endpoint

By default, the gcloud container azure 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 VNet, you can connect directly to the private endpoint. To generate a kubeconfig using the private endpoint, use the gcloud container azure clusters get-credentials --private-endpoint command.

About authentication for kubectl

All GKE on Azure 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 Azure 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 Azure. The cluster admin is responsible for setting up the appropriate Role-Based Access Control to configure authorization.