As a developer, I want to manage my secrets that will be used inside our Github Action workflow and deployment

[ThomasCardin]

Executive summary

Move secrets management from Github to within the Kubernetes cluster

Issue

Currently, we have two ways of managing our secrets. For deployments made from Kubernetes, we use HashiCorp Vault, and for GitHub Actions, we utilize the secrets feature directly within GitHub actions. In our scenario, we have organization-wide secrets and secrets specific to each application. The problem is that we have to manually add each new secret to this workflow as well as in Vault. In essence, this creates a significant amount of toil.

Solution

To avoid these repetitive tasks, there is this workflow by HashiCorp Vault that allows defining a wildcard *.

How to

To achieve this, we need to create a secrets path (e.g., org/default) that contain all our organization/application secrets. By using the multiple-secrets feature (mention above), we can retrieve the secrets using the Vault GitHub action.

Steps

• [x] Setup vault ressources with terraform (Azure Key vault, certificates, etc.
• [x] Deploy vault in AKS.
• [x] Create an ingress for Vault.
• [x] Manage permissions for access to Vault in our GitHub action.
• [x] Migrate GitHub secrets to Vault.
• [ ] ~#174~
  • [x] #281

[rngadam]

Executive summary

Move secrets management from Github to within the Kubernetes cluster

[ThomasCardin]

For the post mortem you are talking about?

[rngadam]

For the post mortem you are talking about?

No, this is a suggestion for your description to make it more palatable to non-technical users. I would also try to rewrite subjects to not talk about implementation and keep it higher-level. Executive summary are important to create context for non-technical managers