Add an AWS secrets manager

You can use AWS Secrets Manager for your Harness secrets.

Unlike AWS KMS, AWS Secrets Manager stores both secrets and encrypted keys. With AWS KMS, Harness stores the secret in its Harness store and retrieves the encryption keys from KMS. For information on using an AWS KMS Secrets Manager, go to Add an AWS KMS Secrets Manager.

This topic describes how to add an AWS Secret Manager in Harness.

important

You can only use Harness Built-in Secret Manager to store authentication credentials for access to the corresponding secret manager.

Storing credentials from one secret manager within another can result in complex and challenging situations. Moreover, these configurations might introduce vulnerabilities, posing potential security risks.

The Harness platform has several validations, including the disabling of self-references.

Before you begin

If you are adding an AWS Secrets Manager running on ROSA, you must also add an environment variable AWS_REGION with the appropriate region as its value, for example, AWS_REGION=us-east-1.

Permissions: Test AWS Permissions

Harness uses the same minimum IAM policies for AWS secret manager access as the AWS CLI.

The AWS account you use for the AWS Secret Manager must have the following policies at a minimum:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
            "secretsmanager:Describe*",
            "secretsmanager:Get*",
            "secretsmanager:List*"
        ],
        "Resource": "*"
    }
}

These policies let you list secrets which will allow you to add the secret manager and refer to secrets, but it will not let you read secrets values.

The following policy list enables Harness to perform all the secrets operations you might need:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
          "secretsmanager:CreateSecret",
          "secretsmanager:DescribeSecret",
          "secretsmanager:DeleteSecret",
          "secretsmanager:GetRandomPassword",
          "secretsmanager:GetSecretValue",
          "secretsmanager:ListSecretVersionIds",
          "secretsmanager:ListSecrets",
          "secretsmanager:UpdateSecret",
          "secretsmanager:TagResource"
        ],
        "Resource": "*"
    }
}

Go to Using Identity-based Policies (IAM Policies) for Secret Manager in the AWS documentation.

To test, use the AWS account when running aws secretsmanager list-secrets on either the Harness Delegate host or another host.

Step 1: Add a Secret Manager

This topic assumes you have a Harness Project set up. If you don't have a Harness Project, go to Create Organizations and Projects.

You can add a connector from any module in your Project in Project SETUP, or in your Organization, or Account Resources.

In Connectors, select Connector.

In Secret Managers, select AWS Secrets Manager. The AWS Secrets Manager settings appear.

note

For information on restrictions on names and maximum quotas, go to Quotas for AWS Secrets Manager.

Step 2: Overview

Enter a Name for your secret manager.

You can choose to update the ID or let it be the same as your secret manager's name. For more information, go to Entity Identifier Reference.

Enter a Description for your secret manager.

Enter Tags for your secret manager.

Select Continue.

Step 3: Credential Details

When setting up your AWS Secrets Manager in Harness, you can choose one of the following Credential Types for authentication:

AWS Access Key
Assume IAM Role on Delegate
Assume Role Using STS on Delegate

Common Settings for All Credential Types

Use "PutSecretValue" Action to Update Secret Value
By default, Harness uses the UpdateSecret action to update secret values, which requires the secretsmanager:UpdateSecret permission for AWS Secrets Manager. Enable this option to use the PutSecretValue action instead, requiring the secretsmanager:PutSecretValue permission.
Use as Default Secrets Manager
Enable this option to make this Secrets Manager the default for all secret operations within your Harness account.

Credential Type: AWS Access Key

Use your AWS IAM user login credentials for authentication.

Prerequisites

Access Key ID and Secret Access Key: Obtain these from the JSON Key Policy or the AWS IAM console under Encryption Keys.
For detailed instructions, see Finding the Key ID and ARN in the AWS documentation.

Providing AWS Access Key ID

You have two options for adding the Access Key ID:

Plaintext:
Enter the Access Key ID directly into the AWS Access Key ID field.
Encrypted:
1. Click Create or Select a Secret.
2. In the dialog, create or select a Secret and enter the Access Key ID as the secret value.
3. Save and use the created secret for this configuration.

Providing AWS Secret Access Key

Click Create or Select a Secret.
Create or select an existing Secret with the Secret Access Key as its value.

Additional Fields

Secret Name Prefix: Add a prefix to all secrets stored under this Secrets Manager. For example, using devops as the prefix results in secrets like devops/mysecret. This is not a folder name.
Region: Select the appropriate AWS region for your Secrets Manager.

Credential Type: Assume IAM Role on Delegate

With this option, Harness uses the IAM role assigned to the AWS host running the selected Delegate for authentication.

Prerequisites

Ensure the Delegate host has the appropriate IAM role assigned.

Additional Fields

Refer to the Secret Name Prefix and Region settings described under the AWS Access Key section above.

Credential Type: Assume Role Using STS on Delegate

Harness uses AWS Security Token Service (STS) to assume a role. This option is commonly used for cross-account access or assuming roles within the same AWS account.

Prerequisites

Configure an IAM role in the target AWS account.

Required Fields

Role ARN: Enter the Amazon Resource Name (ARN) of the role you want to assume.
External ID: If provided by the account administrator, enter the External ID for additional security. See AWS External ID documentation for more details.
Assume Role Duration: Specify the session duration for the assumed role. For more information, refer to the AssumeRole API documentation.

Additional Fields

Refer to the Secret Name Prefix and Region settings described under the AWS Access Key section above.

Step 4: Setup Delegates

In Setup Delegates, enter Selectors for specific Delegates that you want to allow to connect to this connector.

Step 5: Test Connection

Once the Test Connection succeeds, select Finish. You can now see the connector in Connectors.

Reference JSON secrets

Harness allows you to manage the lifecycle of your secrets independently by referencing JSON secrets in the vault.

For example, you can store a secret in vault with the following JSON.

{
  "key1": "value1",
  "key2": {
    "key21": "value21",
    "key22": "value22"
  },
  "key3": {
    "key31": {
      "key311": "value311"
    }
  }
}

Here are sample outputs for the respective JSONPath from the above JSON file:

test-secret (without any # key)

{
  "key1": "value1",
  "key2": {
    "key21": "value21",
    "key22": "value22"
  },
  "key3": {
    "key31": {
      "key311": "value311"
    }
  }
}

test-secret#key1

"value1"

test-secret#key2

{
  "key21": "value21",
  "key22": "value22"
}

test-secret#key3

{
  "key31": {
    "key311": "value311"
 }
}

test-secret#key3.key31

{
  "key311": "value311"
}

test-secret#key3.key31.key311

 "value311"

info

You cannot use a JSON XPath for nested keys in expressions. For example, <+secrets.getValue("account.YOUR_SECRET_MANAGER://myVault/harness/testpath/example")>.

Harness provides limited support for keys that include dots. Keys with dots only work when the key is present at first level in the JSON. For example:

{
  "key.abc": "some-value",
  "key": {
    "nested.key1": "some-value"
  },
  "key.pqr": {
    "nestedKey": "some-value"
  },
  "pqr.xyz": "some-value",
  "pqr": {
    "xyz": "some-nested-value"
  }
}

Here are sample outputs for the respective JSONPath from the above JSON file:

/path/to/secret#key.abc returns some-value.
/path/to/secret#key.pqr returns {"nestedKey": "some-value"}.
/path/to/secret#key.nested.key1 and key.pqr.nestedKey are not supported.
/path/to/secret#pqr.xyz returns some-nested-value and not some-value. (Hierarchical paths take precedence over keys with dots.)

warning

Harness does not recommend using keys that include dots and might deprecate support in future releases.

Before you begin​

Permissions: Test AWS Permissions​

Step 1: Add a Secret Manager​

Step 2: Overview​

Step 3: Credential Details​

Common Settings for All Credential Types​

Credential Type: AWS Access Key​

Prerequisites​

Providing AWS Access Key ID​

Providing AWS Secret Access Key​

Additional Fields​

Credential Type: Assume IAM Role on Delegate​

Prerequisites​

Additional Fields​

Credential Type: Assume Role Using STS on Delegate​

Prerequisites​

Required Fields​

Additional Fields​

Step 4: Setup Delegates​

Step 5: Test Connection​

Reference JSON secrets​

Before you begin

Permissions: Test AWS Permissions

Step 1: Add a Secret Manager

Step 2: Overview

Step 3: Credential Details

Common Settings for All Credential Types

Credential Type: AWS Access Key

Prerequisites

Providing AWS Access Key ID

Providing AWS Secret Access Key

Additional Fields

Credential Type: Assume IAM Role on Delegate

Prerequisites

Additional Fields

Credential Type: Assume Role Using STS on Delegate

Prerequisites

Required Fields

Additional Fields

Step 4: Setup Delegates

Step 5: Test Connection

Reference JSON secrets