3rd party access to your AWS account: machine or meatbag?
Something all AWS customers come across at some point, and it must be up there in the top ten of questions:
How do I securely provide access to my AWS account for a 3rd party?
Let’s make three hops across the surface of this question:
- Remember no-no’s and go-do’s
- The three options
- How to decide
Remember the no-no’s and go-do’s
Skip ahead if you’re a granny and already know how to suck these eggs:
- Never use root credentials or you’re on the naughty step.
- Are you using AWS Organizations? Better to give a 3rd party access to a linked account rather than a master/payer account.
- Be Scrooge-like in your granting of permissions and apply the practice of Least Privilege (Limited ReadOnly and never as much as AdminstratorAccess).
- Share the Scots’ optimism about summer and assume everyone is out to get you, especially the weather.
- Be like Marvin, the paranoid android.
The three options
There are three options to providing third parties access:
- If it’s a SaaS company, so it’s a machine and not a meatbag that is accessing your account, then use Roles and a Trust Policy instead of sharing keys. Key to this (get it?) is having the 3rd party generate a unique key that you using in your trust policy condition for External Id. It’s all here.
- If it’s a SaaS company that can’t do (1), then AWS and AWS Pros will pull a grumpy face because the 3rd party will ask you for IAM key access. This isn’t great because if anyone gets the keys then they can assume the access that your 3rd party has. It also means you need to handle regular key rotation.
- If it’s a meatbag and not a machine you need to give access to then it’s perfectly OK to create a user for an individual and allow them access. Maybe it’s easy for you because you federate identities with AD. You can do (1) if the meatbag can use the CLI:
How to decide
If the 3rd party is a SaaS machine, use (1) if you can. Mind, that this is still a trust relationship and trusting 3rd parties has risk in it. You should still use IAM for Least Privilege and monitor the access.
You’ll find (2) used with quite a few services out there, but the trend is away from it because of key management and Confused Deputy.
If 3rd party is a meatbag, use (3) for console, but if the meatbag is an AWS whiz who uses the CLI and other programmatic tools, then (1) is cool.
If it’s a meatbag, then there are a couple of challenges with using (1):
- You can’t use the console to switch roles if the Trust Policy has an External ID. Works with CLI though. If you drop the External ID from the Trust Policy, then the use can switch roles fine. But then you risk the Confused Deputy problem.
- You are trusting the 3rd party’s IAM: you can enforce MFA, that’s about it. AWS check partners like MSPs so that they adhere to best practice.
If you create a user for 3rd party then you can apply all your IAM practices to that one, specific person.
Another idea is for YOU to create a new linked account and give the 3rd party some limited IAM access to they create and manage their own user adds/deletes, but they have locked down policy access. This could work well if you have a 3rd party with lots of consultants. So you giving the 3rd party access to an account you own, which in turn has cross-account trust to other accounts you own.
With the new AWS Organizations you can additionally use Security Control Policies in addition to IAM to provide additional security. (Thanks to Chris Porter for reminding me about this!)
Quite a few options there, but the main difference is the answer to this question: Is the 3rd party a machine, or a meatbag? It pays to think like Bender to find the answer to this common AWS question :-)