I am setting up a GitLab pipeline to run some Terraform configuration to enable OIDC authentication between our Azure AD and HashiCorp Vault instances. A proof of concept of this solution has been successfully implemented.

To protect some of the sensitive data consumed, there is a requirement to store the following Azure credentials securely, encrypted and injected into the GitLab pipeline when run:

1. Tenant ID
2. Client ID
3. Client Secret

We'd therefore like to identify and implement an ideal solution to achieve this objective and will readily consider secure storage options using AWS, Azure or HashiCorp Vault which are all part of our tech stack. Any suggestions or recommendations?

CodePudding user response：

Personally, I wouldn't consider Tenant ID and Client ID a sensitive information.

To protect the client secret, can't you just use group variables?

Saving the data to services like Azure Key Vault would be possible, but you'd need an application registration (another client id and secret) to retrieve it again.

CodePudding user response：

That's the thing with secrets: You have to start somewhere. That problem is often called "secure introduction". Let's follow that trail.

It starts with registering Vault in Azure-AD, giving you back the values you are concerned with. If you register Vault in Azure-AD in your pipeline, the best is to hold on to the values and reuse them right away to configure Vault's OIDC auth backend.

But based on your requirements, you can't store them in your Terraform state. There is also the problem of changing the client secret on a regular basis, say every year or so.

When you register Vault in Azure-AD, write the credentials in a version 2 KV store, with restricted policies. Even though only the client secret is a secret, we store the credentials in a document like this:

{
   "client_id": "..........",
   "client_secret": "...........",
   "tenant_id": "............"
}

We then read these values from Vault, and use them to configure the OIDC auth backend. When the client secret change, there are put as a new version of the secret and are picked up by the next run of the configuration pipeline.