How to Create a Read-Only IAM Role for Safe AWS Scanning

Any tool that scans your AWS account — for codification, security review, cost analysis, or inventory — needs access. The single most important decision you make is how much. The right answer is almost always "read-only, scoped, and revocable." This guide shows you how to set that up correctly, including the two details teams most often get wrong: using a role instead of keys, and protecting it with an external ID.

• Why read-only matters
• The managed policies that help
• Roles beat access keys
• Creating the role, step by step
• The external ID
• Verify and revoke
• FAQ

Why read-only matters

Read access lets a tool see your infrastructure. Write access lets it change your infrastructure. For scanning, codifying, or auditing, you only need the first — so granting the second is pure downside.

A tool that can run terraform apply can also run terraform destroy. If a tool only needs to read, write access is risk with no benefit.

Read-only access dramatically shrinks your blast radius: a compromise of the tool, a bug in its code, or a rogue action simply cannot mutate your account. It also makes audits and incident reviews shorter — "the scanner is physically incapable of writing" is a complete answer. This is the principle behind tools that are read-only by design, and it's why InfraSync never holds credentials that can write to your account.

The managed policies that help

AWS ships several managed policies you can attach instead of writing JSON by hand:

• ReadOnlyAccess — broad read (Get*, List*, Describe*) across services. The usual choice for full-account codification and inventory.
• SecurityAudit — read access to configuration and metadata for security review, without reading data contents. Narrower than ReadOnlyAccess.
• ViewOnlyAccess — list-and-describe-style visibility, more limited still.

For least privilege, start as narrow as the job allows. If a tool documents the exact actions it needs, a custom policy scoped to those actions beats any broad managed policy.

Roles beat access keys

You can grant access two ways: hand over long-lived IAM user access keys, or let the tool assume a cross-account IAM role. Prefer the role:

• Temporary credentials. Assuming a role yields short-lived tokens that rotate automatically — nothing long-lived to leak.
• Instant revocation. Delete the role (or the trust) and access ends immediately, account-wide.
• No secrets to store. You never paste a permanent secret into a third-party form.

Creating the role, step by step

1. In the AWS console, open IAM → Roles → Create role.
2. Choose "AWS account" → "Another AWS account" and enter the vendor's AWS account ID (the tool provides this).
3. Tick "Require external ID" and paste the unique external ID the tool gives you (see below).
4. Attach a read-only policy — typically ReadOnlyAccess, or a narrower custom policy.
5. Name the role clearly (e.g. infrasync-readonly) and create it.
6. Copy the role ARN back into the tool.

The resulting trust policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::<VENDOR_ACCOUNT_ID>:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "<YOUR_UNIQUE_EXTERNAL_ID>" }
    }
  }]
}

The external ID

The external ID is a small detail that closes a real security hole called the confused-deputy problem. Without it, if a vendor assumes customer roles on a known ARN pattern, one customer could potentially trick the vendor into assuming another customer's role. The external ID is a shared secret that must match for the assume-role call to succeed, so the vendor can only assume your role when it presents your external ID.

Always require an external ID for third-party cross-account roles. A reputable tool will generate a unique one for you automatically.

Verify and revoke

After connecting, confirm the access behaves as expected and keep control in your hands:

• Confirm read-only. Review the attached policy — there should be no Create*, Put*, Update*, Delete*, or *:* actions.
• Check CloudTrail. The assume-role events and the API calls the tool makes are all logged; you can see exactly what it read.
• Rotate or revoke anytime. Delete the role to cut access instantly. With a role, there are no stray keys to hunt down afterward.

This is exactly the model InfraSync uses: you create the read-only role, InfraSync assumes it with your external ID to scan, and you can revoke it whenever you like. See our AWS-to-Terraform guide for what happens after the scan, and the security statement for how credentials are handled.

FAQ

What's the difference between ReadOnlyAccess and SecurityAudit?

ReadOnlyAccess grants read (Get, List, Describe) permissions across services, including reading some data. SecurityAudit grants permission to read configuration and metadata for security review but not data contents. For codifying infrastructure, ReadOnlyAccess or a scoped subset is typical; for pure config review, SecurityAudit is narrower.

Why use an IAM role instead of access keys?

A cross-account IAM role uses short-lived, automatically rotated temporary credentials and can be revoked instantly by deleting the role. Long-lived access keys must be stored, rotated manually, and are a bigger liability if leaked. Roles are the AWS-recommended way to grant a third party access.

What is an external ID and why does it matter?

An external ID is a shared secret added to a cross-account role's trust policy. It prevents the confused-deputy problem, where another customer of the same vendor could otherwise trick the vendor into assuming your role. The vendor supplies a unique external ID that must match for the role to be assumed.