Authentication overview

This page describes how GKE on Azure handles authentication to Google Cloud and user authentication to your clusters.

How GKE on Azure connects to Azure

The GKE Multi-Cloud API authenticates to Azure with an AzureClient object. When you create a client, Google generates an X.509 key pair. You upload the public key to Azure Active Directory (Azure AD).

For more information, see Create an AzureClient.

Authentication

GKE Multi-Cloud API authentication

You use the GKE Multi-Cloud API to create, update, and delete clusters and node pools. As with other Google Cloud APIs, you can use this API with REST, Google Cloud CLI, or the Google Cloud console.

For more information, see Google Cloud authentication overview and the GKE Multi-Cloud API reference documentation.

Kubernetes API authentication

You can use the kubectl command-line tool to perform cluster operations such as deploying a workload and configuring a load balancer. The kubectl tool connects to the Kubernetes API on your cluster's control plane. To call this API, you need to authenticate with authorized credentials.

To get credentials, you can use one of the following methods:

  • Google Identity, which lets users log in using their Google Cloud identity. Use this option if your users already have access to Google Cloud with a Google Identity.

  • GKE Identity Service, which lets users log in using OpenID Connect (OIDC).

GKE Identity Service lets you use identity providers such as Okta, Active Directory Federation Services (ADFS), or any OIDC compliant identity provider.

Authorization

GKE on Azure has two methods for access control, the GKE Multi-Cloud API and role-based access control (RBAC). This section describes the differences between these methods.

It's best to take a layered approach to protecting your clusters and workloads. You can apply the principle of least privilege to the level of access that you provide to your users and workloads. You might need to make tradeoffs to allow the right level of flexibility and security.

GKE Multi-Cloud API access control

The GKE Multi-Cloud API lets cluster administrators create, update, and delete clusters and node pools. You manage permissions for the API with Identity and Access Management (IAM). To use the API, users must have the appropriate permissions. For the permissions necessary for each operation, see API roles and permissions. IAM lets you define roles and assign them to principals. A role is a collection of permissions, and when assigned to a principal, controls access to one or more Google Cloud resources.

When you create a cluster or node pool in an organization, folder, or project, users with appropriate permissions in that organization, folder, or project can modify it. For example, if you give a user a cluster deletion permission at a Google Cloud project level, that user can delete any cluster in that project. For more information, see Google Cloud resource hierarchy and Creating IAM policies.

Kubernetes API access control

The Kubernetes API lets you manage Kubernetes objects. To manage access control on the Kubernetes API, you use role-based access control (RBAC). For more information, see Configuring role-based access control in the GKE documentation.

Administrator access

When you use the gcloud CLI to create a cluster, by default the GKE Multi-Cloud API adds your user account as an administrator and creates appropriate RBAC policies that grant you full administrative access to the cluster. To configure different users, pass the --admin-users flag when you create or update a cluster. When you use the --admin-users flag, you must include all users that can administer the cluster. The gcloud CLI doesn't include the user that creates the cluster.

You can also add admin users using the Google Cloud console. For more information, see Update your cluster.

To see the configuration of your cluster's access, run the following command:

kubectl describe clusterrolebinding gke-multicloud-cluster-admin

In addition to the RBAC policies to access the Kubernetes API server, if an admin user isn't a project owner, you need to grant specific IAM roles that let the admin users authenticate using their Google identity. For more information about how to connect to the cluster, see Connect and authenticate to your cluster.

What's next