Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/compute/docs/authentication below:

Authenticate to Compute Engine | Compute Engine Documentation

Stay organized with collections Save and categorize content based on your preferences.

This document describes how to authenticate to Compute Engine programmatically. How you authenticate to Compute Engine depends on the interface you use to access the API and the environment where your code is running.

If you need to review the different options for authenticating apps and workloads running on Compute Engine to Google Cloud API, see

.

For more information about Google Cloud authentication, see the Authentication methods.

Compute Engine supports programmatic access. You can access the API in the following ways:

• Client libraries
• Google Cloud CLI
• REST

The Compute Engine client libraries provide high-level language support for authenticating to Compute Engine programmatically. To authenticate calls to Google Cloud APIs, client libraries support Application Default Credentials (ADC); the libraries look for credentials in a set of defined locations and use those credentials to authenticate requests to the API. With ADC, you can make credentials available to your application in a variety of environments, such as local development or production, without needing to modify your application code.

When you use the gcloud CLI to access Compute Engine, you log in to the gcloud CLI with a user account, which provides the credentials used by the gcloud CLI commands.

If your organization's security policies prevent user accounts from having the required permissions, you can use service account impersonation.

For more information, see Authenticate for using the gcloud CLI. For more information about using the gcloud CLI with Compute Engine, see the gcloud CLI reference pages.

You can authenticate to the Compute Engine API by using your gcloud CLI credentials or by using Application Default Credentials. For more information about authentication for REST requests, see Authenticate for using REST. For information about the types of credentials, see gcloud CLI credentials and ADC credentials.

How you set up authentication depends on the environment where your code is running.

The following options for setting up authentication are the most commonly used. For more options and information about authentication, see Authentication methods.

You can set up credentials for a local development environment in the following ways:

• User credentials for client libraries or third-party tools
• User credentials for REST requests from the command line
• Service account impersonation

Set up Application Default Credentials (ADC) in your local environment:

1. Install the Google Cloud CLI. After installation, initialize the Google Cloud CLI by running the following command:

   gcloud init

   If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

2. If you're using a local shell, then create local authentication credentials for your user account:

   gcloud auth application-default login

   You don't need to do this if you're using Cloud Shell.

   If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

   A sign-in screen appears. After you sign in, your credentials are stored in the local credential file used by ADC.

For more information about working with ADC in a local environment, see Set up ADC for a local development environment.

When you make a REST request from the command line, you can use your gcloud CLI credentials by including gcloud auth print-access-token as part of the command that sends the request.

The following example lists service accounts for the specified project. You can use the same pattern for any REST request.

Before using any of the request data, make the following replacements:

• PROJECT_ID: Your Google Cloud project ID.

To send your request, expand one of these options:

Execute the following command:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     "https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts"

Execute the following command:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }
Invoke-WebRequest `

    -Method GET `
    -Headers $headers `
    -Uri "https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts" | Select-Object -Expand Content

For more information about authenticating using REST and gRPC, see Authenticate for using REST. For information about the difference between your local ADC credentials and your gcloud CLI credentials, see gcloud CLI authentication configuration and ADC configuration.

In most cases, you can use your user credentials to authenticate from a local development environment. If that is not feasible, or if you need to test the permissions assigned to a service account, you can use service account impersonation. You must have the iam.serviceAccounts.getAccessToken permission, which is included in the Service Account Token Creator (roles/iam.serviceAccountTokenCreator) IAM role.

You can set up the gcloud CLI to use service account impersonation by using the gcloud config set command:

gcloud config set auth/impersonate_service_account SERVICE_ACCT_EMAIL

For select languages, you can use service account impersonation to create a local ADC file for use by client libraries. This approach is supported only for the Go, Java, Node.js, and Python client libraries—it is not supported for the other languages. To set up a local ADC file with service account impersonation, use the --impersonate-service-account flag with the gcloud auth application-default login command:

gcloud auth application-default login --impersonate-service-account=SERVICE_ACCT_EMAIL

For more information about service account impersonation, see Use service account impersonation.

To authenticate a workload running on Google Cloud, you use the credentials of the service account attached to the compute resource where your code is running, such as a Compute Engine virtual machine (VM) instance. This approach is the preferred authentication method for code running on a Google Cloud compute resource.

For most services, you must attach the service account when you create the resource that will run your code; you cannot add or replace the service account later. Compute Engine is an exception—it lets you attach a service account to a VM instance at any time.

Use the gcloud CLI to create a service account and attach it to your resource:

1. Install the Google Cloud CLI. After installation, initialize the Google Cloud CLI by running the following command:

   gcloud init

   If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

2. Set up authentication:

   1. Create the service account:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

      Replace SERVICE_ACCOUNT_NAME with a name for the service account.

   2. To provide access to your project and your resources, grant a role to the service account:

      gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com" --role=ROLE

      Replace the following:

      • SERVICE_ACCOUNT_NAME: the name of the service account
      • PROJECT_ID: the project ID where you created the service account
      • ROLE: the role to grant
      Note: The --role flag affects which resources the service account can access in your project. You can revoke these roles or grant additional roles later. In production environments, do not grant the Owner, Editor, or Viewer roles. Instead, grant a predefined role or custom role that meets your needs.
   3. To grant another role to the service account, run the command as you did in the previous step.

   4. Grant the required role to the principal that will attach the service account to other resources.

      gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com --member="user:USER_EMAIL" --role=roles/iam.serviceAccountUser

      Replace the following:

      • SERVICE_ACCOUNT_NAME: the name of the service account
      • PROJECT_ID: the project ID where you created the service account
      • USER_EMAIL: the email address for a Google Account

3. Create the resource that will run your code, and attach the service account to that resource. For example, if you use Compute Engine:

   Create a Compute Engine instance. Configure the instance as follows:
   • Replace INSTANCE_NAME with your preferred instance name.
   • Set the --zone flag to the zone in which you want to create your instance.
   • Set the --service-account flag to the email address for the service account that you created.

   gcloud compute instances create INSTANCE_NAME --zone=ZONE --service-account=SERVICE_ACCOUNT_EMAIL

For more information about authenticating to Google APIs, see Authentication methods.

The preferred method to set up authentication from outside of Google Cloud is to use workload identity federation. For more information, see Set up ADC for on-premises or another cloud provider in the authentication documentation.

After you authenticate to Compute Engine, you must be authorized to access Google Cloud resources. Compute Engine uses Identity and Access Management (IAM) for authorization.

For more information about the roles for Compute Engine, see Compute Engine IAM roles and permissions . For more information about IAM and authorization, see IAM overview.

• For apps and workloads running on Compute Engine, review workload authentication methods.
• Learn about Google Cloud authentication methods.
• See a list of authentication use cases.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Compute Engine supports programmatic API access through client libraries, Google Cloud CLI, and REST."],["Application Default Credentials (ADC) are supported by client libraries, allowing authentication across various environments without code modification."],["When working locally, user credentials, service account impersonation, or `gcloud CLI` credentials can be used to set up authentication for Compute Engine."],["On Google Cloud, the preferred authentication method is using the credentials of the service account attached to the compute resource where your code is running."],["For environments outside of Google Cloud, using workload identity federation is the recommended way to set up authentication."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4