How to generate short-lived GCP Service Account Keys or OAuth2 tokens with Vault

Sometimes we prefer to store the GCP Service Account key directly in a Vault path. With this approach, doing some things like Key rotation, Offboarding the users who had access to a Vault path, and basically, Access management could be extremely hard! The benefits of using this secrets engine to manage the Google Cloud IAM service accounts are:

• Automatic cleanup of GCP IAM service account keys — each Service Account key is associated with a Vault lease. When the lease expires (either during normal revocation or through early revocation), the service account key is automatically revoked.
• Quick, short-term access — users do not need to create new GCP Service Accounts for short-term or one-off access (such as batch jobs, deployment jobs, or quick introspection).
• Multi-cloud and hybrid cloud applications — users authenticate to Vault using a central identity service (such as LDAP) and generate GCP credentials without the need to create or manage a new Service Account for that user.

Setup

First, enable the GCP secrets:

vault secrets enable gcp

Now you need to create a service account and it will be introduced to the Vault to use it. The service account must have the following roles:

roles/iam.serviceAccountKeyAdmin   # Service Account Key Admin
roles/iam.serviceAccountCreator    # Create Service Accounts

The next step is to configure the credentials required for the plugin to perform API calls to Google Cloud. Before that, you should generate a JSON key for this service account.

1. GCP Console
2. IAM And Admin
3. Service Accounts
4. Click on your vault’s service account
5. KEYS tab
6. ADD KEY → Create a new key → JSON → Create

The browser automatically downloads the generated key.

Configure the GCP plugin credentials:

# We set the new keys TTL to 30 seconds
# TTL only applies to the Service Account key
# OAuth2 tokens have a static life-time of 1 hr that cannot be modified.
> vault write gcp/config credentials=@key.json ttl=30
#> Success! Data written to: gcp/config

Configure a roleset. Rolesets determine the permissions that Service Account credentials generated by Vault will have on GCP resources. (More details…)

mybindings.hcl:

# In this case, we are going to create a service account with GCS access
# Depends on your use case; you should configure it, e.g., CircleCI or Gitlab
# Which need to deploy an application in GKE need to have access to it.
resource "buckets/my-bucket" {
  roles = [
    "roles/storage.objectAdmin",
    "roles/storage.legacyBucketReader",
  ]
}

Notice that BigQuery requires different permissions than other resources. This is because BigQuery currently uses legacy ACL instead of traditional IAM permissions. This means to update access on the dataset, Vault must be able to update the dataset’s metadata.

To configure a roleset that generates keys/tokens (You can use both of these at the same time) :

# OAuth2 access tokens
> vault write gcp/roleset/my-storage-roleset-oauth2 \
    project="your-project-name" \
    secret_type="access_token"  \
    token_scopes="https://www.googleapis.com/auth/cloud-platform" \
    bindings=@mybindings.hcl
#> Success! Data written to: gcp/roleset/my-storage-roleset-oauth2
# Service Account keys
> vault write gcp/roleset/my-storage-roleset-sa \
    project="your-project-name" \
    secret_type="service_account_key"  \
    bindings=@mybindings.hcl
#> Success! Data written to: gcp/roleset/my-storage-roleset-sa

If you run the above commands, Vault will create two service accounts for you.

Don’t delete the Vault generated service accounts from the console, use this command instead: > vault delete gcp/roleset/my-storage-roleset-sa

The configuration of this secret plugin is over!

Usage

After the secrets engine is configured and a user/machine has a Vault token with the proper permission, it can generate credentials. Depending on how the roleset was configured, you can generate OAuth2 tokens or service account keys.

# Generates OAuth2 token
> vault read gcp/token/my-storage-roleset-oauth2
========== Data ==========
Key                 Value
---                 -----
key_algorithm       KEY_ALG_RSA_2048
key_type            TYPE_GOOGLE_CREDENTIALS_FILE
private_key_data    ewogIC...
****
# Generates service account key
> vault read gcp/key/my-storage-roleset-sa
Key                 Value
---                 -----
lease_id            gcp/key/my-storage-roleset-sa/wWBwiD5gZrFZ1TCVV9chLtq8.waI57
lease_duration      30s
lease_renewable     true
key_algorithm       KEY_ALG_RSA_2048
key_type            TYPE_GOOGLE_CREDENTIALS_FILE
private_key_data    ewogICJ0...

Through creating policies and roles, you can assign specific roles to a user. In this article, we explained the secrets→GCP, So what do you think, If besides this, configure and use auth→GCP or auth→JWT? You can find an article about this in my blog 😉

//Thanks for reading 🙏