USER MANUALS

AWS Secrets Manager

Virtual DataPort provides support to obtain credentials from the AWS Secrets Manager using two types of modes:

  • Default Credential Provider. Connects with the Credentials Vault using the AWS default credential provider chain. No credentials are required by configuration.

  • Access Keys. Connects with the Credentials Vault using CyberArk using AWS access keys.

Default Credential Provider

This mode relies on AWS SDK the authentication following the AWS default credential provider chain.

No credentials are required by Virtual DataPort. Select Default Credential Provider as authentication.

Enabling AWS Secrets Manager Default Credential Provider

Access Keys

This mode requires AWS Keys for authenticating with the Credentials Vault.

Select Access Keys as authentication.

Enabling AWS Secrets Manager Access Keys

You have to provide the following data:

  • AWS access key id: this is the access key of the user.

  • AWS secret access key: this is the secret access key of the user.

  • AWS region: this is region where the secrets are defined.

Naming Convention for AWS Secrets Manager Secrets

AWS Secrets Manager supports creating Other type of secrets specifying the field names used for storing the information. For this type of secrets, Virtual DataPort expects the secrets to be created with these naming conventions:

  • User names: it is expected at a field named username.

  • Passwords: it is expected at a field named password.

  • AWS access keys: it is expected at a field named access_key.

  • AWS secret keys: it is expected at a field named secret_key.

For example, a secret with user/password credentials.

{
  "username": "my-user",
  "password": "my-password"
}

and a secret with AWS credentials.

{
  "access_key": "my-access-key",
  "secret_key": "my-secret-key"
}

Required Policies

Virtual DataPort accesses to AWS Secrets Manager through the AWS Systems Manager Parameter Store. So, policies attached to the AWS user used must grant, at least, READ access to both systems.

For example, the following two policies can be attached:

  • Default AWS policy AmazonSSMReadOnlyAccess.

  • A custom policy granting only read access to AWS Secrets Manager:

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

Note that there are a default AWS policy allowing READ/WRITE to Secrets Manager which it is also valid: SecretsManagerReadWrite.

Add feedback