すべての GKE on Azure は、 Google Cloudユーザー ID とサービス アカウント ID を受け入れるように構成されています。受け入れる際には、kubectl から提供された認証情報を検証し、ユーザー ID またはサービス アカウント ID に関連付けられたメールアドレスを取得します。したがって、これらのアカウントの認証情報に userinfo.email OAuth スコープを記述して、正しく認証されるようにする必要があります。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-17 UTC。"],[],[],null,["# About Kubeconfig\n================\n\nThis page is for IT administrators and Operators who want to set up,\nmonitor, and manage cloud infrastructure. To learn more about common roles and\nexample tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nKubernetes configuration file\n-----------------------------\n\nKubernetes uses a YAML file called\n[`kubeconfig`](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)\nto store cluster authentication information for `kubectl`. `kubeconfig` contains\na list of contexts to which `kubectl` refers when running commands. By default,\nthe file is saved at `$HOME/.kube/config`.\n\nA *context* is a group of access parameters. Each context contains a Kubernetes\ncluster, a user, and a namespace. The *current context* is the cluster that is\ncurrently the default for `kubectl`: all `kubectl` commands run against that\ncluster.\n\nAfter you create a cluster, follow\n[Generate a `kubeconfig` entry](/kubernetes-engine/multi-cloud/docs/azure/how-to/configure-cluster-access-for-kubectl#generate_kubeconfig_entry)\nto add the context of the cluster to your local `kubeconfig`.\n\nPrivate endpoints\n-----------------\n\nAll clusters have a canonical endpoint. The endpoint exposes the\nKubernetes API server that `kubectl` and other services use to communicate with\nyour cluster control plane over TCP port 443. On Azure, this endpoint\nis a\nsingle private IP backed by an internal-facing\nload balancer--- for example `10.0.1.5`. This endpoint is not\naccessible on the public internet. You can get the private cluster endpoint\naddress from the `endpoint` field in the output of the\n[`gcloud container azure clusters describe`](/sdk/gcloud/reference/container/azure/clusters/describe)\ncommand.\n\n### Connect gateway endpoint\n\nBy default, the `gcloud container azure clusters get-credentials` command\ngenerates a `kubeconfig` that uses\n[Connect gateway](/anthos/multicluster-management/gateway). With this\n`kubeconfig`, `kubectl` uses Connect, which then securely forwards the\ntraffic to the private endpoint on your behalf. When you use Connect gateway,\nthe endpoint looks like\n`https://connectgateway.googleapis.com/v1/projects/`\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`/memberships/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e,\nwhere \u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e is your project number and\n\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e is your cluster name.\n\nIf you have access to your cluster's private endpoint through your\nVNet, you can connect directly to the private endpoint. To\ngenerate a `kubeconfig` using the private endpoint, use the\n[`gcloud container azure clusters get-credentials --private-endpoint`](/kubernetes-engine/multi-cloud/docs/azure/how-to/configure-cluster-access-for-kubectl#private-endpoint)\ncommand.\n\nAbout authentication for `kubectl`\n----------------------------------\n\nAll GKE on Azure are configured to accept Google Cloud\nuser and service account identities, by validating the credentials presented by\n`kubectl` and retrieving the email address associated with the user or service\naccount identity. As a result, the credentials for those accounts must include\nthe `userinfo.email` OAuth scope in order to successfully authenticate.\n\nWhen you use `gcloud` to set up your environment's `kubeconfig` for a\nnew or existing cluster, `gcloud`\ngives `kubectl` the same credentials used by `gcloud` itself. For example, if\nyou use `gcloud auth login`, your personal credentials are provided to\n`kubectl`, including the `userinfo.email` scope. This allows the\nGKE on Azure to authenticate the `kubectl` client.\n\nOnce users or Google Cloud service accounts are authenticated, they must\nalso be *authorized* to perform any action on a GKE on Azure. The\ncluster admin is responsible for setting up the appropriate\n[Role-Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\nto configure authorization."]]
