Each stage in the deployment pipeline has an isolated instance of Vault. They are available as follows:
All engineers have access to the first two stages in the pipeline, but only Platform Operators have access to Production.
Authentication is handling through Minted's corporate identity provider. To authenticate, select OIDC from the Method dropdown on the sign-in screen.
Each tenant in the Hen Platform receives it's own namespace to manage data in Vault. Currently, the only secret engine supports is KV2 engine. This allows for populate key-value based secrets in a hierarchical fashion. The namespace path corresponds to the project name provided in each project's hen.yaml file. As well, even though each Vault instance is isolated from the other, the pipeline stage name is including in the namespace path to avoid simple mistakes and provide more clarity. For example, a project name my-fabulous-webservice would have a KV2 namespace path of for the staging pipeline stage:
secret/staging/my-fabulous-webservice
By default, the Hen Platform will provide a secret named env for each tenant. The contents of this secret are automatically injected in to the environment of all Kubernetes pods running inside project's namespace. As well, Hen automatically wraps the container command provided to ensure that these environment variables are then available to your container process. Thus, safely accessing secrets managed with Vault is as simple as following 12-factor best-practices, and reading configuration from the environment.
Secrets can be set through the Vault UI or the CLI. Please refer to the Vault docs for operating Vault itself.