Using HashiCorp Vault in GitHub

In this chapter, we will explore the integration of HashiCorp Vault, a powerful secrets management solution, with GitHub Actions. You’ll be guided through setting up a HashiCorp Vault in the cloud, authenticating it, and accessing resources securely using GitHub Actions. You will learn how to leverage the secrets stored in Vault to perform actions on pull requests while maintaining fine-grained role-based access control (RBAC) capabilities.

HashiCorp Cloud Vault is our chosen vault for this chapter, and if you’ve never heard of this product, it can be described as a secrets management product hosted on the HashiCorp Cloud Platform. We could have used Azure Key Vault, but what we cover in the next chapter for Azure will further extend upon OpenID Connect (OIDC) usage and will provide you with a strong foundational knowledge base to work from. As most other providers have adequate documentation to set up OIDC against them on the GitHub...

Technical requirements

To follow along with the hands-on material in this chapter, you must follow the steps in the previous chapter or access the resources from that chapter if anything is ambiguous to you.

In addition to this, you will also be required to have access to an email address to set up the HashiCorp Cloud Vault trial. It will be a 30-day trial, and by the end of this, you will have gained the skills to continue with the product or utilize another product at another vendor, such as Azure AD and Key Vault or GCP and secrets manager. Most of these will have a cost associated with them, and you should review the costs of each for your projected usage before enabling production.

In this chapter, we’ll need a new private repository named GHA.Private.Templates, and we’ll need to set it up for access to be used as a reusable workflow repository. This can be initialized with a README file for now.

We will be stepping through the process of creating everything...

Understanding what OIDC is

In this section, we will explain what OIDC is and how it functions within identity and access management.

OIDC is an open standard for secure and standardized user authentication and authorization. It builds upon the OAuth 2.0 protocol, providing an additional layer for identity verification and information exchange between client applications and identity providers.

At its core, OIDC enables the authentication of users by leveraging identity providers. These identity providers act as trusted third-party services that verify the user’s identity and provide necessary information to client applications. By relying on well-established identity providers such as Auth0, Okta, GitHub, Google, or Microsoft Entra ID (formerly Azure Active Directory), OIDC allows client applications to authenticate users without the need to manage user credentials directly.

OIDC has a few components for you to be familiar with. This is by no means an extensive list...

Setting up a HashiCorp Cloud Vault instance

In this section, we’ll explore the HashiCorp Cloud Vault offering and set up a development-only cluster with a public IP address for the workshops we will do. Implementing the scripts and actions you see in this book will be production ready. However, the implementation of this HashiCorp instance will not be production ready, as it is being configured for development purposes only.

If you wish to use this product in your environment, I suggest contacting the HashiCorp team today for guidance and support on being production safe for your organization’s setup.

What is HashiCorp Cloud Vault?

To give you a bit of background on Vault in case you’ve not heard of it, Hashicorp Vault is a popular open source secrets management (recently a cloud offering) and data protection tool. It provides a secure and centralized way to store, manage, and access sensitive information such as API keys, passwords, certificates, and...

Understanding secret engines and where secrets are stored

In the context of HashiCorp Vault, a secret engine is a component that handles the secure storage, generation, or encryption of secrets. They are called engines because they are plug and play, allowing users to enable different methods of managing secrets according to their requirements.

There’s not typically a component specifically referred to as secret engines in the sense of them being hidden or undisclosed. Rather, these engines provide various interfaces to manage secrets in Vault, and they are well-documented and transparent in their functionality. Let’s briefly explore a few popular engines that will help you understand what might be appropriate for your type of secret in the future:

• Key Value (KV) secrets engine: This is a secure and encrypted key-value store. It’s like a secure version of Redis or Memcached. You can store arbitrary data, such as passwords, API keys, or arbitrary text...

Enabling JWT authentication in HashiCorp

Enabling JWT is simple; configuring it is a little trickier. It’s simple to enable using the UI, but you need API or CLI calls to configure it securely. So, we’re going to use each of them in this process so you get a little bit of experience with each of the methods available.

There is also official GitHub documentation for this here: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault. It gives a very basic example, but it’s not up to date nor is it very secure, so we’ll use parts of it and expand on it further.

Let’s just quickly go over what we’re configuring in this section. We will configure our instance to allow JWT to be enabled as a form of authentication and for the authentication to be set up to understand how to verify GitHub tokens.

Enabling JWT for GitHub-produced tokens

In this section, we’re...

Setting up a workflow to use HashiCorp

This section aims to introduce a new workflow and a vault action. This workflow will allow us to notify Slack of the build outcome. We want this to be a reusable workflow within our organization so that any build outcome will go to a channel for the team.

We’ll add the build-node action we created in previous chapters and a new reusable workflow to the GHA.Private.Templates repository we created in the previous chapter. You can get the build action from the Chapter 6/.github/actions/* file and the reusable workflow we will use from Chapter 6/.github/workflows/gha.workflows.build-node.yml. You will need to update the value of YOUR_VAULT_URL_HERE in this file to point to your public cluster URL, which you can get from your cluster overview page.

Copy the actions directory from the repository into the private template repository for the organization. This file won’t be changed, and we’ve used this before, so we won’...

Exploring other security hardening techniques

Security should always be on your mind. When we create a way to generate dynamic leases to manage external cloud infrastructure or more, we should be extra diligent in our security requirements and make sure we meet them. A lot of what we did in the last section covered the 101s of role mapping, which we’ll go into in this section.

Implementing CODEOWNERS

Before we jump into OIDC recommendations, I want to call out a common one we all need to follow to limit our chance of disruption or bill shock: CODEOWNERS. I’ve seen a lack of implementation of this in repositories with workflows. If we have a .github directory in our repository, we should have CODEOWNERS protecting that directory and ideally only allowing write access to a team that has undergone some form of GitHub action training. Send them this book if they’ve not.

My first recommendation is to implement a CODEOWNERS file whenever you create a repository...

Summary

In this chapter, we delved into the fundamentals of OIDC in GitHub Actions, explored the setup and configuration of a HashiCorp Cloud Vault instance, and demonstrated how to leverage OIDC authentication and authorization to access secrets and communicate with Slack securely. We began by gaining a solid understanding of OIDC and its role in secure authentication and authorization. We explored the key concepts and principles of OIDC and its relevance in the GitHub Actions context.

Next, we set up a HashiCorp Cloud Vault instance and configured it to store our secrets securely. We learned how to authenticate and authorize a caller of a workflow using OIDC, establishing a secure connection between GitHub Actions and the Vault instance. With the authentication and authorization mechanisms in place, we seamlessly integrated Vault secrets into our GitHub Actions workflows. We accessed the secrets securely and utilized them to communicate with Slack, ensuring that sensitive information...