Before you can interact with Google Cloud APIs and services, you need to prove that you are who you say you are. This process of proving your identity is known as authentication.
To authenticate to Google Cloud, you must provide credentials as evidence of your identity. For example, to use a service, you might authenticate using credentials such as a password and a one-time code.
Google Cloud refers to authenticated users as principals. When you attempt to access a resource such as a Google Cloud project or storage bucket, Google Cloud checks what level of access your principal has to the requested resource. This process is called authorization, and is handled by a system called Identity and Access Management (IAM).
These same concepts apply to code performing automated tasks on your behalf, which are known as workloads. A workload must provide credentials to prove its identity and authenticate as a principal, after which Google Cloud can determine what level of access the workload has to the resources it has requested.
Principal types
There are different types of principals that you can authenticate as. You might even use different principal types at different stages of a task, or across different development environments.
The primary principal types and the credentials they require to authenticate include the following:
User accounts: These are Google Accounts that are for humans to do interactive work, such as incidental administrative tasks, non-programmatic configuration of Google Cloud services, testing, experimenting, and observability.
You authenticate as a user account with user credentials, such as a password and one-time code.
Service accounts: These are accounts internal to Google Cloud that workloads can use to access services or resources. You typically don't authenticate as a service account directly. Instead, you attach a service account to a resource such as a Compute Engine VM, or use service account impersonation.
For most scenarios, we recommend using short-lived service account credentials to authenticate a service account.
Federated identities: These are identities that reference user or service accounts in an external identity provider. There are two types of federated identities supported by Google Cloud, which have similar names:
Workforce Identity Federation: Lets human users sign into Google Cloud with identities managed by an external identity provider. If your organization already has single sign-on (SSO) set up, you might use this type of identity to authenticate to Google Cloud.
Your identity provider must support OpenID Connect (OIDC) or SAML 2.0 to use Workforce Identity Federation.
Workload Identity Federation: Lets workloads running external to Google Cloud operate on Google Cloud resources.
You can use Workload Identity Federation with workloads that authenticate using X.509 client certificates; that run on Amazon Web Services (AWS) or Azure; on-premises Active Directory; deployment services, such as GitHub and GitLab; and with any identity provider that supports OpenID Connect (OIDC) or Security Assertion Markup Language (SAML) V2.0.
To learn more about these and other supported principal types in Google Cloud, see Principal types.
Configure your Google Cloud organization for authentication
When setting up authentication for your Google Cloud organization, you might need to integrate existing systems and workflows into Google Cloud:
If you have an existing identity provider that you want to use, you need to set up Workforce Identity Federation.
If you have workloads running outside of Google Cloud that need access to Google Cloud resources, you need to set up Workload Identity Federation.
We recommend that you also do the following to help secure your Google Cloud environment:
Make sure multi-factor authentication is enabled for your users.
Check if you need to change reauthentication settings.
Create policies for managing API keys.
Create policies for managing service account keys.
Authenticate humans and workloads
How you authenticate to Google Cloud depends on the APIs and services that you're using, and the way in which you interact with those APIs and services.
Authenticate humans
When performing manual, interactive work such as incidental administrative tasks, setting up resources, changing configurations, experimenting, and browsing logs, you use your user account's credentials to authenticate.
Console
For interactive work in the Google Cloud console, you authenticate by signing in to the web interface with your user credentials.
Go to the Google Cloud console
The same credentials for your Google Cloud console session are used for Cloud Shell, where you can access the gcloud CLI.
gcloud
After you install the gcloud CLI on your local device, you can use your user credentials to authenticate to Google Cloud by running the following command in your terminal:
gcloud auth login
After you authenticate, subsequent gcloud commands use the signed-in
principal to make their requests.
For authenticating with Workforce Identity Federation credentials, Workload Identity Federation credentials, or service account keys, see Authenticate for using the gcloud CLI.
Authenticate workloads
Whether you're developing and running code on your local device, in Google Cloud, on-premises, or in another cloud, the most flexible and portable way to authenticate your workload is to provide credentials through a mechanism called Application Default Credentials (ADC).
Libraries that implement ADC (such as the Google Cloud client libraries) check known locations in the environment they're run in for credentials. This means that, if you change where your code runs, you don't need to change the code itself—only the credentials that are used for that environment.
For example, when developing locally, you can set your environment so that ADC makes use of your user credentials for authentication. When your code is ready for production, you can deploy it unchanged to a Compute Engine VM instance, and set the environment to use short-lived service account credentials to authenticate instead.
You can't use ADC to authenticate in the following scenarios:
When authenticating the gcloud CLI.
When using an API key. API keys can only be used with specific APIs.
To learn how to set up ADC for specific environments, see Set up Application Default Credentials.
What's next
Learn more about the different authentication methods for Google Cloud.
To understand how you control what a principal can access in Google Cloud, see Authorization and access control.