Vault - JWT claim enhancement
in progress
B
Beryl Mandrill
As part of the JWT/OIDC authentication for vault allow us to enhance the claims to include the environment id. This is required since we would like to make the scope more granular in order to allow production secrets to only be available to production environments.
Additionally prod1 env should not have access to prod2 secrets as part of the pipeline.
Include a claim in the JWT payload for the current environment id
account/{account_id}:org/{organization_id}:project/{project_id}/{env_id}
Similar to feature flag PL_OIDC_ENHANCED_SUBJECT_FIELD but with extra field.
Log In
This post was marked as
in progress
A
Abhishek Thamman
Merged in a post:
Requests to an external secrets managers must be associated with an "Environment"
A
Associated Horse
Harness uses "Environments" to define the environment to which a pipeline deploys, and uses "Connectors" to integrate with external secrets managers (like HashiCorp Vault). The connector is essentially the "identity" that interacts with the external secrets manager, and can be configured at the account, organization, or project level.
Enterprise organizations require the isolation of environments, like keeping production isolated from integration or development environments, including secrets. Therefore, secrets managers require the ability to ensure access to production secrets are only provided to production workloads/pipelines. However, connectors cannot be tied to environments and the environment cannot be exposed to the secrets manager.
For example, let's review a JWT integration with HashiCorp Vault. The connector can be configured at the account, organization, or project level, with the number of JWT claims and detail increasing at each level. This is an example JWT of a connector created at the project level:
{
"sub": "account/ABC123DEF456:org/MyAppOrg:project/MyAppProject",
"aud": "harness",
"exp": 1749488567,
"iat": 1749484967,
"account_id": "ABC123DEF456",
"organization_id": "MyAppOrg",
"project_id": "MyAppProject",
"connector_id": "project_hashi_connector",
"connector_name": "project_hashi_connector",
"context": "CONNECTOR"
}
This JWT is all the secrets manager, HashiCorp Vault in this example, receives to identify/authenticate the connection looking to retrieve secrets. The same account/org/project is used to deploy to production, integration testing, and development. Therefore, the sub, account_id, organization_id, and project_id claims cannot be used to determine whether the requestor should be provided production, integration testing, or development secrets.
Please provide a way to expose the environment to an external secrets manager so that proper secrets governance/controls can be applied by the secrets manager.
Prateek Mittal
long-term
Prateek Mittal
under review