{"id":8531,"date":"2024-01-19T08:52:13","date_gmt":"2024-01-19T08:52:13","guid":{"rendered":"https:\/\/www.satup.xyz\/index.php\/2024\/01\/19\/fine-grained-rbac-for-github-action-workflows-with-github-oidc-and-hashicorp-vault\/"},"modified":"2024-01-19T08:52:13","modified_gmt":"2024-01-19T08:52:13","slug":"fine-grained-rbac-for-github-action-workflows-with-github-oidc-and-hashicorp-vault","status":"publish","type":"post","link":"https:\/\/www.satup.xyz\/index.php\/2024\/01\/19\/fine-grained-rbac-for-github-action-workflows-with-github-oidc-and-hashicorp-vault\/","title":{"rendered":"Fine-Grained RBAC For GitHub Action Workflows With GitHub OIDC and HashiCorp Vault"},"content":{"rendered":"


\n<\/p>\n

\n

In our last article<\/a>, we discussed how a developer-first, contextual approach to secrets management enables a security program to meet the speed and scale of modern businesses. In this article, we explain how we accomplished this by leveraging GitHub\u2019s OpenID Connect (OIDC) support for authentication to fine-grained Hashicorp Vault roles, resulting in a \u201ccredentials-free\u201d experience for development teams in our deployment pipelines. For organizations running CI\/CD through GitHub Actions and managing their secrets with HashiCorp Vault, we\u2019ve found a process that offers a streamlined experience for developers while enabling simplified orchestration and management for security.<\/p>\n

In this article, we step through the technical implementation we employed between GitHub and Vault to support this OIDC flow for secrets consumption. We cover both the programmatic components of this secrets management pattern and the engineering details other organizations may wish to adapt to create their own versions of this program. At the end of the article, we share a Terraform module we have open sourced to help any organization to get up and running with a similar initiative.<\/p>\n

A common concern with many secrets management efforts is the \u201csecret zero\u201d problem. An organization stores all of its secrets in some kind of protected enclave, such as HashiCorp Vault or 1Password. The organization needs to restrict access to the secrets and to segment which secrets each group can access. Therefore, roles are created and authentication to those roles are distributed to appropriate users, teams, and systems.<\/p>\n

But where can those<\/em> authentication credentials be safely stored? Not in the secret store, as these credentials are a precondition to getting access. Could they be stored in a separate protected enclave? But how is access to that<\/em> system protected? It\u2019s turtles all the way down<\/a>. This first set of login credentials used to gain access to the secrets store is often denoted \u201csecret zero.\u201d<\/p>\n

Current Alternatives Require Complex Management<\/a><\/h3>\n

One common solution to the \u201csecret zero\u201d problem is to introduce another<\/em> secret enclave that contains an already trusted entity at the point where access to the secrets store is needed. For example, if a company\u2019s secrets are stored in HashiCorp Vault, static long-lived credentials to Vault (e.g. userpass, AppRole) can be generated and stored in GitHub as encrypted secrets<\/a>. A repository is granted access to these secrets as a property of the access control settings set on the repository or organization available in GitHub. Depending on the operating environment and the company in question, this may be sufficient to allow a GitHub Action workflow secure access to secrets in Vault.<\/p>\n

For many organizations, however, this approach necessitates implementing complex management procedures. An organization should be able to produce the following information about their secrets management program:<\/p>\n