Hashicorp Vault Integration with Google OIDC Provider

In our previous blog, we set up a vault production-grade multi-node cluster, This article will be focusing on authentication and authorization in Vault using Google G-Suite OIDC flow.

Vault supports a number of authentication methods for users or systems to prove their identity so that a token with the appropriate policies can be obtained. OIDC-based delegated authorization methods are convenient for users and have become increasingly common. This method is familiar to most users.

Vault Auth Flow

What will we cover :

This will cover vault integration with google as an OIDC provider for the Vault.

1. Prerequisite
2. Configure OIDC Authentication
3. Vault Group and Policy Creation
4. Demonstrate Vault User Delegation

Prerequisites

Create Google Auth Secret from Google Cloud:

Steps to create the Google OAuth credentials to obtain client_id and client_secret

1.Visit the Google API Console.
2. Create or select a project.
3. Navigate to Menu > APIs & Services
4. Create a new credential via Credentials > Create Credentials > OAuth Client ID.
5. Configure the OAuth Consent Screen. Application Name is required. Save.
6. Select application type: "Web Application".
7. Configure Authorized Redirect URIs.
  ["http://vault-custom-domain:8200/ui/vault/auth/oidc/oidc/callback","http://localhost:8250/oidc/callback"]
8. Save client ID and secret.

The Client ID and Secret Looklike

{ "web": {
"client_id":"*******.apps.googleusercontent.com",
"project_id":"*****",
"auth_uri":"https://accounts.google.com/o/oauth2/auth",
"token_uri":"https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs",
"client_secret":"********",
"redirect_uris":["https://vault-custom-domain/ui/vault/auth/oidc/oidc/callback","http://localhost:8250/oidc/callback"],
"javascript_origins":["https://vault-custom-domain"]
  }
}

For more information: Using OAuth 2.0 to Access Google APIs

Note: Make sure your Vault server has been initialized and unsealed.
Please follow our previous blog where we walk through the Vault Cluster setup step by step.

Configure OIDC Authentication

Step 1: Enable OIDC auth method

$ vault auth enable oidc

Step 2: Create a Default Policy for OIDC users

We have created deny default policy because whenever a user login vault using the google oidc client it directly landed with no permission in order to delegate users’ permission based on their roles.

S vault policy write org-default-policy -<<EOF

path "*" {
    capabilities = ["deny"]
}
EOF

Step 3: Create OIDC Role

Now create oidc role based on the above deny policy, later it will be used by oidc configuration.

$ vault write auth/oidc/role/oidc-role \ 
    bound_audiences="******.apps.googleusercontent.com" \
    allowed_redirect_uris="http://vault-custome-domain:8200/ui/vault/auth/oidc/oidc/callback" \ 
    allowed_redirect_uris="http://localhost:8250/oidc/callback" \
    user_claim="sub" \ 
    token_policies="org-default-policy"

Step 6: Create OIDC Config

$ vault write auth/oidc/config \
    oidc_discovery_url="https://accounts.google.com" \
    oidc_client_id="********.apps.googleusercontent.com" \
    oidc_client_secret="*******" \
    default_role="oidc-role"

Hurray!! Now Vault OIDC setup has been done.

Vault Group and Policy Creation:

According to your organization structure, you can create multiple policies and groups.

For demonstration purposes, we have created 2 policies and 2 groups:
1. developer role
2. lead developer role

Step 1: Vault Policy Creation

We have assigned developers and lead developers to view and list dev and prod environment secrets. you can change it according to your organization's/project's requirements.

$ vault policy write developer-policy-<<EOF

# Manage k/v secrets
path "secret/data/development/*" {
    capabilities = ["read","list"]
}
EOF

$ vault policy write lead-dev-policy -<<EOF

# Manage k/v secrets
path "secret/data/development/*" {
    capabilities = ["read","list","update"]
}
path "secret/data/production/*" {
    capabilities = ["read","list"]
}
EOF

Step 2: Vault Group Creation

vault write identity/group name="developer" \
     type="internal" \
     policies="developer-policy" \
     metadata=team="Engineering" \
     metadata=region="India"

vault write identity/group name="lead-developer" \
     type="internal" \ 
     policies="lead-dev-policy" \
     metadata=team="Engineering" \
     metadata=region="India"

Demonstrate Vault Users Delegation:

Adding users to the appropriate groups so that they can read and list secrets based on their requirements.

Step 1: First log in with the OIDC method and click on Google Sign-in.

Step 2: Copy the OIDC user-id

Step 3: Log in to Vault with the privileged user and go to Entities to find out the entity-id which is associated with oidc user-id.

Step 4: Go to Groups and click on the desired group and add Members.

Step 5: Add entity-id in the Member entity-id section and save it.

Finally, now user can see limited access to the vault.

The process of group and policy creation is well described in official Vault documentation and no need to write it here.

Conclusion:

There are many different external OIDC providers that can be used for our vault, one of them is Google. Vault has enterprise and open-source versions, and can be deployed to different clouds, platforms, and operating systems. In this post, we looked at the User authentication and authorization for Vault.

Stay tuned don’t forget to follow me. In our next blog, we’ll cover how to set up vault monitoring with Prometheus and Grafana.

Thanks for reading this far, and good luck. I appreciate your comments/feedback.

About The Author
Suraj Solanki
DevOps Engineer — II
LinkedIn: https://www.linkedin.com/in/suraj-solanki