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", "iss": " https://app.harness.io/ng/api/oidc/account/ABC123DEF456 ", "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.
