Secrets Management

Harness includes a built-in secrets management feature that enables you to store encrypted secrets, such as access keys, and use them in your Harness applications. Some key points about Secrets Management:

  • Secrets are always accessed/decrypted at the time when they are needed and at no time are they stored unencrypted.
  • The Harness manager does not have access to your key management system, and only the Harness delegate, which sits in your private network, has access to it. Harness never makes secrets management accessible publicly, which adds an important layer of security.

Use Harness or Custom Secrets Management

You can choose to use your own secret management solution or the Harness Secrets Management built-in solution that leverages the Harness account on AWS KMS.

Below is a diagram representing how secrets are used with Harness.

To Add a Secret Manager

You can add your own secrets manager to Harness.

To add a secrets manager, do the following:

  1. Mouseover Continuous Security, and click Secrets Management. The Secrets Management page appears.
  2. Click Configure Secret Managers. The configured secret managers are displayed. The default is identified with a checkmark.
  3. Click Add Secret Manager. The Configure Secret Manager appears.
  4. Provide the account access information for the new secret manager. See the different options below.
  5. In Renew Interval Hours, select how often the secrets in the Secrets Manager are reloaded by the Harness delegate.
  6. Check Use as default secret manager to set this secret manager as the default.
  7. Click SUBMIT.

Migrating Secrets

Secrets Management supports the ability to migrate your secrets between secret managers, in case the default secret manager is compromised.

  1. In Secrets Management, click Configure Secret Managers.
  2. Next to the secret manager you want to migrate secrets from, click Deprecate.
  3. In the Deprecate dialog, in Transition data to use, select another secret manager, and click SUBMIT.

Using AWS

For AWS, you must add a Display Name, AWS Access Key, AWS Secret Key, and AWS Resource Name (ARN). You can locate these in the JSON for the Key Policy or in the AWS IAM console, under Encryption keys. For more information, see Finding the Key ID and ARN from Amazon.

Using HashiCorp Vault

For HashiCorp Vault, you must add a Display Name, Vault URL, and Token. For more information, see Vault documentation.

Using Secret Management

Secret Management includes the management of connections to artifact servers and cloud providers, and several types of execution credentials. The secrets you add can be used throughout your account, and managed centrally in Secret Management.

Using Cloud Providers

In Cloud Providers, the cloud providers added to the account are listed. For each one, you can see the Run Time Usage Log and Change Log:

  • The Run Time Usage Log shows each time the cloud provider was used and by which deployments. Click a deployment name to view that specific deployment.
  • The Change Log shows each time the cloud provider was changed and by which user.

For more information, see Add Cloud Providers.

Using Connectors

Under Using Connectors, the Artifact Servers, Collaboration Providers, and Verification Providers that you have configured for the account are listed. For each connector, you can see the Run Time Usage Log and Change Log.

For information on adding these connectors, see Add Artifact Servers, Add Collaboration Providers, and Verification Providers.

Using Execution Credentials

The default Secret Manager for your account is used to encrypt any secrets, files, or execution credentials. Once configured, encrypted text and files are available across your account. This allows you to upload a secret once, use it everywhere, and manage it in once place.

There are several execution credential types you can add to Secrets Management.

SSH

You will add SSH keys for use in connecting to remote servers, such as a Ubuntu instance.

  1. To add an SSH key that can be referenced in Harness entities, click Add SSH Key.
  2. Enter a Display Name for the SSH credentials.
  3. Provide the User Name for the account that will use the SSH key.
  4. Do one of the following:
    1. Click Inline and paste in the key to use.
    2. Click File Path (on Delegate) and specify the location of the key. This is the file path on the server running the Harness delegate, such as /home/johndoe/example.pem.
  5. If you want to restrict the use of a SSH credentials to specific applications and environments, do the following:
    1. In Usage Scope, click the drop-down under Applications, and click the name of the application.
    2. In Environments, click the name of the environment.
  6. Click SUBMIT.
SSH via Kerberos

Harness supports SSH server authentication using Kerberos, enabling you to SSH into a target host via the Kerberos protocol. For a quick Kerberos summary, see Explain like I’m 5: Kerberos by Lynn Root.

Field

Description

Auth Scheme

Select Kerberos.

Principal

Principal is a string that names a specific entity to which a set of credentials may be assigned. Enter the account name associated with the Kerberos account, such as johndoe.

Realm

Realm is the logical network served by a single Kerberos database and a set of Key Distribution Centers (KDCs). Typically, this is the domain where the service the user is trying to authenticate with is located.

For example: US-EAST-2.COMPUTE.INTERNAL.

Typically, the target host(s) that your SSH connection is intending to authenticate with via Kerberos are located in a domain name with the same name you enter in Realm. For example, ip-172-31-44-168.us-east-2.compute.internal.

The realm naming convention is all uppercase letters to differentiate the realm from the internet domain, but the Realm field does not enforce the convention.

TGT Generation

Select one of the following options:

  • Key Tab File Path (on Delegate) - You can choose this option to generate a new TGT from the KDC every time you authenticate with the service. This ensure that the TGT is always valid and not expired when you try to authenticate.
  • Password - Select this option to enter a password for TGT generation.
  • None - Select this option to skip skip TGT Generation. If you select this option, you must ensure that the TGT that is on the server running the Harness delegate is always.

Keytab File Path

This field is displayed if you select Key Tab File Path for TGT Generation.

Enter the file path to the keytab file on the server running the Harness delegate. For example, /home/johndoe/a.keytab. The file is not uploaded to Harness.

When you done, the dialog will look something like this:

To use the Kerberos SSH connection to connect to a target host, you select it in SSH Connection Attributes when specifying the target host in the Service Infrastructure settings of an environment.

In this example, the target host that you want to use Kerberos authentication with is entered in Host Name(s).

Note that the domain name used to identify the hosts in the Host Name(s) field is likely to be the same as the domain name you entered in Realm when configuring the SSH connection.

WinRM Connection
For information on setting up WinRM connections in Harness, see Set Up the WinRM Connection in Harness.

You can set up a WinRM connection and then use it as a Deployment Type in an environment's Service Infrastructure.

Encrypted Text

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

  1. In Secrets Management, click Encrypted Text.
  2. Click Add Encrypted Text. The Add Encrypted Text dialog appears.
  3. Enter a name for the encrypted text. This is the name you will use to reference the text elsewhere in your applications.
  4. Enter a value for the encrypted text.
  5. If you want to restrict the use of the text to specific applications and environments, do the following:
    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.
  6. Click SUBMIT.

Now, when you are in an application entity such as a service, you can use the encrypted text. For example:

  1. In the Configuration section of a service, 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.
Encrypted Files

You can upload encrypted files and reference them across your account in the same way as encrypted text.

  1. In Secrets Management, click Encrypted Files.
  2. Click Add Encrypted File. The Add Encrypted File dialog appears.
  3. Enter a name for the encrypted file. This is the name you will use to reference the file in application entities.
  4. Click Choose File, and locate and add a file. The default Secret Manager for your account is used to encrypt the file.
  5. If you want to restrict the use of the secret to specific applications and environments, do the following:
    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 environment.
  6. Click SUBMIT.

Now, when you are in an application entity that uses files, you can reference the encrypted file. For example, in the following Configuration File dialog, click Encrypt File and the File dropdown lets you choose the file you added in Secrets Management:


How did we do?