Often, there comes a day when you’ve come across a killer SaaS or product that will work with your AWS account. It could be an automation tool (like Skeddly, a cost monitoring tool, a security tool, or any one of the many other products designed to work with your AWS account. Whatever the case, in order to read or modify information in your AWS account, you must provide credentials with which it will use to access your AWS account.
As a third-party vendor, we want you to be as safe with your AWS account as possible. So we’ve compiled some tips and best-practices to put in place when working with third-parties that are going to access your AWS account.
Create a unique set of IAM credentials for each third-party vendor you want to work with. There are many benefits to this:
Never, never, ever, ever give root credentials for your AWS account to a third-party. You should never, never, ever, ever even use them yourself.
If your AWS account has Access Keys for the root, delete them right now. Instead, create an IAM user for yourself to use.
Whenever possible, you should create Third-Party IAM Roles to give to third-parties. Third-Party IAM Roles are more secure than Access Keys are. With Third-Party IAM Roles, a trust relationship is established between your AWS account and the vendor’s AWS account.
When creating a Third-Party IAM Role, the role builds a trust relationship that is embedded with two pieces of information:
The external ID should be unique for each IAM role registered. It should also be generated for you by the vendor. If a vendor lets you supply your own External ID, don’t do it. They have a big security hole.
AWS ensures that the IAM role can only be assumed from the AWS account listed in the trust relationship. If any other AWS account attempts to assume the role, AWS will prevent it. In the unlikely event that the role information were leaked, someone else would not be able to use the IAM role.
Access Keys are another way to access an AWS account. They are less secure than IAM roles because there isn’t any built-in security mechanism to protect them. They can be used by anyone who gets access to them.
Access Keys should only be used when Third-Party IAM Roles cannot. And when giving Access Keys to third-parties, you should be satisfied with the security that will be used to protect them:
As a best-practice, you should rotate Access Keys every 90 days. This means going to each IAM user, and:
IAM Access Policies are a JSON document that describes what can and/or cannot be done with the IAM Role or Access Keys. By default, fresh AWS credentials cannot do anything. Your policy document must “opt-in” the commands that are granting the third-party permission to execute.
Here is a sample policy that allows a third-party to start and stop EC2 instances:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
}
]
}Everything not explicitly listed in this policy is denied. Wildcards * can be used in the Action and Resource fields.
It’s used in the Resource field in this policy. You can use it like ec2:Describe* to allow all EC2 operations that start
with Describe.
When you give your AWS credentials to a third-party, they will need to tell you an IAM policy to apply to your AWS credentials. Review this policy very carefully.
Get, Describe, or List. But they should
never be used for actionable commands, like Modify, Create, or Launch.iam:).Remember, this policy grants that third-party access to your AWS account.
Skeddly includes an IAM Policy Generator, the first of it’s kind outside of AWS’s own tool. After you have created and configured your Skeddly actions, you can use Skeddy’s IAM Policy Generator to generate an IAM policy document customized to your actions.
For example, if you have instructed Skeddly to start and stop your EC2 instances, it will generate a policy that only
includes the ec2:StartInstances, ec2:StopInstances, and ec2:DescribeInstances commands. Skeddly doesn’t need anything
more than these commands, so the policy won’t include more.
And while it may be a few more steps to complete after you add or change your actions, it’s far more secure than us providing you a blanket IAM policy trying to cover everything that Skeddly could possibly need. That would be a lot, because Skeddly can do a lot.
Amazon CloudTrail is a security tool built into AWS that tracks everything that happens in your AWS account. You should enable it in every region in your AWS account. Once enabled, it logs every API operation to an Amazon S3 bucket. You can review the history of your AWS account by viewing the logs. You can even filter the logs based on specific AWS resources, such as EC2 instances or EBS snapshots.
For example, if you wanted to know whom started or stopped an EC2 instance, you can search for it’s EC2 instance ID within CloudTrail. It would give you the IAM user or Role that performed the operation.
Remember, you are responsible for your AWS account. Make sure you trust whom you’re letting in.
If your third-party vendor does not support these best-practices, call them on it, ask them why not, demand they do, or don’t use them.