Amazon Web Services

Overview

AirMDR integrates with Amazon Web Services (AWS) to investigate security findings, query logs and metrics, retrieve cloud resource context, and automate response actions. The permissions required depend on the skills and workflows your organization uses.

Investigation access: Read security findings, audit events, logs, metrics, and resource information to investigate threats and enrich alerts.
Query access: Execute Athena queries for historical analysis. This requires access to source data, catalog metadata, and an S3 location where query results are written.
Write access: Perform response actions, such as archiving GuardDuty findings, updating Security Hub finding status, and uploading or deleting S3 objects.
Permissions-management access: Revoke IAM role sessions by attaching or updating an inline policy on the specified target role.

Setup at a glance

In a hurry, and GuardDuty plus CloudTrail is all you need? The Use a Script tab does step 1 and Option 1 of step 2 for you, in a single account. Otherwise:

Enable AWS GuardDuty — required for every method.

Choose one of the three authentication methods, based on your organization’s requirements. Each method defines its own permissions, so follow only the path you choose:

Method	When to use it	Permissions come from
Option 1: IAM User (Access Key Method)	Simplest to set up. Authenticates with programmatic access keys.	Create IAM policy, attached to the IAM user.
Option 2: IAM Role (Assume Role via STS)	Recommended for production and enterprise environments. Delegates access through STS.	Create IAM policy, attached to the IAM role.
Option 3: Multi-Account Integration using AWS StackSet Method	An AWS Organization with many member accounts.	The StackSet template and the Step 1b inline policies, both defined within the option. Skip Create IAM policy.

Configure AWS in the AirMDR Integrations Dashboard

After completing the above steps, see Where to find the generated AWS authentication parameters to locate any value you need in the AWS Console UI.

AWS Setup Prerequisites

What you need	Why it’s needed
AWS Account (free)	The account you sign in to the AWS Console with
Valid Payment Method (credit/debit card)	Required even if you stay within Free Tier
Verified Email Address	AWS will send confirmation and alerts
Enable MFA (Multi-Factor Authentication)	Secure your root user (HIGHLY recommended)
IAM Users and Roles	Create users instead of using the root account for everything
Knowledge of Regions	Decide which AWS region you want to deploy resources in (e.g., `us-east-1`, `eu-west-1`)
AWS CLI	Optional for the manual path. Required for the Use a Script path, which runs under a CLI profile.
Python 3 with pip	Required for the Use a Script path only.

Set up the integration

The connection dialog offers two paths, on the Do it Yourself and Use a Script tabs.

Use a Script — a generated Python script provisions a single account for you in a few minutes. It grants GuardDuty and CloudTrail access only, so it suits a GuardDuty-led deployment rather than full coverage.
Do it Yourself — the manual steps below. Required for STS role assumption and for an AWS Organization, and the direct route to full skill coverage. (You can also reach full coverage from the script path by widening its policy afterwards.)

Quick setup with the Use a Script tab

Scope: GuardDuty and CloudTrail only. The script’s policy grants nothing else, so the CloudWatch, Security Hub, S3, Athena and IAM skills — and Archive Guardduty Findings, which is a write action — all return AccessDenied. Six of the twenty-four skills work out of the box. Widen the policy afterwards, or follow the manual steps instead, if you need more.

The script automates Enable AWS GuardDuty and Option 1: it turns GuardDuty on, creates an IAM policy and user, attaches one to the other, and prints an access key pair for you to paste back into the form. It produces access keys only. Use the manual path for Option 2 or Option 3. Before you start, on the machine that will run the script:

Python 3 and pip. If python on your system is Python 2 or missing, use python3 and pip3 in the commands below.
An AWS CLI profile for the target account, defined in ~/.aws/config. If it is an IAM Identity Center (SSO) profile, sign in first with aws sso login --profile <name> — the script fails with an expired-token error otherwise.
Enough privilege on that profile. The script calls guardduty:ListDetectors, guardduty:CreateDetector, iam:GetPolicy, iam:CreatePolicy, iam:GetUser, iam:CreateUser, iam:ListAttachedUserPolicies, iam:AttachUserPolicy and iam:CreateAccessKey, plus iam:CreateServiceLinkedRole the first time GuardDuty is enabled in the account. That is close to IAM-administrator privilege — run it from an administrator workstation, not a shared or long-lived host.

Open Integrations → Amazon Web Services → Connections → + Create, fill in Instance and Description, then select the Use a Script tab.
Step 1 — Select the script language. Python is the only option.
Step 2 — Fill the details and download the script. Both fields are required, and both are written into the script before it downloads:
- SSO Profile That Will Run The Script — the named profile from your local ~/.aws/config. It becomes profile_name in the script’s boto3.Session.
- Region_name — the region this connection queries, e.g. us-east-1. GuardDuty is enabled in this region only.
Click the download icon beside Region_name.
Step 3 — Run it on the machine holding that profile:
pip install boto3 python script.py
Step 4 — Provide the credentials. Copy the Access Key ID and Secret Access Key the script prints into Access_key and Secret_key. Both are required on this tab.
Expand Advanced Configuration if you need a Remote Agent or an Expiry date, then click Save and run Authenticate on the connection.

The secret access key is printed to your terminal and nowhere else. Paste it into the form straight away and clear your scrollback — AWS will not display it again, and re-running the script mints an additional key rather than reprinting this one. An IAM user may hold only two access keys; past that the script reports Limit reached and returns nothing, so delete an unused key under IAM → Users → the user → Security credentials first.

What the script creates

Resource	Name	Notes
GuardDuty detector	—	Created only if the chosen region has none. An existing detector is reused.
IAM policy	`AirMDRSkillsReadOnlyPolicy`	`guardduty:Get`, `guardduty:List`, `guardduty:Describe*`, and `cloudtrail:DescribeTrails`, `GetTrailStatus`, `ListTrails`, `LookupEvents`. Reused if it already exists.
IAM user	`guardduty-cloudtrail-readonly-user`	Reused if it already exists.
Access key	—	A new pair on every run. This step is not idempotent.

Re-running the script is safe for the detector, policy and user — each is checked for before being created, so a policy you have since widened is left as it is — but it mints a fresh access key each time.

AirMDRSkillsReadOnlyPolicy is the script’s policy. It is a different object from AirMDR-ReadOnlyPolicy, the policy the manual Create IAM policy step builds, and from AirMDRReadOnlyPolicy, the inline policy inside the Option 3 StackSet template.

Widening the script’s policy

Edit AirMDRSkillsReadOnlyPolicy in IAM → Policies and add the fourteen read actions it is missing: sts:GetCallerIdentity, logs:DescribeLogGroups, logs:DescribeLogStreams, logs:GetLogEvents, logs:FilterLogEvents, cloudwatch:GetMetricStatistics, securityhub:GetFindings, securityhub:GetFindingsV2, securityhub:GetEnabledStandards, s3:ListAllMyBuckets, s3:ListBucket, s3:GetObject, s3:GetBucketLocation, iam:SimulatePrincipalPolicy. That unlocks eleven more skills — the CloudWatch, Security Hub read, S3 read and caller-permission ones — bringing the policy level with the read statement in Create IAM policy. The remaining seven need more than reads: Archive Guardduty Findings, Update AWS SecurityHub Finding Status, Put S3 Object, Delete S3 Objects and Revoke AWS Role Sessions are write actions, Execute AWS Athena Query needs the Athena set, and General AWS Query needs whatever its playbook calls. The callout in Create IAM policy lists the action for each.

Enable AWS GuardDuty

AWS GuardDuty is mandatory for integration with AirMDR because it serves as the primary threat detection engine in your AWS environment and AirMDR relies on GuardDuty findings to perform its core security use cases.

To enable AWS GuardDuty, refer to Getting started with GuardDuty.

Create IAM policy

Follow this step only if you are using Option 1 or Option 2. Both attach the policy it creates to their IAM user or role.Skip it for Option 3, which defines its own permissions in the StackSet template and the Step 1b inline policies, and for the Use a Script tab, which creates its own policy.

Create the AirMDR-ReadOnlyPolicy (Options 1 and 2 only)

To allow AirMDR to fetch telemetry data and perform read-only queries on your AWS environment, create a custom IAM policy covering the following managed-policy equivalents.

Creating a custom IAM policy in AWS is important when integrating with platforms like AirMDR because it allows you to define precise, least-privilege access.

Policy Name	Access Type	Importance
`AmazonGuardDutyReadOnlyAccess`	Read-Only	Required
`IAMReadOnlyAccess`	Read-Only	Recommended
`AmazonEC2ReadOnlyAccess`	Read-Only	Optional
`AmazonS3ReadOnlyAccess`	Read-Only	Optional
`AWSCloudTrail_ReadOnlyAccess`	Read-Only	Optional
`CloudWatchReadOnlyAccess`	Read-Only	Optional
`AWSSecurityHubReadOnlyAccess`	Read-Only	Optional
`AmazonEC2ContainerRegistryReadOnly`	Read-Only	Optional

Importance describes how central each area is to AirMDR’s use cases, not which actions the policy below grants. The JSON in the next step is a single custom policy covering all of them — it is not assembled from these managed policies. Trim it if you want a narrower scope.

Understand the Purpose of AWS Permissions Used by AirMDR

Expand this section to see the read permissions AirMDR uses, grouped by the AWS managed policy that would grant them, along with the skills that use each. It is helpful when reviewing access scope, customizing IAM policies, or conducting security reviews. Response and Athena permissions are listed per skill under Skills Provided by this Integration.

✅ AmazonEC2ReadOnlyAccess

🔹 Description:
Provides read-only access to EC2 and container metadata, enabling AirMDR to enrich alerts, assess security configurations, classify workloads by risk, and validate container deployment standards.🔸 Input Params Used:
service_name: ec2, method_name: describe_instances🔸 AWS Actions:
ec2:DescribeInstances🔸 Skills Used:
general_aws_query📎 Findings:

✅ AmazonGuardDutyReadOnlyAccess

🔹 Description:
Enables AirMDR to retrieve and analyze GuardDuty findings for suspicious activity related to S3 buckets and remote IPs, supporting threat pattern detection, anomaly analysis, and automated case enrichment.🔸 AWS Actions:
guardduty:ListFindings, guardduty:ListDetectors, guardduty:GetFindings🔸 Skills Used:
Get AWS Guard Duty Findings, List Guardduty Detectors, List Guardduty Findings

✅ AmazonS3ReadOnlyAccess

🔹 Description:
Provides read-only access to evaluate S3 bucket security by checking configurations, classifying data sensitivity, and validating real-world exposure risks.🔸 Input Params Used:
service_name: s3, method_name: [get_bucket_acl, get_public_access_block, get_bucket_policy, get_bucket_tagging, list_objects_v2]🔸 AWS Actions:
s3:ListAllMyBuckets, s3:ListBucket, s3:GetObject, s3:GetBucketLocation for the dedicated S3 skills; s3:GetBucketAcl, s3:GetBucketPublicAccessBlock, s3:GetBucketPolicy, s3:GetBucketTagging for bucket-configuration checks through General AWS Query🔸 Skills Used:
List S3 Buckets, List S3 Objects, Get S3 Objects, general_aws_query📎 Findings:

✅ AWSCloudTrail_ReadOnlyAccess

🔹 Description:
Grants read-only access to CloudTrail logs for reconstructing activity timelines, detecting suspicious patterns, and enriching alerts with user and process-level context.🔸 Input Params Used:
Attribute Key: ResourceName, Attribute Value: ec2 instance id, filter_key: sourceIPAddress🔸 AWS Actions:
cloudtrail:DescribeTrails, cloudtrail:GetTrailStatus, cloudtrail:LookupEvents🔸 Skills Used:
Lookup AWS CloudTrail Events, List Cloudtrail Trails📎 Findings:

✅ CloudWatchReadOnlyAccess

🔹 Description:
Allows read-only access to CloudWatch logs and metrics for analyzing VPC activity, extracting alert context, and enriching investigations with time-bound log insights and metric statistics.🔸 Input Params Used:
Log Group Name, Log Stream Name Prefix🔸 AWS Actions:
logs:DescribeLogGroups, logs:DescribeLogStreams, logs:GetLogEvents, logs:FilterLogEvents, cloudwatch:GetMetricStatistics🔸 Skills Used:
List Cloudwatch Log Groups, Filter AWS CloudWatch Log Events, Get AWS CloudWatch Log Events, Get AWS CloudWatch Metrics📎 Findings:

✅ AmazonEC2ContainerRegistryReadOnly

🔹 Description:
Provides read-only access to container workloads and images, letting AirMDR identify what a running task is executing and validate container deployment standards during an investigation.🔸 Input Params Used:
service_name: [ecs, ecr], method_name: [describe_tasks, describe_images]🔸 AWS Actions:
ecs:DescribeTasks, ecr:DescribeImages🔸 Skills Used:
general_aws_query

✅ AWSSecurityHubReadOnlyAccess

🔹 Description:
Provides read-only access to Security Hub findings and enabled standards, letting AirMDR correlate findings from Security Hub’s integrated sources and check compliance posture during an investigation.🔸 AWS Actions:
securityhub:GetFindings, securityhub:GetFindingsV2, securityhub:GetEnabledStandards🔸 Skills Used:
Get AWS SecurityHub Findings, Get AWS SecurityHub Findings v2, List Securityhub Standards

✅ IAMReadOnlyAccess

🔹 Description:
Enables validation of IAM permissions and detection of unusual user behavior, such as bulk S3 modifications, to support access risk analysis.🔸 Input Params Used:
service_name: iam, method_name: [get_user, list_attached_user_policies, simulate_principal_policy]🔸 AWS Actions:
iam:SimulatePrincipalPolicy for Get AWS Caller Permissions; iam:GetUser, iam:ListAttachedUserPolicies through General AWS Query. Behavioral detection pairs these with cloudtrail:LookupEvents, granted under the CloudTrail entry.🔸 Skills Used:
Get AWS Caller Permissions, general_aws_query, alongside Lookup AWS CloudTrail Events📎 Findings:

To create the policy:

Sign in to the AWS IAM Console of the account where you enabled GuardDuty.
Search for IAM in the top menu bar.
In the IAM dashboard, click on IAM resources → Policies.
Click Create policy in the top right corner.

Select the JSON tab and paste the following:

You can update the policy permissions in the JSON as per your requirement.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AirMDRInvestigationRead",
      "Effect": "Allow",
      "Action": [
        "sts:GetCallerIdentity",
        "cloudtrail:LookupEvents",
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams",
        "logs:GetLogEvents",
        "logs:FilterLogEvents",
        "cloudwatch:GetMetricStatistics",
        "guardduty:ListDetectors",
        "guardduty:ListFindings",
        "guardduty:GetFindings",
        "securityhub:GetFindings",
        "securityhub:GetFindingsV2",
        "securityhub:GetEnabledStandards",
        "s3:ListAllMyBuckets",
        "s3:ListBucket",
        "s3:GetObject",
        "s3:GetBucketLocation",
        "iam:SimulatePrincipalPolicy",
        "ec2:DescribeInstances",
        "ecs:DescribeTasks",
        "ecr:DescribeImages",
        "s3:GetBucketAcl",
        "s3:GetBucketPublicAccessBlock",
        "s3:GetBucketPolicy",
        "s3:GetBucketTagging",
        "iam:GetUser",
        "iam:ListAttachedUserPolicies"
      ],
      "Resource": "*"
    }
  ]
}

The actions from ec2:DescribeInstances onwards serve General AWS Query. Drop them if your playbooks do not use that skill, and add whatever other actions the methods your playbooks do call require.

The statement above is read-only, and covers every read skill except Athena. Two groups of skills need actions added in a second, clearly-labelled statement. Add only the rows for skills you intend to use.Response skills — these change state in your AWS account:

Skill	Action to add
Archive Guardduty Findings	`guardduty:ArchiveFindings`
Update AWS SecurityHub Finding Status	`securityhub:BatchUpdateFindings`
Put S3 Object	`s3:PutObject`
Delete S3 Objects	`s3:DeleteObject`
Revoke AWS Role Sessions	`iam:PutRolePolicy`, restricted to the intended target role ARNs

Athena — a query skill, but it writes its results to S3, so it is not covered by the read statement:

Skill	Actions to add
Execute AWS Athena Query	`athena:StartQueryExecution`, `athena:GetQueryExecution`, `athena:GetQueryResults`, plus the source-data, catalog, and result-location access under IAM permissions reference

Click Next.
In the Review and create section, provide the Policy details:
- Policy name – Provide a meaningful name like AirMDR-ReadOnlyPolicy.
- Description (Optional) – Add a short description for this policy.
Under Permissions defined in this policy, confirm the actions listed match what you pasted and meet your security requirements. A policy has no trust policy — that is set on the role in Option 2.
Click Create policy.

Option 1: IAM User (Access Key Method)

Use this method if you prefer to authenticate via programmatic access credentials (Access Key ID and Secret Key).

Create an IAM user and generate access keys

Navigate to IAM → IAM Dashboard.
Click on IAM resources → Users.
Click Create user in the top right corner.
Enter a User name (e.g., airmdr-integrator).
Click Next.
In the Set permissions section, select Attach policies directly.
Search for and select AirMDR-ReadOnlyPolicy.
See Create IAM policy for detailed steps to define AirMDR-ReadOnlyPolicy in IAM.
Click Next.
In the Review and create section, click Create user.
Search for and select the user you just created (e.g., airmdr-integrator).
Open the Security credentials tab and, under Access keys, click Create access key.
Select the Command Line Interface (CLI) use case, then select the confirmation checkbox.
Click Next.
In the Set description tag - optional section, provide the Description tag value.
- Description tag value (Optional) – Access key for AirMDR’s use case.
Click Create access key.
On the Retrieve access keys screen, copy the:
- ✅ Access Key ID
- ✅ Secret Access Key
This is the only time you can view the Access Key ID and Secret Access Key, so it is recommended to download the .csv file and save it securely in a password manager or organization vault for future reference.
Click Done.

Option 2: IAM Role (Assume Role via STS)

Use this method if you prefer to delegate access securely using AWS Security Token Service (STS). Recommended for production and enterprise environments.

Create an IAM role for cross-account access

This creates an IAM role in your account that AirMDR’s AWS account assumes through STS. No long-lived credentials leave your account; AirMDR receives short-lived session credentials each time it assumes the role.

Navigate to IAM → IAM Dashboard.
Click on IAM resources → Roles.
Click Create role in the top right corner.
In Select a trusted entity → Trusted entity type, choose AWS account.
In the An AWS account section, choose Another AWS account.
Enter the AirMDR AWS Account ID: 242133657058 only as an identifier of the account that can use this role.
Generally, the Account ID is a 12-digit number. Use only the Account ID mentioned above.
Select the Require external ID checkbox (best practice when a third party will assume this role).
Enter a unique, hard-to-guess value for the External ID, for example airmdr-role-2026-5c1e8b7f42d9a036. AirMDR treats it as a secret.
The ExternalId value must have a minimum of 2 characters and a maximum of 1,224 characters. The value must be alphanumeric without white space. It can also include the following symbols: plus (+), equal (=), comma (,), period (.), at (@), colon (:), forward slash (/), and hyphen (-).

Leave Require MFA unchecked. AirMDR assumes the role programmatically and cannot present an MFA token, so enabling it blocks access.
Click Next.
In the Add permissions section, search for and select AirMDR-ReadOnlyPolicy.
See Create IAM policy for detailed steps to define AirMDR-ReadOnlyPolicy in IAM.
Click Next.
In the Name, review and create section:
- Provide the Role details:
  - Role Name – Provide a meaningful name like AirMDR-Role.
  - Description (Optional) – Add a short description for this role.
- Review your selections and confirm they are correct.
  - Permissions – AirMDR-ReadOnlyPolicy is attached.
  - Trust policy – the principal is arn:aws:iam::242133657058:root, with an sts:ExternalId condition matching the external ID you entered.
- Click Create role.
Open the role you just created (e.g., AirMDR-Role).
Copy and securely save:
- ✅ Role ARN (Amazon Resource Name)
- ✅ External ID (entered earlier)
You will enter both in the AirMDR connection form — see Configure AWS in the AirMDR Integrations Dashboard. If the AirMDR team is configuring the connection on your behalf, share them through a secure channel, never plain email or chat.
Click Done.

Option 3: Multi-Account Integration using AWS StackSet Method

For organizations managing multiple accounts under an AWS Organization, AirMDR supports StackSet-style delegated access via a root account.

Connect every account in an AWS Organization

Connects AirMDR to every account in an AWS Organization through two IAM roles: one in the management account that enumerates the organization, and one in each member account that AirMDR reads from.Who runs this: an AWS administrator with IAM and CloudFormation StackSet permissions in the organization’s management account.Time: about 20 minutes, plus StackSet deployment time.

How the access chain works

Read this before you start — it determines what you put in each trust policy.

Air MDR AWS Multi Account Authentication Workflow

Two hops, not one. AirMDR assumes the management-account role, and then assumes the member-account role from that session. A member account therefore trusts its own organization’s management account, never AirMDR’s account directly.This matters for the member role’s trust policy. If you set it to trust 242133657058 — as the earlier template did — the second hop is denied, because the principal making that call is AirMDROrgAccessRole, not AirMDR’s account. It is the single most common setup mistake, so when you fill in TrustedAccountId in Step 2, put your management account ID there, not AirMDR’s.

Already deployed the old template, where the member role trusts 242133657058 directly? It keeps working — AirMDR detects that topology and assumes accordingly.

Step 1. Create the management account role

Go to IAM → Roles → Create role.
Trusted entity type: AWS account.
Select Another AWS account and enter account ID 242133657058.
Tick Require external ID and enter a unique string. Save it — this is your root_account_external_id.
Attach the managed policy AWSOrganizationsReadOnlyAccess.
Name the role AirMDROrgAccessRole and create it.

External ID format: 2–1,224 characters, alphanumeric, no whitespace. These symbols are also allowed: + = , . @ : / -. Use something unguessable, for example airmdr-orgaccess-2026-a7f3c9e21b8d4f60.

Step 1b. Add the inline policies

AWSOrganizationsReadOnlyAccess alone is not enough. It grants only organizations:Describe* and organizations:List*, with no sts:AssumeRole, so the role cannot reach a single member account.Open the role → Add permissions → Create inline policy → JSON. Policy 1 is required; Policy 2 is optional.Policy 1 — AirMDRAssumeMemberRoles (required). Lets the role make the second hop:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeMemberAccountReadRoles",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::*:role/AirMDRReadOnlyRole"
    }
  ]
}

If you changed RoleName in Step 2, match it here.Policy 2 — AirMDRManagementAccountRead (optional). Needed only if AirMDR should read data in the management account itself. The StackSet does not deploy into the management account, so that account is read through this role directly, and without this policy every such read returns AccessDenied.Everything else works without it: Authenticate, enumerating the organization’s accounts, and every read in a member account. Many organizations keep workloads out of the management account, as AWS recommends, and can skip this policy. If you skip it:

Run single-account skills with an explicit member account_id. With account_id omitted they default to the management account and fail.
Fan-out skills still return every member account, but the management account’s slice errors. Lookup AWS CloudTrail Events and the CloudWatch skills report it as status: "error"; Get AWS Guard Duty Findings drops it silently.
General AWS Query needs an explicit member account_id. It stops at the first account that errors, and the management account is always part of its sweep, so without account_id the whole query fails.

If you do want management-account data, the policy grants the same reads the StackSet gives each member account — see the permission set for what is included and left out:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AirMDRServiceRead",
      "Effect": "Allow",
      "Action": [
        "sts:GetCallerIdentity",
        "cloudtrail:LookupEvents",
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus",
        "guardduty:ListDetectors",
        "guardduty:ListFindings",
        "guardduty:GetFindings",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams",
        "logs:FilterLogEvents",
        "logs:GetLogEvents",
        "cloudwatch:GetMetricStatistics",
        "securityhub:GetFindings",
        "securityhub:GetFindingsV2",
        "securityhub:GetEnabledStandards",
        "iam:SimulatePrincipalPolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AirMDRS3Read",
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets",
        "s3:ListBucket",
        "s3:GetObject",
        "s3:GetBucketLocation"
      ],
      "Resource": "*"
    }
  ]
}

Step 1c. Record three values

From the role’s summary page:

Value	Where	Example
`root_account_role_arn`	Role ARN	`arn:aws:iam::123456789012:role/AirMDROrgAccessRole`
`root_account_id`	The 12-digit account in that ARN	`123456789012`
`root_account_external_id`	What you entered in step 4	`airmdr-orgaccess-2026-a7f3c9e21b8d4f60`

root_account_id also tells AirMDR which account is the management account, so it can route reads there correctly instead of looking for a member role that does not exist.

Step 2. Deploy the member role by StackSet

Still in the management account.

CloudFormation → StackSets → Create StackSet.
Permissions model: Service-managed permissions.
Prerequisite: Template is ready. Specify template: Upload a template file.
Upload the YAML below.

Edit the two placeholder defaults before you upload the template. Both ship as <REPLACE WITH ...> and the StackSet will deploy a broken role if you leave them.

Parameter	Replace with
`TrustedAccountId`	Your organization’s management (root) account ID — the 12-digit account you are creating this StackSet from. Not AirMDR’s `242133657058`.
`ExternalIdVar`	A new unique secret of your own. This is a different secret from the one in Step 1 — do not reuse it. It becomes your `cross_account_external_id`.

You can either edit the Default: values in the YAML before uploading, or leave them and override both in the Parameters screen at item 6 below.

Same format rule as Step 1 for the external ID: 2–1,224 characters, alphanumeric, no whitespace, and the symbols + = , . @ : / -.

AWSTemplateFormatVersion: "2010-09-09"
Description: "IAM Role with ReadOnly permissions for deployment across child accounts"

Parameters:
  RoleName:
    Type: String
    Default: "AirMDRReadOnlyRole"
    Description: "Name of the IAM role"
  TrustedAccountId:
    Type: String
    Default: "<REPLACE WITH ROOT ACCOUNT ID>"
    Description: "AWS Account ID that can assume this role"
  ExternalIdVar:
    Type: String
    Default: "<REPLACE WITH EXTERNAL ID>"
    Description: "External ID that must be supplied when assuming this role"

Resources:
  AirMDRReadOnlyRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Ref RoleName
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              AWS: !Sub "arn:aws:iam::${TrustedAccountId}:root"
            Action: "sts:AssumeRole"
            Condition:
              StringEquals:
                "sts:ExternalId": !Ref ExternalIdVar
      Policies:
        - PolicyName: "AirMDRReadOnlyPolicy"
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  # Identity - used to verify the connection
                  - "sts:GetCallerIdentity"
                  # CloudTrail
                  - "cloudtrail:LookupEvents"
                  - "cloudtrail:DescribeTrails"
                  - "cloudtrail:GetTrailStatus"
                  # GuardDuty
                  - "guardduty:ListDetectors"
                  - "guardduty:ListFindings"
                  - "guardduty:GetFindings"
                  # CloudWatch Logs
                  - "logs:DescribeLogGroups"
                  - "logs:DescribeLogStreams"
                  - "logs:FilterLogEvents"
                  - "logs:GetLogEvents"
                  # CloudWatch Metrics
                  - "cloudwatch:GetMetricStatistics"
                  # Security Hub
                  - "securityhub:GetFindings"
                  - "securityhub:GetFindingsV2"
                  - "securityhub:GetEnabledStandards"
                  # Permission pre-flight
                  - "iam:SimulatePrincipalPolicy"
                Resource: "*"

              # You can limit the resources as per need and org policy.
              - Effect: Allow
                Action:
                  - "s3:ListAllMyBuckets"
                  - "s3:ListBucket"
                  - "s3:GetObject"
                  - "s3:GetBucketLocation"
                Resource: "*"
      Tags:
        - Key: "Purpose"
          Value: "AirMDRReadOnly"
        - Key: "ManagedBy"
          Value: "CloudFormation-StackSets"

Outputs:
  RoleArn:
    Description: "ARN of the created role"
    Value: !GetAtt AirMDRReadOnlyRole.Arn
    Export:
      Name: !Sub "${AWS::StackName}-RoleArn"

  RoleName:
    Description: "Name of the created role"
    Value: !Ref AirMDRReadOnlyRole
    Export:
      Name: !Sub "${AWS::StackName}-RoleName"

  AssumeRoleCommand:
    Description: "AWS CLI command to assume this role"
    Value: !Sub "aws sts assume-role --role-arn ${AirMDRReadOnlyRole.Arn} --role-session-name AirMDRReadOnlySession --external-id ${ExternalIdVar}"

StackSet name: e.g. AirMDR-StackSet.
Parameters: set TrustedAccountId to your own management account ID and ExternalIdVar to your chosen secret. Leave RoleName at its default unless you intend to rename the member role — if you change it, update the Resource ARN in the Step 1b AirMDRAssumeMemberRoles policy and the cross_account_role_name in Step 3 to match.
Configure options: Managed execution → Inactive. Tick the IAM capabilities acknowledgement.
Deployment options:
- Add stacks to stack set → Deploy new stacks
- Deployment targets → Deploy to organization
- Automatic deployment → Activated (new accounts are covered automatically)
- Account removal behaviour → Delete stacks
- Specify regions → exactly one region. The template creates an IAM role, and IAM is global, so a second region’s stack would try to create the same role again and fail with AlreadyExists. Which region you pick does not matter to AirMDR — the role works in every region. Picking the one your security data lives in keeps things tidy.
- Region concurrency → Sequential; Concurrency mode → Strict failure tolerance
Review → Submit, then wait for every stack instance to reach CURRENT.

Write actions. This policy is read-only. Skills that change state in your account — archiving GuardDuty findings, updating Security Hub workflow status, writing or deleting S3 objects, revoking IAM role sessions — need guardduty:ArchiveFindings, securityhub:BatchUpdateFindings, s3:PutObject, s3:DeleteObject and iam:PutRolePolicy. Athena additionally needs athena:StartQueryExecution, athena:GetQueryExecution and athena:GetQueryResults. Add them as a second, clearly-labelled statement only if you want AirMDR to take those actions.

The permission set

The template’s two statements — the service reads and the S3 reads — are the complete set of read actions the built-in skills call. They are split so you can scope the S3 statement’s Resource down from * to the specific bucket ARNs your investigations use, without touching the rest. That scoping is worth doing: it is the only statement that reaches object contents.If you add the optional AirMDRManagementAccountRead policy in Step 1b, it is the same two statements, so the management account gets the same reads as each member. If you scope the S3 statement in the template, scope it there too. Neither contains sts:AssumeRole — that grant lives separately in AirMDRAssumeMemberRoles, and only the management account role needs it.Two things the template deliberately leaves out:

General AWS Query calls whatever service and method a playbook names, so no fixed list can cover it. Add the actions your playbooks actually use — ec2:DescribeInstances and s3:GetBucketPolicy are common starting points.
Athena needs athena:StartQueryExecution, athena:GetQueryExecution and athena:GetQueryResults, plus the source-data and result-location access described under IAM permissions reference.

Step 3. Create the connection in AirMDR

Follow Configure AWS in the AirMDR Integrations Dashboard, entering these values in Step 4 of the Do it Yourself tab. Leave Steps 2 and 3 blank — they are for the single-account methods.

Field	Value
`root_account_role_arn`	From Step 1c
`root_account_external_id`	From Step 1, first external ID
`root_account_id`	Your management account, 12 digits
`cross_account_role_name`	`AirMDRReadOnlyRole` — the name, not an ARN
`cross_account_external_id`	`ExternalIdVar` from Step 2
`region_name`	The region your security data is in — where AirMDR will query. Independent of the StackSet region.

Leave assume_role_in_root_account unset. AirMDR works out which trust topology your member roles use on the first assume and reuses that answer for the rest of the query. Pin it only if you want to skip that one-off detection — true for the template in this guide, false for the older one. A pinned value is obeyed exactly, so an incorrect pin produces AccessDenied rather than silently falling back.

Step 4. Verify

Save the connection, then run Authenticate on it from the Connections tab. This runs the Verify Authentication skill, and a green result confirms AirMDROrgAccessRole is assumable — and nothing more. It only calls sts:GetCallerIdentity, which any principal may call, so it cannot tell you whether the member roles work.Prove the second hop with a real query. Run Lookup AWS CloudTrail Events with no account_id. CloudTrail event history is on by default in every account, so this tests the access chain without depending on any other service being set up. Read AccountResults[] in the response — it has one entry per active account in the organization:

Every entry status: "success" — the access chain works for every account.
status: "error" with AccessDenied on sts:AssumeRole for every member — the member trust policy, the external ID, or the Step 1b sts:AssumeRole grant is wrong.
The same error for some members only — the StackSet has not reached those accounts. Check its stack instances; accounts that joined after deployment are covered only if automatic deployment is on.
AccessDenied on a cloudtrail: action for the management account only — expected if you skipped the optional Step 1b Policy 2, AirMDRManagementAccountRead. Otherwise that policy is missing or incomplete.

Do not verify with Get AWS Guard Duty Findings. It fans out the same way but returns only the combined findings, with no per-account status — so an empty result can mean “no findings” or “every account failed”, and you cannot tell which. To check GuardDuty in a specific account, run List Guardduty Detectors with that account_id: an empty DetectorIds list means GuardDuty is not enabled there.

Account coverage

Every skill that calls AWS accepts an optional account_id input — a 12-digit member account ID — so any skill can be pointed at any account in the organization. What differs is the behaviour when you omit it.Fan out across every account when account_id is omitted: Get AWS Guard Duty Findings, Lookup AWS CloudTrail Events, Filter AWS CloudWatch Log Events, Get AWS CloudWatch Metrics, General AWS Query. They report per-account outcomes differently:

Skill	Per-account status
Lookup AWS CloudTrail Events	`AccountResults[]` — `account_id`, `status`, and the error when one occurred. A failing account is skipped, not fatal.
Filter AWS CloudWatch Log Events, Get AWS CloudWatch Metrics	`account_results[]` — same shape, lowercase key. A failing account is skipped, not fatal.
Get AWS Guard Duty Findings	None. Returns only the combined findings; failing accounts are skipped silently.
General AWS Query	None. Returns one raw response per account, and stops at the first account that errors, reporting that error.

Fall back to the management account when account_id is omitted: every other skill — List Guardduty Detectors, List Guardduty Findings, List Cloudtrail Trails, List Cloudwatch Log Groups, Get AWS CloudWatch Log Events, all S3 skills, all Security Hub skills, Execute AWS Athena Query, and both IAM skills. Reading the management account this way needs the optional Step 1b Policy 2 on AirMDROrgAccessRole; without it they return AccessDenied. If you skipped that policy, always pass a member account_id to these skills.

Configure AWS in the AirMDR Integrations Dashboard

Navigate to AirMDR, provide the credentials, and click Login.
In the left navigation pane, select Integrations.
Search for “Amazon Web Services”, select the Connections tab, and click the + Create icon. The Add New Connection dialog opens.
Fill in the two fields at the top — both are required:
- Instance — a unique name for this connection (e.g., your org name-AWS), used to identify it when running skills.
- Description — what this connection is for.

Stay on the Do it Yourself tab — for the scripted alternative see Quick setup with the Use a Script tab. Under Steps to provide credentials, complete only the numbered step that matches the method you set up, and leave the other two blank. The dialog capitalizes each field label (Root_account_role_arn); the rest of this guide uses the lowercase parameter names (root_account_role_arn) for the same fields.

Authentication method	Step in the dialog	Fields to provide
IAM User (Access Key Method)	Step 2	`Access_key` — Access Key ID of the IAM user `Secret_key` — Secret Access Key associated with the IAM user. This is generated when you create the access key.
IAM Role (Assume Role via STS)	Step 3	`Role_arn` — ARN of the IAM role to assume `External_id` — External ID configured in the role’s trust policy
Multi-Account (AWS StackSet Method)	Step 4	`Root_account_role_arn` — ARN of the `AirMDROrgAccessRole` in the management account `Root_account_external_id` — External ID in that role’s trust policy `Root_account_id` — 12-digit ID of the root/management account `Cross_account_role_name` — name of the member-account role, e.g. `AirMDRReadOnlyRole` `Cross_account_external_id` — the `ExternalIdVar` from the StackSet `Assume_role_in_root_account` — optional; leave blank so AirMDR detects the trust topology

In Step 5, enter Region_name — the AWS region this connection queries (e.g., us-east-1). This field is required.
Advanced Configuration (optional) — expand it to set a Remote Agent or an Expiry date for the credentials. Leave both unset unless your deployment requires them.
Click Save.
Back on the Connections tab, run Authenticate on the new connection to validate the credentials and authorize it.

One connection covers one region and one authentication method. To query a second region, create a second connection with a different region_name.

Where to find the generated AWS Authentication Parameters in the Console (UI Steps)

Credential	How to Get It (UI Path)
Access Key ID	IAM → Users → Select user → Security credentials tab → Scroll to Access keys section
Secret Access Key	Shown only once during Access Key creation. If lost, delete and create a new access key under “Access keys”
Role ARN (`role_arn`, Option 2)	IAM → Roles → Click the role you created (e.g., `AirMDR-Role`) → Copy ARN from the top section
External ID (`external_id`, Option 2)	IAM → Roles → Select the role → Trust relationships → View the policy to see `sts:ExternalId`
Root Account Role ARN (`root_account_role_arn`, Option 3)	In the management account: IAM → Roles → `AirMDROrgAccessRole` → Copy ARN
Root Account External ID (`root_account_external_id`, Option 3)	Management account: IAM → Roles → `AirMDROrgAccessRole` → Trust relationships → `sts:ExternalId`
Region Name	Top-right corner of AWS Console (e.g., `us-east-1`, `ap-south-1`) or in the region dropdown in any service page
Root Account ID	Click account name (top-right) → My Account → Find 12-digit Account ID under “Account settings”
Cross Account Role Name	IAM → Roles (in member account) → Name of role created (e.g., `AirMDRReadOnlyRole`)
Cross Account External ID	IAM → Roles (in member account) → Select role → Trust relationships → Check for `sts:ExternalId` value
Assume_role_in_root_account	Optional, Option 3 only, in Step 4 of the dialog. Leave blank so AirMDR detects the trust topology.

Skills Provided by this Integration

The AWS integration provides skills to investigate security findings, query logs and metrics, access S3 objects, analyze historical data, and automate response actions. Each table below lists the IAM actions that skill requires. Grant them to the IAM user or role configured for the AirMDR connection, and restrict them to the smallest set of resources your workflows need. Permissions that depend on an optional feature are listed separately under IAM permissions reference.

CloudTrail — Audit and Investigation

Skill name	Purpose	IAM actions required	Scope and notes
Lookup AWS CloudTrail Events	Retrieve recent management events and supported Insights events using event attributes and time filters. Supports investigating account activity and changes to AWS resources.	`cloudtrail:LookupEvents`	Retrieves events in the selected region.
List Cloudtrail Trails	List configured CloudTrail trails with their full configuration and current logging status.	`cloudtrail:DescribeTrails`, `cloudtrail:GetTrailStatus`	Uses `DescribeTrails`, not `ListTrails`: `ListTrails` returns only name, ARN, and home region, and does not support shadow trails.

CloudTrail LookupEvents retrieves management and supported Insights events within the last 90 days in a region. It does not retrieve data events. Query older events or data events from a configured logging destination, such as CloudTrail logs stored in S3 through Athena.

CloudWatch — Logs and Metrics

Skill name	Purpose	IAM actions required	Scope and notes
List Cloudwatch Log Groups	Discover available CloudWatch Logs log groups in the configured account and region.	`logs:DescribeLogGroups`	Discovers log groups in the selected account and region.
Filter AWS CloudWatch Log Events	Search log events across streams in a log group using filter patterns and a specified time range.	`logs:FilterLogEvents`	Restrict access to the required log groups.
Get AWS CloudWatch Log Events	Retrieve events from a specified log stream within a log group.	`logs:GetLogEvents`	Restrict access to the required log streams. Accepts either `log_group_name` or `log_group_identifier`, not both.
Get AWS CloudWatch Metrics	Retrieve metric statistics for specified namespaces, metrics, dimensions, and time ranges.	`cloudwatch:GetMetricStatistics`	Retrieves statistics for the requested metrics and dimensions.
Build Cloudwatch Filter Pattern	Construct a CloudWatch Logs filter pattern using keywords, exclusion terms, and JSON field conditions.	None	Constructs a filter pattern locally without calling an AWS API.

logs:DescribeLogStreams is required: the integration discovers log streams before retrieving events from them.

GuardDuty — Threat Investigation and Response

Skill name	Purpose	IAM actions required	Scope and notes
Get AWS Guard Duty Findings	Discover GuardDuty detectors, list matching findings, and retrieve detailed findings in one call.	`guardduty:ListDetectors`, `guardduty:ListFindings`, `guardduty:GetFindings`	Restrict detector-level actions to the required detector ARNs.
List Guardduty Detectors	List the GuardDuty detectors in the account and region.	`guardduty:ListDetectors`	Detector discovery only.
List Guardduty Findings	List finding IDs matching a filter, without retrieving finding detail.	`guardduty:ListFindings`	Takes a detector ID. Pair with Get AWS Guard Duty Findings to retrieve detail.
Archive Guardduty Findings	Archive selected findings after investigation while preserving them for later review.	`guardduty:ArchiveFindings`	Write action. Restrict to the required GuardDuty detector ARNs.

Security Hub — Findings and Compliance

Skill name	Purpose	IAM actions required	Scope and notes
Get AWS SecurityHub Findings	Retrieve and filter security findings in AWS Security Finding Format (ASFF).	`securityhub:GetFindings`	Retrieves ASFF findings available to the configured account.
Get AWS SecurityHub Findings v2	Retrieve findings in Open Cybersecurity Schema Framework (OCSF) format using composite filters and sort criteria.	`securityhub:GetFindingsV2`	Calls the `GetFindingsV2` API, which has its own IAM action. Security Hub, not Security Hub CSPM.
List Securityhub Standards	List enabled security standards and their subscription status for the configured account and region.	`securityhub:GetEnabledStandards`	Retrieves enabled standards and subscription status.
Update AWS SecurityHub Finding Status	Update a finding’s workflow status to `NEW`, `NOTIFIED`, `RESOLVED`, or `SUPPRESSED`.	`securityhub:BatchUpdateFindings`	Write action. Permits workflow-status updates for the intended findings.

GetFindings and GetFindingsV2 are separate APIs with separate IAM actions. Grant securityhub:GetFindings for the ASFF skill and securityhub:GetFindingsV2 for the OCSF skill; grant both if you use both. securityhub:ListFindings and securityhub:DescribeHub are not called by any skill.

Amazon S3 — Object Management

Skill name	Purpose	IAM actions required	Scope and notes
List S3 Buckets	List the buckets in the account, optionally filtered by name prefix, region, or count.	`s3:ListAllMyBuckets`	Account-wide. Add `s3:GetBucketLocation` when filtering by `bucket_region`.
List S3 Objects	List object keys and metadata within a specified S3 bucket.	`s3:ListBucket`	Grant on the bucket ARN. Use an `s3:prefix` condition when listings must be restricted to a prefix.
Get S3 Objects	Download the contents of specified objects for investigation or analysis.	`s3:GetObject`	Grant on the required object ARNs or prefixes. Add `kms:Decrypt` for SSE-KMS encrypted objects.
Put S3 Object	Upload an object, or replace the object at an existing key, from a supplied body and content type.	`s3:PutObject`	Write action. Restrict to the approved bucket and object prefix. Add `kms:GenerateDataKey` and `kms:Decrypt` if the bucket uses SSE-KMS by default.
Delete S3 Objects	Delete a list of object keys from a bucket.	`s3:DeleteObject`	Write action. Restrict to the approved object ARNs or prefixes. Deletes are not version-specific, so in a versioned bucket this creates a delete marker.

Athena — Historical Data Analysis

Skill name	Purpose	IAM actions required	Scope and notes
Execute AWS Athena Query	Execute SQL against authorized datasets, wait for query completion, and retrieve results. Supports historical log analysis and security investigations.	`athena:StartQueryExecution`, `athena:GetQueryExecution`, `athena:GetQueryResults`	Always runs in the `primary` workgroup — scope to that workgroup’s ARN. Also requires access to source data, catalog metadata, and the query result location — see Athena data-access dependencies.

Athena permissions alone do not provide access to the underlying data. Retrieving query results also requires S3 access to the result location. Even a SELECT query writes query results.

The skill takes an optional database_name and output_location. When database_name is omitted it queries the default database; when output_location is omitted it runs in the primary workgroup and writes results to that workgroup’s configured result location, so the workgroup must have one set.

IAM — Permission Checks and Session Response

Skill name	Purpose	IAM actions required	Scope and notes
Get AWS Caller Permissions	Simulate whether the configured IAM principal has the specified permissions. Supports identifying missing permissions before running other skills.	`sts:GetCallerIdentity`, `iam:SimulatePrincipalPolicy`	Resolves the connection’s own principal, then simulates against it. An assumed-role ARN is normalized to its underlying role ARN before simulation.
Revoke AWS Role Sessions	Attach or refresh an inline deny policy to deny requests using role credentials issued before a specified cutoff time.	`iam:PutRolePolicy` on the target role	Permissions-management action. Restrict to the intended target role ARNs.

AWS keeps no registry of issued role sessions, so a token cannot be recalled. The skill instead attaches an inline policy to the target role that denies every action under a DateLessThan condition on aws:TokenIssueTime — the same mechanism as the console’s Revoke active sessions. Repeated runs refresh the same inline policy rather than adding new ones.Revocation does not deactivate IAM user access keys. It cannot edit IAM Identity Center permission-set roles or revoke service-linked role sessions. Restrict iam:PutRolePolicy to the intended target roles because it permits inline policy changes.

Permission simulation is a diagnostic check. It does not guarantee that a live AWS request will succeed under every applicable policy and resource configuration.

General AWS Operations

Skill name	Purpose	IAM actions required	Scope and notes
General AWS Query	Execute a specified AWS service API method using Boto3.	Depends on the selected service, method, resources, and parameters.	Grant the actions required by the methods actually used, for example `ec2:DescribeInstances`, `iam:ListUsers`, or `s3:GetBucketPolicy`.

A single EC2 read-only policy cannot cover every supported use of General AWS Query. List the actions required by the methods your playbooks call, and grant exactly those.When it fans out across an AWS Organization, General AWS Query stops at the first account that returns an AWS error and reports that error — it does not skip the account and continue, unlike the other fan-out skills. Pass account_id to isolate a failing account.

To view the input parameters and output for each skill:

Go to the AirMDR → AWS integration page.
Select the Skills tab and click the skill you want.

IAM permissions reference

The per-skill actions are listed with each skill above. The tables below cover the extra permissions that apply only when a particular feature, encryption option, or data source is in use. AWS managed policies can provide broader access than a workflow requires; use these specific actions when defining a custom policy.

Use separate policies for investigation, Athena queries, and response actions so that each connection receives only the access required for its workflows.

Conditional permissions and dependencies

Add the following permissions only when the associated feature or operation is used.

Condition	Additional permissions or configuration
Filter List S3 Buckets by `bucket_region`	`s3:GetBucketLocation`
Read SSE-KMS encrypted S3 objects	`kms:Decrypt` on the relevant KMS key, with access permitted by the key policy.
Write into an SSE-KMS encrypted bucket with Put S3 Object	`kms:GenerateDataKey` and `kms:Decrypt` on the bucket’s key. The skill sends no encryption parameters of its own, so the bucket’s default encryption applies.
Run any skill against a member account of an AWS Organization	`sts:AssumeRole` on the member role ARNs, a matching trust policy on those roles, and the configured external ID.
Enumerate the accounts of an AWS Organization	`organizations:ListAccounts`, on the management-account role. Covered by `AWSOrganizationsReadOnlyAccess` in Option 3 Step 1.
Run General AWS Query against a service not listed above	The actions required by the exact `service_name` and `method_name` the playbook calls.

Put S3 Object and Delete S3 Objects expose no ACL, tagging, versioning, or multipart options — they take a bucket, object keys, and for uploads a body and content type. s3:PutObjectAcl, s3:PutObjectTagging, s3:DeleteObjectVersion and the multipart actions are therefore not required for those two skills. Athena’s result location is different — see the Athena table below.

Athena data-access dependencies

For standard Athena queries against Glue catalog tables backed by S3, configure the following access in addition to the three Athena actions listed with the skill.

Resource or operation	Permissions required
Source S3 bucket	`s3:ListBucket` and applicable bucket-location access, such as `s3:GetBucketLocation`.
Source S3 objects	`s3:GetObject` on the required data prefixes.
Glue database and table metadata	Applicable metadata-read actions, such as `glue:GetDatabase` and `glue:GetTable`. Include the relevant catalog, database, and table resources.
Partitioned Glue tables	Applicable partition-read actions, such as `glue:GetPartitions`, `glue:GetPartition`, and `glue:BatchGetPartition`.
S3 query-result bucket	`s3:GetBucketLocation`, `s3:ListBucket`, `s3:ListBucketMultipartUploads`.
S3 query-result objects	`s3:PutObject`, `s3:GetObject`, `s3:AbortMultipartUpload`, `s3:ListMultipartUploadParts` on the result prefix. Athena writes results there even for a `SELECT`, and uses multipart uploads for large result sets.
KMS-encrypted source data or results	Applicable KMS permissions on the relevant keys.
Lake Formation governed tables	Applicable Lake Formation data permissions and `lakeformation:GetDataAccess` where required.
Workgroup	The skill always runs in the `primary` workgroup. Scope the three `athena:` actions to that workgroup’s ARN if you restrict by resource. When `output_location` is omitted, results go to the workgroup’s configured result location, which must be set.

Athena queries require access to the underlying data and query-result location. Even a SELECT query writes results. Other SQL operations, federated queries, and different catalog configurations can require additional permissions.

Getting Started

AirMDR Detections

Integrations

API Reference

AirMDR Product Suite

Amazon Web Services

Overview

Setup at a glance

Set up the integration

Quick setup with the Use a Script tab

What the script creates

Widening the script’s policy

Enable AWS GuardDuty

Create IAM policy

Option 1: IAM User (Access Key Method)

Option 2: IAM Role (Assume Role via STS)

Option 3: Multi-Account Integration using AWS StackSet Method

How the access chain works

Step 1. Create the management account role

Step 1b. Add the inline policies

Step 1c. Record three values

Step 2. Deploy the member role by StackSet

The permission set

Step 3. Create the connection in AirMDR

Step 4. Verify

Account coverage

Configure AWS in the AirMDR Integrations Dashboard

Where to find the generated AWS Authentication Parameters in the Console (UI Steps)

Skills Provided by this Integration

IAM permissions reference

​Overview

​Setup at a glance

​Set up the integration

​Quick setup with the Use a Script tab

​What the script creates

​Widening the script’s policy

​Enable AWS GuardDuty

​Create IAM policy

​Option 1: IAM User (Access Key Method)

​Option 2: IAM Role (Assume Role via STS)

​Option 3: Multi-Account Integration using AWS StackSet Method

​How the access chain works

​Step 1. Create the management account role

Step 1b. Add the inline policies

Step 1c. Record three values

​Step 2. Deploy the member role by StackSet

​The permission set

​Step 3. Create the connection in AirMDR

​Step 4. Verify

​Account coverage

​Configure AWS in the AirMDR Integrations Dashboard

​Where to find the generated AWS Authentication Parameters in the Console (UI Steps)

​Skills Provided by this Integration

​IAM permissions reference

Overview

Setup at a glance

Set up the integration

Quick setup with the Use a Script tab

What the script creates

Widening the script’s policy

Enable AWS GuardDuty

Create IAM policy

Option 1: IAM User (Access Key Method)

Option 2: IAM Role (Assume Role via STS)

Option 3: Multi-Account Integration using AWS StackSet Method

How the access chain works

Step 1. Create the management account role

Step 2. Deploy the member role by StackSet

The permission set

Step 3. Create the connection in AirMDR

Step 4. Verify

Account coverage

Configure AWS in the AirMDR Integrations Dashboard

Where to find the generated AWS Authentication Parameters in the Console (UI Steps)

Skills Provided by this Integration

IAM permissions reference