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.