GCP
Last updated
Last updated
The gcp
auth method allows Google Cloud Platform entities to authenticate to Vault. Vault treats Google Cloud as a trusted third party and verifies authenticating entities against the Google Cloud APIs. This backend allows for authentication of:
Google Cloud IAM service accounts
Google Compute Engine (GCE) instances
This backend focuses on identities specific to Google Cloud and does not support authenticating arbitrary Google or Google Workspace users or generic OAuth against Google.
This plugin is developed in a separate GitHub repository at , but is automatically bundled in Vault releases. Please file all feature requests, bugs, and pull requests specific to the GCP plugin under that repository.
Vault includes a CLI helper that obtains a signed JWT locally and sends the request to Vault.
For more usage information, run vault auth help gcp
.
-> Note: The project
parameter has been removed in Vault 1.5.9+, 1.6.5+, and 1.7.2+. It is no longer needed for configuration and will be ignored if provided.
See Generating JWTs for ways to obtain the JWT token.
See API docs for expected response.
Auth methods must be configured in advance before users or machines can authenticate. These steps are usually completed by an operator or configuration management tool.
Enable the Google Cloud auth method:
Configure the auth method credentials if Vault is not running on Google Cloud:
If you are using instance credentials or want to specify credentials via an environment variable, you can skip this step. To learn more, see the Google Cloud Credentials section below.
Create a named role:
For an iam
-type role:
For a gce
-type role:
Note that bound_service_accounts
is only required for iam
-type roles.
For the complete list of configuration options for each type, please see the API documentation.
The environment variable GOOGLE_APPLICATION_CREDENTIALS
. This is specified as the path to a Google Cloud credentials file, typically for a service account. If this environment variable is present, the resulting credentials are used. If the credentials are invalid, an error is returned.
Default instance credentials. When no environment variable is present, the default service account credentials are used.
To use this auth method, the service account must have the following minimum scope:
Enabled GCP APIs
The GCP project must have the following APIs enabled:
Vault server permissions
For iam
-type Vault roles, the service account credentials
given to Vault can have the following role:
For gce
-type Vault roles, the service account credentials
given to Vault can have the following role:
If you instead wish to create a custom role with only the exact GCP permissions required, use the following list of permissions:
These allow Vault to:
verify the service account, either directly authenticating or associated with authenticating GCE instance, exists
get the corresponding public keys for verifying JWTs signed by service account private keys.
verify authenticating GCE instances exist
compare bound fields for GCE roles (zone/region, labels, or membership in given instance groups)
If you are using Group Aliases as described below, you will also need to add the resourcemanager.projects.get
permission.
Permissions for authenticating against Vault
If you are authenticating to Vault from Google Cloud, you can skip the following step as Vault will generate and present the identity token of the service account configured on the instance or the pod.
Note that the previously mentioned permissions are given to the Vault servers. The IAM service account or GCE instance that is authenticating against Vault must have the following role:
As of Vault 1.0, roles can specify an add_group_aliases
boolean parameter that adds group aliases to the auth response. These aliases can aid in building reusable policies since they are available as interpolated values in Vault's policy engine. Once enabled, the auth response will include the following aliases:
If you are using a custom role for Vault server, you will need to add the resourcemanager.projects.get
permission to your custom role.
This section describes the implementation details for how Vault communicates with Google Cloud to authenticate and authorize JWT tokens. This information is provided for those who are curious, but these details are not required knowledge for using the auth method.
IAM login applies only to roles of type iam
. The Vault authentication workflow for IAM service accounts looks like this:
The client sends this signed JWT to Vault along with a role name.
Vault extracts the kid
header value, which contains the ID of the key-pair used to generate the JWT, and the sub
ID/email to find the service account key. If the service account does not exist or the key is not linked to the service account, Vault denies authentication.
Vault authorizes the confirmed service account against the given role. If that is successful, a Vault token with the proper policies is returned.
GCE login only applies to roles of type gce
and must be completed on an infrastructure running on Google Cloud. These steps will not work from your local laptop or another cloud provider.
The client sends this JWT to Vault along with a role name.
Vault extracts the kid
header value, which contains the ID of the key-pair used to generate the JWT, to find the OAuth2 public cert to verify this JWT.
Vault authorizes the confirmed instance against the given role, ensuring the instance matches the bound zones, regions, or instance groups. If that is successful, a Vault token with the proper policies is returned.
This section details the various methods and examples for obtaining JWT tokens.
curl example
Vault requires the following minimum claim set:
If a user generates a token that expires after 15 minutes, and the gcp role has max_jwt_exp
set to the default, Vault will return the following error: Expiration date must be set to no more that 15 mins in JWT_CLAIM, otherwise the login request returns error "role requires that service account JWTs expire within 900 seconds
. In this case, the user must create a new signed JWT with a shorter expiration, or set max_jwt_exp
to a higher value in the gcp role.
gcloud example
You can also do this through the (currently beta) gcloud command. Note that you will be required to provide the expiration claim exp
as a part of the JWT input to the command.
Golang example
You can autogenerate this token in Vault versions 1.8.2 or higher.
GCE tokens can only be generated from a GCE instance.
Vault can automatically discover the identity token on a GCE/GKE instance. This simplifies authenticating to Vault like so:
The JWT token can also be obtained from the "service-accounts/default/identity"
endpoint for a instance's metadata server.
Curl example
The GCP Auth Plugin has a full HTTP API. Please see the API docs for more details.
The following example demonstrates the Google Cloud auth method to authenticate with Vault.
-> Note: If you're using a environment, you will additionally need to configure your environment’s custom endpoints via the custom_endpoint configuration parameter.
The Google Cloud Vault auth method uses the official Google Cloud Golang SDK. This means it supports the common ways of .
For more information on service accounts, please see the .
for iam
and gce
type roles.
for gce
type roles.
for iam
and gce
type roles that set add_group_aliases
to true.
!> WARNING: Make sure this role is only applied so your service account can impersonate itself. If this role is applied GCP project-wide, this will allow the service account to impersonate any service account in the GCP project where it resides. See for more information.
The client generates a signed JWT using the Service Account Credentials API method. For examples of how to do this, see the Generating JWTs section.
The client obtains an on a GCE instance.
This describes how to use the GCP Service Account Credentials directly to generate the signed JWT with the claims that Vault expects. Note the CLI does this process for you and is much easier, and that there is very little reason to do this yourself.
For the API method, providing the expiration claim exp
is required. If it is omitted, it will not be added automatically and Vault will deny authentication. Expiration must be specified as a value (seconds from Epoch). This value must be before the max JWT expiration allowed for a role. This defaults to 15 minutes and cannot be more than 1 hour.
One you have all this information, the JWT token can be signed using curl and :
Read more on the .