Is it safe to give an outside DevOps provider access to your AWS account?

Why do founders worry about giving a provider AWS access?

Founders worry because the AWS account holds customer data, the bill and the ability to delete everything, so letting outsiders in feels like handing over the keys.

The worry is reasonable, and the answer is to control how access is given, not to avoid help altogether.

Under the AWS shared responsibility model you stay responsible for security in the cloud however the work is split. That is a reason to be precise about access, not a reason to do all the work alone.

How should a third party be given access to your AWS account?

A third party should be given access through an IAM role in your account, not by sharing a password or long-lived access keys.

AWS says that with IAM roles you can grant third parties access to your resources without sharing your AWS security credentials.

The role has a permission policy that defines what the provider can do and which resources it can reach. AWS gives examples of scoping a role to manage only certain services, or to read-only access across the account, and notes that anything the provider uses is billed to you, so limit it appropriately.

What is an external ID and why does it matter?

An external ID is a value in the role's trust policy that stops a provider's access being misused by someone else, a risk AWS calls the confused deputy problem.

AWS says the primary function of the external ID is to prevent that problem, and that the role can then be assumed only under specific circumstances.

• The external ID is not a secret; AWS says anyone who can view the role can see it.
• Each customer of a provider should get a unique external ID, generated by the provider.
• It supports a good setup but does not replace limiting what the role can do.

What access should a provider start with?

A provider should start with read-only access, so it can look at your setup, review costs and check backups without being able to change anything.

Changes can then be made through a route you control, such as your own deployment pipeline.

How can you see what a provider has done in your account?

You can see what a provider has done through AWS CloudTrail, which records actions taken by a user, role or AWS service, including who took which action and when.

CloudTrail's event history gives a searchable, immutable record of the past 90 days of management events in a Region, and AWS makes it available automatically.

For longer retention you need a trail that stores events in S3, so set that up before you need it. Changes made through a pipeline also leave a Git history you can trace, which is a second record. An AWS infrastructure audit for a small SaaS covers checking that logging is on.

What should you ask a DevOps provider about access before signing?

Ask what access they need, how it is granted, what they can change on their own and what happens to it when you leave.

A confident provider will answer in specifics and put it in writing.

• Is access a role in my own account, and is it read-only by default?
• Do changes go through my pipeline as reviewed pull requests?
• Which actions need my written OK?
• Can I see every action in CloudTrail and in Git?
• What do you hand back, and how is access removed when I leave?

How much a startup should pay for DevOps each month covers the other questions to ask before buying.

How does Keel handle access to a startup's AWS account?

Keel uses a read-only AWS role by default, makes changes only through your own pipeline as reviewed pull requests, and does deletions, access changes and DNS changes by people only, with your written OK.

Everything runs in your own AWS account, so there is nothing to hand back if you leave.

Keel's Startup programme is a foundation-level service for small teams already live with paying customers: a deploy pipeline with rollback, tested backups, monitoring and monthly patching, with a monthly check-in with your account manager. It is for teams of fewer than 5 at pre-seed to Series A, on AWS with code on GitHub or GitLab, and places are awarded on merit. You can apply for a place in the pricing section.

Is your provider access set up safely?

Tick each item that is true today.