Set Up AWS Secrets Manager Access for Edge

This article describes how to grant an Ataccama edge instance access to secrets stored in AWS Secrets Manager so that edge jobs can retrieve credentials (such as database passwords or API keys) at runtime.

How edge compute accesses secrets

When an edge job needs a secret, it doesn’t read it with its own identity. Instead, the edge’s ECS task role calls sts:AssumeRole on a customer-managed IAM role that grants the required secretsmanager:GetSecretValue permission.

This indirection lets you keep secret-read permissions outside of the Ataccama-managed edge role and revoke them at any time by detaching or deleting the customer role.

The flow is:

The edge job’s ECS task role calls sts:AssumeRole on the customer-managed IAM role you create in Step 2: Create the IAM role.
The edge’s source policy only permits sts:AssumeRole against tagged roles. This tag is mandatory. Without it, the AssumeRole call is denied before it ever reaches your role’s trust policy.
Your role’s trust policy must allow the edge’s task role to assume it.
Your role’s permissions policy grants secretsmanager:GetSecretValue (and related actions) on the secret ARNs the edge needs to read.
If the secrets are encrypted with a customer-managed KMS key, your role also needs kms:Decrypt on that key, and the key’s resource policy must allow the role to decrypt.

The ataccama:edge:customer-provided = true tag is enforced by the edge’s IAM policy.

Without this tag, edge jobs receive AccessDenied on every secret lookup, regardless of how permissive the role’s trust and permissions policies are.

When to use this setup

Use this configuration when you want edge jobs to fetch credentials from AWS Secrets Manager and you already store (or plan to store) those secrets in your own AWS account.

The setup supports two scenarios:

Same-account: Secrets live in the same AWS account as the edge instance.
Cross-account: Secrets live in a separate AWS account that the edge account must reach via cross-account AssumeRole.

In both cases the steps are the same; only the trust policy on the customer role differs.

Prerequisites

An Ataccama edge instance already deployed in your AWS account. See Register an Ataccama-Managed Edge on AWS.
AWS permissions to create IAM roles and policies in the account where the secrets live.
The edge AWS account ID (the account where the edge instance is deployed). Available in the Ataccama Cloud Portal (Settings > Edge).
The ARNs of the AWS Secrets Manager secrets you want to expose to the edge.
For secrets encrypted with a customer-managed KMS key: the KMS key ARN.

Setup overview

Complete the following steps in the AWS account where the secrets live. This is the same as the edge account for the same-account scenario, or a different account for cross-account.

Step 1: Create the permissions policy.
Step 2: Create the IAM role, with the correct trust policy for your scenario and the required tag.
Step 3: Verify and record the role ARN.
Provide the role ARN to Ataccama by configuring a key vault connection in ONE. See [Configure a key vault connection].

Step 1: Create the permissions policy

Create an IAM policy that grants read access to the specific secrets you want the edge to use. Scope the resource list to exact secret ARNs. Avoid Resource: "*".

Replace <region>, <account-id>, and the secret name patterns with your values.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadSecrets",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:DescribeSecret",
        "secretsmanager:GetSecretValue",
        "secretsmanager:ListSecrets"
      ],
      "Resource": [
        "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name-or-prefix>*"
      ]
    }
  ]
}

secretsmanager:ListSecrets is required for the Test connection action in ONE to succeed. It is a list-level action and does not accept resource-level restrictions; AWS applies it at the account level.

If the secrets are encrypted with a customer-managed KMS key, add a second statement:

{
  "Sid": "AllowDecryptWithCustomerCmk",
  "Effect": "Allow",
  "Action": [
    "kms:Decrypt"
  ],
  "Resource": [
    "arn:aws:kms:<region>:<account-id>:key/<kms-key-id>"
  ]
}

You must also update the KMS key’s key policy to allow the role you create in Step 2: Create the IAM role to call kms:Decrypt. Granting kms:Decrypt in the IAM policy alone is not sufficient for customer-managed keys.

Step 2: Create the IAM role

Create an IAM role for the edge to assume and attach the policy from Step 1: Create the permissions policy.

Trust policy: same-account

If the secrets and the edge are in the same AWS account, use this trust policy. Replace <edge-account-id> with your AWS account ID.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<edge-account-id>:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

Trusting the account root is safe here because the right to call sts:AssumeRole on this role is gated by the edge task role’s own IAM policy as well as the required tag check. No other identity in the account can assume the role unless you explicitly grant them sts:AssumeRole permission.

Trust policy: cross-account

If the secrets live in a different AWS account than the edge instance, use this trust policy in the secrets account. Replace <edge-account-id> with the AWS account ID of the edge (not the secrets account).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<edge-account-id>:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::<edge-account-id>:role/ata-edge-*"
        }
      }
    }
  ]
}

The aws:PrincipalArn condition narrows the trust to the edge’s task and Lambda roles, which all share the ata-edge- name prefix. Combined with the required tag check enforced on the edge side, this gives you a least-privilege cross-account boundary.

Create the role

Follow the AWS docs to create a custom-trust IAM role, using the following values:

Trust policy: Paste from Trust policy: same-account or Trust policy: cross-account based on your setup.
Permissions policy: Attach the policy from Step 1: Create the permissions policy as a managed or inline policy.
Role name: A descriptive name, for example ataccama-edge-secrets-reader.
Tag (mandatory): ataccama:edge:customer-provided = true. The edge’s IAM policy contains a StringEquals condition on this tag, so any role without it cannot be assumed.

You can add any of your standard organizational tags as needed.

Step 3: Verify and record the role ARN

Open the role you just created.
Confirm:
- Trust relationship matches the trust policy you chose in Step 2: Create the IAM role.
- Permissions policy grants the Secrets Manager actions listed in Step 1: Create the permissions policy.
- Required tag is present.
Copy the role ARN. It has the form arn:aws:iam::<account-id>:role/<role-name>.

Removing the required tag from the role is equivalent to revoking access. Edge jobs will receive AccessDenied until the tag is restored.

Configure the key vault connection in ONE

In ONE, create a key vault connection to AWS Secrets Manager.

Go to Global settings > Secret management.

To access Global settings, select the Ataccama logo.
Select Add.
In Provider, choose AWS Secrets Manager.
Fill in the following:
- Name: A unique name for the key vault.
- Description (Optional): A description for this service.
- Secrets manager region: The AWS Region where the secrets live. Secrets Manager is a regional service: secrets live in one specific Region and must be retrieved from that Region’s endpoint.
- Role: The role ARN from Step 3: Verify and record the role ARN.
- Assume role region: The AWS Region whose STS endpoint is used to call AssumeRole. This is independent of where the role’s permissions take effect.
  
  For most setups, use the same Region as Secrets manager region. Specify a different Region only if your organization standardizes on a specific STS endpoint.
Save your changes.

You can now reference secrets stored in this vault when configuring data source credentials for edge processing:

When creating or editing the source connection, choose the key vault you created in Select a secret management service for this connection.
When adding credentials, select Use secret management service and provide the key name under which the secret is stored in your key vault.

The following section is relevant only if you operate multiple edges.

A single customer role can be used by more than one edge instance, but how you configure it depends on whether the edges live in the same AWS account.

Same AWS account

Two or more edges deployed in the same AWS account can share one role with no additional changes. Both edges' ECS task roles satisfy the same-account trust policy from Trust policy: same-account, and both already carry the required tag check on their source policy.

CloudTrail still attributes each GetSecretValue call to the originating edge: the role-session name has the form ataccama-job-session-<edge-instance-name> and the session is tagged with ataccama:edge:instance:name = <edge-instance-name>.

Different AWS accounts

If the edges are deployed in separate AWS accounts, extend the trust policy to list every edge account as a principal. Adjust the aws:PrincipalArn condition for the cross-account variant accordingly.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::<edge-account-id-1>:root",
          "arn:aws:iam::<edge-account-id-2>:root"
        ]
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::<edge-account-id-1>:role/ata-edge-*",
            "arn:aws:iam::<edge-account-id-2>:role/ata-edge-*"
          ]
        }
      }
    }
  ]
}

Considerations

No per-edge isolation on a shared role. The permissions policy applies uniformly: every edge that can assume the role gets the same access to the same secret ARNs. If edge A and edge B should see different secrets, create two roles (one per edge or per access scope) rather than sharing one.
Per-edge ABAC, if needed. If you want one shared role but per-edge restrictions on which secrets each edge can read, scope the permissions policy by the session tag the edge passes. Tag each secret with ataccama:edge:instance:name = <edge-instance-name> and add a Condition to the permissions policy:
```
"Condition": {
  "StringEquals": {
    "aws:ResourceTag/ataccama:edge:instance:name": "${aws:PrincipalTag/ataccama:edge:instance:name}"
  }
}
```
With this in place, the role grants access to a secret only when the secret’s ataccama:edge:instance:name tag matches the calling edge’s session tag.
Audit trail is preserved. Even with a shared role, every GetSecretValue CloudTrail event includes the session name and session tag, so you can always attribute a secret read to a specific edge instance.

Was this page useful?