Reference Existing Secret Manager Secrets

Updated 3 months ago by Chakravarthy Tenneti

If you already have secrets created in HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or CyberArk Enterprise Password Vault before you use one of these vaults as the Harness Secrets Manager, you do not need to re-create the existing secrets in Harness.

Harness does not query the secrets manager for existing secrets, but you can create a secret in Harness that references an existing secret in HashiCorp Vault or AWS Secrets Manager. No new secret is created in those providers. If you delete the secret in Harness, it does not delete the secret in the provider.

In this topic:

Before You Begin

Option 1: Vault Secrets

You can create a Harness secret that refers to the existing Vault secret using a path and key, such as /path/secret_key#my_key.

In the above example, /foo/bar is the pre-existing path, MySecretKey is the secret name, and MyKey is the key used to lookup the secret value.

Do not prepend the Vault secrets engine to the path. In the above example, if the secret (/foo/bar/MySecretKey/MyKey) had been generated by a Vault secrets engine named harness-engine, it would reside in this full path /harness-engine/foo/bar/MySecretKey/MyKey. However, in the Value field, you would enter only /foo/bar/MySecretKey/MyKey.

This Harness secret is simply a reference pointing to an existing Vault secret. Deleting this Harness secret will not delete the Vault secret referred to by this secret.

You can also reference pre-existing Vault secrets in the Harness YAML editor, as described in Encrypted Information in YAML.

Option 2: AWS Secrets Manager Secrets

You can create a Harness secret that refers to an existing secret in AWS Secrets Manager using the name of the secret, and a prefix if needed. For example, devops/mySecret.

Referencing Secret Keys

In AWS Secrets Manager, your secrets are specified as key-value pairs, using a JSON collection:

To reference a specific key in your Harness secret, add the key name following the secret name, like secret_name#key_name. In the above example, the secret is named example4docs. To reference the example1 key, you would enter example4docs#example1.

Option 3: CyberArk Secrets

Once you have set up CyberArk as the default Harness Secrets Manager, you can reference existing secrets in the Encrypted Text dialog.

To use an existing CyberArk secrets, enter the following fields.

  • Name - Enter a name for the secret so you can reference it in Harness. This is a Harness setting, not a name in CyberArk.
  • Query - Queries the CyberArk secrets manager for the secret. For example, the query Safe=Test;Folder=root\OS\Windows;Object=windows1 search for Safe Test, folder root\OS\Windows, and object name windows1. The query is combined with the user credentials provided in the CyberArk Secrets Manager setup to create the complete API query.

The query syntax is:

Safe=<safe>;Folder=<folder>;Object=<name>

What Safe, Folder, and Object are named depends on your CyberArk setup. You can see the Safe as the Address field and Object as Username field in the following example, and so the query would be Address=components;Username=svc_account:

We recommend the query includes enough fields to ensure that multiple secrets are not returned. If multiple secrets are returned, the query will fail.

Option 4: Azure Key Vault Secrets

You can create a Harness secret that refers to an existing secret in Azure Key Vault, using that secret's name (for example: azureSecret). You can also specify the secret's version (for example: azureSecret/05).

Next Steps

How did we do?