open-vault/website/source/docs/auth/gcp.html.md
Jeff Escalante a3dfde5cec New Docs Website (#5535)
* conversion stage 1

* correct image paths

* add sidebar title to frontmatter

* docs/concepts and docs/internals

* configuration docs and multi-level nav corrections

* commands docs, index file corrections, small item nav correction

* secrets converted

* auth

* add enterprise and agent docs

* add extra dividers

* secret section, wip

* correct sidebar nav title in front matter for apu section, start working on api items

* auth and backend, a couple directory structure fixes

* remove old docs

* intro side nav converted

* reset sidebar styles, add hashi-global-styles

* basic styling for nav sidebar

* folder collapse functionality

* patch up border length on last list item

* wip restructure for content component

* taking middleman hacking to the extreme, but its working

* small css fix

* add new mega nav

* fix a small mistake from the rebase

* fix a content resolution issue with middleman

* title a couple missing docs pages

* update deps, remove temporary markup

* community page

* footer to layout, community page css adjustments

* wip downloads page

* deps updated, downloads page ready

* fix community page

* homepage progress

* add components, adjust spacing

* docs and api landing pages

* a bunch of fixes, add docs and api landing pages

* update deps, add deploy scripts

* add readme note

* update deploy command

* overview page, index title

* Update doc fields

Note this still requires the link fields to be populated -- this is solely related to copy on the description fields

* Update api_basic_categories.yml

Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages.

* Add bottom hero, adjust CSS, responsive friendly

* Add mega nav title

* homepage adjustments, asset boosts

* small fixes

* docs page styling fixes

* meganav title

* some category link corrections

* Update API categories page

updated to reflect the second level headings for api categories

* Update docs_detailed_categories.yml

Updated to represent the existing docs structure

* Update docs_detailed_categories.yml

* docs page data fix, extra operator page remove

* api data fix

* fix makefile

* update deps, add product subnav to docs and api landing pages

* Rearrange non-hands-on guides to _docs_

Since there is no place for these on learn.hashicorp, we'll put them
under _docs_.

* WIP Redirects for guides to docs

* content and component updates

* font weight hotfix, redirects

* fix guides and intro sidenavs

* fix some redirects

* small style tweaks

* Redirects to learn and internally to docs

* Remove redirect to `/vault`

* Remove `.html` from destination on redirects

* fix incorrect index redirect

* final touchups

* address feedback from michell for makefile and product downloads
2018-10-19 08:40:11 -07:00

9.6 KiB

layout page_title sidebar_title sidebar_current description
docs Google Cloud - Auth Methods Google Cloud docs-auth-gcp The "gcp" auth method allows users and machines to authenticate to Vault using Google Cloud service accounts.

Google Cloud Auth Method

The gcp auth method allows authentication against Vault using Google credentials. It treats Google Cloud Platform (GCP) as a Trusted Third Party and expects a JSON Web Token (JWT) signed by Google credentials from the authenticating entity. This token can be generated through different GCP APIs depending on the type of entity.

This plugin is developed in a separate GitHub repository at hashicorp/vault-plugin-auth-gcp, but is automatically bundled in Vault releases. Please file all feature requests, bugs, and pull requests specific to the GCP plugin under that repository.

Authentication

Via the CLI

The default path is /gcp. If this auth method was enabled at a different path, specify -path=/my-path in the CLI.

$ vault login -method=gcp \
    role="my-role" \
    jwt="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

In this example, the "role" is the name of a configured role. The "jwt" is a self-signed or Google-signed JWT token obtained using the signJwt API call.

Because the process to sign a service account JWT can be tedious, Vault includes a CLI helper to generate the JWT token given the service account and parameters. This process only applies to iam-type roles!

$ vault login -method=gcp \
    role="my-role" \
    jwt_exp="15m" \
    credentials=@path/to/credentials.json \
    project="my-project" \
    service_account="service-account@my-project.iam.gserviceaccounts.com"

This signs a properly formatted service account JWT and authenticates to Vault directly. For details on each field, please run vault auth help gcp.

Via the API

$ curl \
    --request POST \
    --data '{"role":"my-role", "jwt":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}' \
    http://127.0.0.1:8200/v1/auth/gcp/login

The response will be in JSON. For example:

{
  "auth": {
    "client_token": "f33f8c72-924e-11f8-cb43-ac59d697597c",
    "accessor": "0e9e354a-520f-df04-6867-ee81cae3d42d",
    "policies": [
      "default",
      "dev",
      "prod"
    ],
    "metadata": {
      "role": "my-role",
      "service_account_email": "dev1@project-123456.iam.gserviceaccount.com",
      "service_account_id": "111111111111111111111"
    },
    "lease_duration": 2764800,
    "renewable": true
  }
}

Configuration

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.

  1. Enable the Google Cloud auth method:

    $ vault auth enable gcp
    
  2. Configure the auth method credentials:

    $ vault write auth/gcp/config \
        credentials=@/path/to/credentials.json
    

    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 Authentication section below.

  3. Create a named role:

    For an iam-type role:

    $ vault write auth/gcp/role/my-iam-role \
        type="iam" \
        project_id="my-project" \
        policies="dev,prod" \
        bound_service_accounts="my-service@my-project.iam.gserviceaccount.com"
    

    For a gce-type role:

    $ vault write auth/gcp/role/my-gce-role \
        type="gce" \
        project_id="my-project" \
        policies="dev,prod" \
        bound_zones="us-east1-b" \
        bound_labels="foo:bar,zip:zap"
    

    For the complete list of configuration options for each type, please see the API documentation.

Google Cloud Authentication

The Google Cloud Vault auth method uses the official Google Cloud Golang SDK. This means it supports the common ways of providing credentials to Google Cloud.

  1. 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.

  2. Default instance credentials. When no environment variable is present, the default service account credentials are used.

For more information on service accounts, please see the Google Cloud Service Accounts documentation.

To use this storage backend, the service account must have the following minimum scope(s):

https://www.googleapis.com/auth/cloud-platform

Workflow

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 implementation details are not required knowledge for using the auth method.

IAM Login

IAM login applies only to roles of type iam. The Vault authentication workflow for IAM service accounts looks like this:

Vault Google Cloud IAM Login Workflow

  1. The client generates a signed JWT using the IAM projects.serviceAccounts.signJwt method. For examples of how to do this, see the Obtaining JWT Tokens section.

  2. The client sends this signed JWT to Vault along with a role name.

  3. 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.

  4. 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

GCE login only applies to roles of type gce and must be completed on an instance running in GCE. These steps will not work from your local laptop or another cloud provider.

Vault Google Cloud GCE Login Workflow

  1. The client obtains an instance identity metadata token on a GCE instance.

  2. The client sends this JWT to Vault along with a role name.

  3. 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.

  4. 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.

Obtaining JWT Tokens

Vault expects a signed JWT token to verify against. There are a few ways to acquire a JWT token.

Generating IAM Tokens

Vault includes a CLI helper for generating the signed JWT token and submitting it to Vault for iam-type roles. If you want to generate the JWT token yourself, follow this section.

Shell Example

The expected format of the JWT request payload is:

{
  "sub": "$SERVICE_ACCOUNT",
  "aud": "vault/$ROLE",
  "exp": "$EXPIRATION" // optional
}

If specified, the expiration must be a NumericDate 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 oauth2l:

ROLE="my-role"
PROJECT="my-project"
SERVICE_ACCOUNT="service-account@my-project.iam.gserviceaccount.com"
OAUTH_TOKEN="$(oauth2l header cloud-platform)"

curl \
  --header "${OAUTH_TOKEN}" \
  --header "Content-Type: application/json" \
  --request POST \
  --data "{\"aud\":\"vault/${ROLE}\", \"sub\": \"${SERVICE_ACCOUNT}\"}" \
  "https://iam.googleapis.com/v1/projects/${PROJECT}/serviceAccounts/${SERVICE_ACCOUNT}:signJwt"

gcloud Example

gcloud beta iam service-accounts sign-jwt credentials.json - \
  --iam-account=service-account@my-project.iam.gserviceaccount.com \
  --project=my-project

Golang Example

Read more on the Google Open Source blog.

Generating GCE Tokens

GCE tokens can only be generated from a GCE instance. You must run these commands from the GCE instance. The JWT token can be obtained from the service-accounts/default/identity endpoint for a instance's metadata server.

ROLE="my-gce-role"
SERVICE_ACCOUNT="service-account@my-project.iam.gserviceaccount.com"

curl \
  --header "Metadata-Flavor: Google" \
  --get \
  --data-urlencode "aud=http://vault/${ROLE}" \
  --data-urlencode "format=full" \
  "http://metadata/computeMetadata/v1/instance/service-accounts/${SERVICE_ACCOUNT}/identity"

API

The GCP Auth Plugin has a full HTTP API. Please see the API docs for more details.