Giving AWS Credentials to Third-Party Services | Skeddly

Skeddly Blog

Skeddly news and announcements...

Giving AWS Credentials to Third-Party Services

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.

Use Unique Credentials

Create a unique set of IAM credentials for each third-party vendor you want to work with. There are many benefits to this:

  • if the credentials are abused, you know the source of the abuse,
  • if you need to revoke the credentials, only the single third-party is affected,
  • you can fine-tune the permissions for each vendor with IAM policies.

AWS Root Account Credentials

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.

Third-Party IAM Roles

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 AWS account number of the vendor, and
  • an “External ID” that acts like a password.

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.

IAM User Access Keys

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:

  • they should be encrypted using strong encryption, and
  • they should never be exposed, even back to you.

As a best-practice, you should rotate Access Keys every 90 days. This means going to each IAM user, and:

  • creating a new set of Access Keys,
  • update any third-parties with the Access Keys, and
  • deleting the old Access Keys.

IAM Access Policies

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.

  • It should not be overly broad.
  • Never give admin-level access.
  • It should not permit more than you’re expecting it to permit. If you are expecting the third-party to only be creating snapshots, then the policy should not include commands to launch new EC2 instances.
  • It should use as few wildcards as possible. Wildcards are handy to reduce the size of a policy, but they can mask the commands that are being permitted. They may be OK for read-only commands like Get, Describe, or List. But they should never be used for actionable commands, like Modify, Create, or Launch.
  • Be cautious if the policy is permitting any IAM commands (they start with iam:).

Remember, this policy grants that third-party access to your AWS account.

Skeddly’s IAM Policy Generator

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

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.

Responsibility

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.