Connect your AWS accounts to Aikido
Aikido can scan your AWS accounts for misconfigurations: public buckets, security groups open to the world, unencrypted resources, risky IAM policies and more. To do that, Aikido’s scanner signs in to each account through an IAM role that trusts Aikido’s AWS account. We create that role for you, in the same infrastructure code as the rest of your platform. The connection starts in your Aikido workspace: you start it, or we do when you’ve given us access through Aikido’s partner program.
This page explains what the role lets Aikido see, which options you can turn on, and how to connect an account. Read Before you connect anything first.
What Aikido can see
By default, the role reads the configuration of your AWS resources, not their content. It combines AWS’s SecurityAudit policy with the few extra read permissions Aikido asks for, minus the ones that return content.
Aikido can see, for example:
- which resources exist and how they’re configured: buckets and their policies, security groups, load balancers, databases, clusters, IAM users, roles and policies;
- the configuration of Lambda functions and ECS task definitions, including their environment variables.
Aikido can’t see:
- the data in your resources: objects in S3 buckets, items in DynamoDB tables, log events, and the values of secrets and parameters in Secrets Manager and Parameter Store;
- by default: the code of your Lambda functions, the user data of your EC2 instances and launch templates, and the bodies of your CloudFormation templates. See Optional: content reads.
The role can’t change your resources. Aikido’s scanner can only use it when it presents your Aikido workspace’s external ID, so another Aikido customer can’t use it to read your account.
Important
A password or API key written directly in a Lambda or ECS environment variable ends up in Aikido. Keep credentials in Secrets Manager or Parameter Store and let your application read them from there.
Connect an account
We connect accounts one at a time. Aikido also offers to connect a whole AWS Organization in one go, but it does that with a CloudFormation StackSet that installs a template hosted by Aikido into every account, outside your infrastructure code. Connecting account by account keeps the role in your infrastructure code, where every change to it gets reviewed.
1. Start the connection in Aikido
In your Aikido workspace, add an AWS cloud and choose to connect a single account. The wizard shows an external ID (it looks like aikido-12345). Copy it. You don’t need to run the CloudFormation stack or the Terraform code the wizard offers; we create the role for you.
Warning
Turn off Aikido’s Automated PRs before you continue, as Before you connect anything explains. Connecting an account can make Aikido open pull requests in your repositories on its own.
2. Ask us for the role
Open a support request with:
- the external ID;
- which AWS accounts you want to connect;
- whether you want any of the optional scans; they’re off unless you ask.
The external ID isn’t a secret, so you can paste it in the request. It is the same for every account you connect to the same Aikido workspace.
3. Finish the connection in Aikido
We send you the ARN of the role in each account. Paste it into the Aikido wizard, give the account a name and set its purpose (production, development, …). Aikido uses the purpose to prioritise findings: a finding in a development account scores lower than the same finding in production. The first results show up within minutes.
Optional scans
Our setup differs from the one Aikido’s wizard offers. Aikido’s standard role can also read the content of some resources, and the wizard offers ECR and EBS scanning next to it. We can set up each of these for you, but they stay off until you ask for them, account by account.
Why: each of them gives Aikido more than your configuration. Content reads reach the places where credentials tend to end up, ECR scanning copies your images to Aikido, and EBS scanning copies your disks. Whether that’s worth it depends on the account and its data, so it’s your decision, made per account and knowing what Aikido gets.
Optional: content reads
Some of Aikido’s checks need to read content: they look for secrets inside Lambda code, EC2 user data or CloudFormation templates. Those places are exactly where credentials end up, so by default the role can’t read them and those checks don’t run.
If you want those checks, ask us to grant Aikido’s full set of permissions for an account. Aikido can then download your Lambda code and read your instance and launch template user data and your CloudFormation templates. Turn it on only for accounts where you accept that Aikido sees that content.
We tried it on our own test account, which runs our standard platform setup: Aikido read our launch templates’ user data and found nothing it hadn’t already reported without it. It is most useful for accounts where you run Lambda functions or write your own user data or CloudFormation templates.
Optional: container images in ECR
Aikido can also scan the images in an account’s ECR registries for known vulnerabilities. This adds a second role, which lets Aikido’s image scanner pull every image in the account’s ECR and scan it on Aikido’s side, so your images leave your account.
You might not need it:
- If your workloads run on a Kubernetes cluster we manage, the cluster’s image scanner already scans the images you run, including those in ECR. It only sends Aikido the list of packages in each image, not the image itself.
- Repositories of our ECR pull-through cache hold copies of public images. Scanning every copy reports the same upstream vulnerabilities many times over.
Optional: EBS volume scanning
Aikido can also scan EC2 volumes, by snapshotting them and reading the snapshots. That gives Aikido a copy of everything on your disks, including any data your applications store there. Ask us if you need it, and we’ll look at it with you.
Disconnect an account
Ask us to remove the role. Then remove the account from your Aikido workspace.