Choosing an authentication method
1. Choosing an authentication method
SPEAKER: There are multiple ways to authenticate to Google Cloud APIs from an application. This diagram will help you choose which method you should use based on your situation. The first question that you need to answer is whether your application is running on Google Cloud. If your app is running on Google Cloud and your app is not running on Google Kubernetes Engine, there are two recommended methods for authentication. For development work in a local environment, you should use the gcloud auth application-default login command to let the application use your user credentials. For applications that are not running in a local development environment, attach a service account directly to the compute or serverless instance on Google Cloud. If your application is running on GKE, Workload Identity is the best solution. Workload Identity allows workloads in your GKE clusters to impersonate IAM service accounts to access Google Cloud APIs. If you're not running your application on Google Cloud, you need to decide whether federation is possible. You're able to set up Workload Identity Federation for workloads running in other clouds or running on-premises as long as the cloud provider or on-premises deployment can generate an ID token. Workload Identity Federation lets you exchange an external provider token for a Google Cloud access token. With that access token, you can impersonate a regular service account and its permissions without requiring a service account key. If federation is not possible, your last resort is to use service account keys. Take great care to secure any service account keys that are used. Cloud client libraries use Application Default Credentials, or ADC, to find your application's credentials and let you access Google Cloud APIs. ADC uses a specific process to search for the application credentials. Your code will not need to change when you move it from your local development environment to a Google Cloud service, like Cloud Run or GKE. Apps not running in Google Cloud can also use the same code. ADC checks credential locations in the following order. The existence of a GOOGLE_APPLICATION_CREDENTIALS environment variable is checked first. If the environment variable is set, ADC will use the service account file at the path specified by the environment variable. If the environment variable isn't set, ADC next checks a well-known location for user credentials that are set using the gcloud CLI. Finally, ADC will use an attached service account. Some services let you attach service accounts to a specific resource on the service. For example, Cloud Run allows the attachment of a service account to a specific service or function. ADC will use the service account attached to the service or function. If there is not a service account attached to the specific resource, ADC will use the default service account for the service being used, like Compute Engine, GKE, or Cloud Run. If no credentials are found during all these checks, an error will be raised. The example shows a Python function that automatically finds the credentials. The code makes an authenticated API request without specifying credentials. So ADC will search for the credentials. Returning to our diagram, we explore each of the authentication methods. When you're using a local development environment, you can use the gcloud CLI command, gcloud auth application-default login. This command generates a JSON file containing user access credentials and places it in the well-known location for ADC defined. These user access credentials allow the application to make API calls with your user identity. The JSON file is secure, does not include your password, and is time-bound. If you have used the gcloud CLI before, you might be familiar with a similar command, gcloud auth login. gcloud auth login uses your credentials when you run gcloud CLI commands. But gcloud auth application-default login uses your credentials when calling from your code. The preferred way to call Google Cloud APIs from applications running on Google Cloud serverless products or Compute Engine is to use attached service accounts. When you run on a Compute Engine VM, replace the default service account for the VM with the service account created specifically for the application. That service account should be given only the privileges needed by your application. Similarly, when you deploy a service to Cloud Run or create a function on Cloud Run functions, attach a service account to the service or function. Attaching a user-managed service account is the preferred way to provide credentials to ADC for production code that runs on Google Cloud. If you're running your application in GKE, Workload Identity is the recommended way to access Google Cloud APIs in a secure and manageable way. Workload Identity allows a Kubernetes service account in your GKE cluster to act as the IAM service account when your application calls Google Cloud APIs. Using Workload Identity lets you assign distinct, fine-grained identities and authorization for each application in your cluster. Workload Identity will automatically exchange Kubernetes service account tokens for IAM tokens when calling Google Cloud APIs. The first step for using Workload Identity is to enable Workload Identity on your cluster. You then allow the Kubernetes service account to impersonate the IAM service account you have created. ADC will manage the rest. Sometimes you need to run applications outside of Google Cloud, whether you're running multi-cloud or on-premises. Identity federation for your workloads lets you grant on-premises or multi-cloud workloads access to Google Cloud APIs without requiring a service account key. Traditionally, applications running outside Google Cloud have used service account keys for access. Service account keys are powerful credentials which can present a security risk when they are not managed correctly. Workload Identity Federation removes the need for service account keys for external applications that use an identity provider that supports OpenID Connect. An OpenID Connect ID token can be exchanged for a short-lived Google Cloud access token, which allows impersonation of an IAM service account. This process allows the external app to call Google Cloud Services without having to secure or rotate a service account key. When you can't use federation, you might need to use a service account key to provide external applications with access to Google Cloud APIs. Using service account keys really is a last resort. If you must use service account keys, make sure you're using the best security practices. You should upload a public key for your service account instead of downloading a private key created by Google. You can use your own infrastructure to generate a public and private key pair and then upload the public key to Google and securely deliver the private key to your runtime environment. This leaves less chance of error when handling your private key. Another best practice for service account keys is to never embed them in program source code or binaries. Keys can be extracted from binaries. And source code might be hosted in repositories, which makes keys more likely to be compromised. Finally, ensure that your service accounts follow the principle of least privilege. Grant only the minimum set of permissions necessary for the associated application. If the service account key is somehow compromised, you will limit the access for the bad actor.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.