Amazon Web Services (AWS)

The AWS integration enables Tidal Control to automatically execute compliance tests on your AWS environment via a cross-account role configuration.

Requirements

• Super User role in Tidal Control
• AWS IAM role management rights
• Access to AWS Management Console

Configuration step-by-step plan

We'll create a cross-account role in your AWS account that allows Tidal to retrieve compliance data. A cross-account role is an AWS mechanism that enables an external AWS account (Tidal) to securely access specific resources in your account without sharing credentials.

Configuration steps:

1. Note Tidal information
2. Create AWS IAM role
3. Assign permissions
4. Retrieve Role ARN
5. Complete integration

Why SecurityAudit?

The SecurityAudit policy is an AWS-managed, read-only policy designed for compliance and security monitoring tools. It gives Tidal read access to configuration metadata across your AWS services, never to the data stored within them. All access is read-only. Tidal Control never writes, modifies, or deletes anything in your AWS environment.

Step 1: Note Tidal information

• Go to Settings → Integrations in Tidal Control
• Click the plus icon next to Amazon Web Services
• Note the Tidal Account ID, the External ID and the Role session name prefix from the dialogue screen
• Tidal Control issues the External ID for your organisation. It is the same for every AWS role you connect, and it cannot be edited

Step 2: Create AWS IAM role

• Log in to AWS Management Console
• Navigate to IAM → Roles → Create role
• Select "AWS account" → "Another AWS account"
• Enter the Tidal Account ID (from step 1)
• Tick "Require external ID"
• Enter the External ID (from step 1)
• Click "Next"

Optional: limit the role to your organisation

Every session Tidal Control opens in your account is named after your organisation and the connection, starting with the Role session name prefix from step 1. CloudTrail shows this name, so you can tell which connection made a call. To accept only your organisation's sessions, add a session name condition to the role's trust policy. In IAM → Roles → your role → Trust relationships → Edit trust policy, use:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<Tidal Account ID>:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "<External ID>" },
        "StringLike": { "sts:RoleSessionName": "<Role session name prefix>*" }
      }
    }
  ]
}

Keep the principal as the Tidal account (:root), not a specific user or role in it. Tidal Control may change which identity in its account makes the call.

Step 3: Assign permissions

• Search for policy "SecurityAudit"
• Select SecurityAudit policy
• Click "Next" to continue
• (Optional) Add tags and click "Next"

Step 4: Retrieve Role ARN

• Give the role the name "Tidal Integration"
• Add description: "Read-only role for Tidal Control compliance monitoring"
• Click "Create role"
• Go to Roles overview and search for your new role
• Click on role name to open details
• Copy the Role ARN (save for Tidal configuration)

Step 5: Complete integration

• Return to Tidal dialogue screen
• Enter recognisable name for integration
• Paste the Role ARN (from step 4)
• The External ID is filled in by Tidal Control
• Open the Regions dropdown and select the AWS regions where your services run. You can select multiple regions. Check the top right of the AWS Console to see your current region.
• Click "Create" to save the connection

Verification

After successful configuration, Settings → Integrations shows AWS under Configured Integrations, AWS-specific tests are available in the Tests section, and test refreshes deliver results without authentication errors.

Troubleshooting

If the integration does not connect, check the following:

• Verify Role ARN correctly copied (no extra spaces)
• Check the External ID in the role's trust policy matches the one in the Tidal dialogue
• If you added a session name condition, check it ends in * and starts with your Role session name prefix
• If Tidal Control says the role can be assumed without an External ID, open the role's trust relationship and tick Require external ID, or add the sts:ExternalId condition with exactly the External ID from the dialogue (not a wildcard)
• Confirm SecurityAudit policy linked to role
• Verify AWS Region correctly selected

Still can't figure it out?

Send an email to support@tidalcontrol.com, and we'll get back to you as soon as possible.