Why 'connect your AWS account' feels risky
Any SaaS tool that asks you to connect your AWS account is asking for a level of trust that is different from a normal software integration. AWS accounts run production infrastructure, hold billing data, and in the wrong hands can be used to spin up expensive resources or access sensitive data. The instinct to be cautious here is correct.
The good news is that AWS gives you a mechanism to grant exactly the access a tool needs and nothing more, verify what that access actually permits before you grant it, and revoke it at any time without depending on the tool's cooperation. That mechanism is a cross-account IAM Role with a read-only policy.
Access keys vs IAM roles: know the difference
There are two ways a third party could access your AWS account: long-lived access keys (an access key ID and secret key you generate and hand over), or a cross-account IAM Role that the third party assumes temporarily using AWS's own STS service. These are not equivalent in risk.
Access keys, once shared, exist outside your control. If the receiving company mishandles them, logs them, or gets breached, the keys still work until you manually rotate them — and you have no visibility into how the vendor is storing them internally. An IAM Role is different: no long-lived secret ever leaves your account. The vendor's system calls AssumeRole, AWS issues a short-lived temporary credential, and that credential expires automatically. You never generate or hand over anything a leak could compromise long-term.
If a tool asks you for an access key ID and secret key instead of walking you through creating an IAM Role, that is worth questioning.
What a read-only policy actually restricts
IAM policies are made of Actions (what API calls are allowed), Resources (which specific things they apply to), and Effect (Allow or Deny). A read-only monitoring policy should only include Describe/List/Get-type actions — the read-side of the AWS API — and should never include Create, Put, Delete, Modify, Attach, Terminate, or similar write actions.
Here is what a minimal read-only policy for infrastructure monitoring looks like in practice:
- ✓ec2:DescribeInstances, ec2:DescribeVolumes, ec2:DescribeAddresses — read EC2/EBS/EIP state, no write actions included
- ✓rds:DescribeDBInstances — read RDS instance state only
- ✓elasticloadbalancing:DescribeLoadBalancers, elasticloadbalancing:DescribeTargetHealth — read load balancer and target health, cannot modify listeners or targets
- ✓ce:GetCostAndUsage, pricing:GetProducts — read billing and pricing data, cannot change budgets or billing settings
- ✓sts:GetCallerIdentity — used only to verify the role was assumed correctly during setup
None of these actions can create, modify, or delete anything. A policy built entirely from Describe/List/Get actions physically cannot be used to spin up resources, change configuration, or delete data, regardless of what the vendor's software does with the access.
Setting up the role: the External ID matters
When you create the cross-account role, AWS lets you require an External ID — a shared secret string that must be included in every AssumeRole call for it to succeed. This exists specifically to prevent the 'confused deputy' problem, where a malicious third party tricks a legitimate service into assuming a role it should not have access to.
- 1In the IAM console, go to Roles → Create role → select 'Another AWS account' as the trusted entity
- 2Enter the vendor's AWS account ID as the trusted account
- 3Check 'Require external ID' and enter the unique value the vendor's dashboard gives you — this should be specific to your account, not a shared constant
- 4Attach an inline policy containing only the Describe/List/Get actions the vendor documents needing — nothing more
- 5Skip permissions boundaries and additional managed policies unless you have a specific reason to add them
If a vendor's setup flow does not ask you to set an External ID, or reuses the same External ID for every customer, that is a weaker setup than it should be.
How to actually verify the policy before you paste it in
Do not just trust that a vendor's 'read-only' claim matches what the policy JSON says. Read the policy document yourself before creating the role. Look specifically for whether every Action starts with Describe, List, or Get — anything starting with Create, Put, Delete, Modify, Terminate, or Attach means the tool has more access than 'read-only' implies.
If the vendor publishes the policy in a public repository, that is a meaningfully stronger trust signal than a policy generated dynamically inside their dashboard that you cannot diff against a known-good version. A policy you can read on GitHub before you ever log into the product is a policy you can hold the vendor accountable to if it ever changes without notice.
Revoking access when you are done
Because the access is granted through an IAM Role you own, you are always the one in control of revocation — it does not depend on the vendor deleting anything on their side. Deleting the IAM Role from your AWS account immediately and permanently ends the vendor's ability to assume it, regardless of whether their system still has the Role ARN stored somewhere.
This is a meaningful difference from handing over access keys, where revocation means trusting the vendor to delete or ignore keys that, technically, still exist and still work until you rotate them on your end too.
How Driftak applies this
Driftak uses exactly this model: you create a read-only IAM Role with a required External ID unique to your account, attach a policy limited to Describe/List/Get actions across EC2, RDS, Elastic Load Balancing, Cost Explorer, and the Pricing API, and paste in the Role ARN. Driftak never asks for access keys and never stores AWS credentials — each scan assumes the role fresh through STS. The IAM policy is published on GitHub so you can read it before you create anything in your account, and disconnecting from your dashboard immediately stops all future scans.
The point of walking through this yourself is not to distrust every vendor — it is that you should not have to take 'we're read-only' on faith when AWS gives you the tools to verify it in about five minutes.