Use Encrypted Text Secrets

Updated 6 days ago by Chakravarthy Tenneti

You can encrypt any text and reference it in Harness Application entities or connections.

In this topic:

Before You Begin

Step 1: Add Encrypted Text

  1. In Secrets Management, click Encrypted Text.
  2. Click Add Encrypted Text. The Add Encrypted Text dialog appears.
  3. Select the Secrets Manager you will use to encrypt this secret.
  4. Enter a name for the encrypted text. This is the name you will use to reference the text elsewhere in your applications.
  5. Enter a value for the encrypted text.
  6. Scope to Account - If your Harness User account is part of a User Group with the Administer Other Account Functions permission enabled, you will see the Scope to Account option. Select Scope to Account to make this encrypted text secret available to Delegate Profile scripts only. Only secrets scoped to the account are available to use in Delegate Profiles.
  7. If you want to restrict the use of the text to specific applications and environments, use Usage Scope. The encrypted text secret can be used in Workflows in Applications listed in its Usage Scope. The encrypted text secret can be used in Delegate Profiles only if the secret it is referencing is Account-level, with its Usage Scope set to Scope to Account. For more information, see Using Secrets.
    1. In Usage Scope, click the drop-down under Applications, and click the name of the Application.
    2. In Environments, click the name or type of the Environment.
  8. Click Submit.

Step 2: Use the Encrypted Text in Services

When you are in an Application entity such as a Service, you can use the encrypted text. For example:

  1. In a Service's Configuration section, click Add Variable. The Config Variable dialog appears.
  2. Enter a name for the variable, and then, in Type, select Encrypted Text.
  3. In Value, select the secret you created in Secrets Management.
  4. Click Submit and the secret will be used at runtime.

For an example of how to use an Encrypted Text secret, see Using Secrets.

Step 3: Using the Encrypted Text in Connectors

All of the passwords and keys used in Harness Connectors (Cloud Providers, Artifact Servers, Verification Providers, Source Repo Providers, and Collaboration Providers) are stored as Encrypted Text secrets in Harness.

You create the Encrypted Text secret first and then select it in the Connector. Or you can create it from the Connector by clicking Create Encrypted Text:

You can also edit it in the Connector.

Step 4: Reference the Encrypted Text

For Encrypted Text used in a Service's Config Variables, you reference them in the Workflow using the Service with the variable ${serviceVariable.var_name} .

For an Encrypted Text secret that has been scoped to an Application (using its Usage Scope settings), you reference the secret in an Application component using the expression: ${secrets.getValue("secret_name").

Step 5: Add a Secret to a File at Runtime

When a text secret has been scoped to Account-level using the Scope to Account setting, it can be referenced in a Delegate Profile as part of a script and written to a file as well. For example, here is a secret decoded from base64 and written to a file:

echo ${secrets.getValue("my_secret")} | base64 -d > /path/to/file.txt

Review: Invalid Characters in Secret Names

The following characters are not allowed in the names of secrets:

 ~ ! @ # $ % ^ & * ' " ? / < > , ;

Secrets in YAML Code

The example below applies to the values.yaml used by the secret manifest for either Kubernetes and Native Helm deployments. See Kubernetes or Native Helm?.

When you plan to use your secrets in YAML content, make sure you follow the quoting mechanism needed by YAML syntax.

For example, if the secret value is "foo: bar" and the secret has:

stringData: {{.Values.secret}}

It will resolve as follows:

stringData: foo: bar

This is not recognized as the lack of quotes and presence of extra space will lead to errors while executing the workflow.


To avoid this, follow the quoting mechanism suggested by YAML syntax, as follows:

stringData: {{.Values.secret | quote}}

It will resolve as follows:

stringData: "foo: bar"

Review: Secrets in Outputs

When a secret is displayed in an output, Harness substitutes the secret value with the secret name so that the secret value is never displayed. For example, here the secret values for repo username and password are replaced with <<<secret_name>>>:

helm repo add --username <<<repoUsername>>> --password <<<repoPassword>>> nginx

If you accidentally use a very common value in your secret, like whitespace or a single character, the <<<secret_name>>> substitution might appear in multiple places in the output. For example, if your secret value is a and your output is Alfalfa sprouts are great, this would result in output like this:

Alf<<<my_secret>>>lf<<<my_secret>>> sprouts <<<my_secret>>>re gre<<<my_secret>>>t

If you see output similar to this, review your secret and fix the error.

Looking Up Secrets and Values

You can look up the value of a secret using the following expression:


You can include this expression in a script and run it. However, for checking the logs, you can reverse look up the secret expression using its value and then output its expression as: <<<secret_name>>>

If an operation within the script changes the value of the script and Harness cannot match it to the expression, the newly modified string is displayed in the output exposing the secret value. If the modification is minor, the secret value can be easily deciphered which is a security concern.

Review: Secret Scope

When creating secrets, it's important to understand their scope in your Harness account.

A user can only create a secret according to the scope set by its Harness User permissions.

For example, if you have access to Application A only, you can create a secret scoped to Application A.

If you have access to Application A and B, you may still narrow the secret's scope to Application A only.

If the scope of a secret is only Application A, then only users with Read permission for Application A may see that secret. Users with Write permission to Application A may edit it also.

For steps, see Restrict Secrets Usage.

How did we do?