My company uses AWS for compute, storage, databases and more. However, they use the root key for access to everything and I'm trying to move away from that for security purposes. Any leak could result in catastrphic data leaks, or crippling bills from AWS. I'd like to prevent that as much as possible by permissioning keys (I know how to do that) and having keys auto expire after x weeks.

I've done a bit of exploration and haven't found something perfect. the closest I've found is the following. (We use Azure to authorize users to AWS) it's a tool that allows the aws cli access to aws by authorizing through azure: https://github.com/dtjohnson/aws-azure-login

The above gives us a daily authorization through the cli to access certain parts of AWS. However, that isn't exactly what we want. Management prefers longer expiry periods for convenience and we need actual keys to be able to use a tool like Cyberduck and to spin up instances in AWS, etc.

Is it possible to create keys by user that expire every X weeks and require a new request for a key?

  • 1
    Hey Joe, rather than proposing a solution and asking if it works, you'd probably be better off telling us your environment, telling us the problem, and asking for suggestions. You question doesn't clearly describe a problem or what you're trying to achieve, so I don't think you're going to get much useful feedback. Edit your question and you'll probably get more useful help :) – Tim Sep 5 '19 at 19:13
  • 1
    @Tim I added some context. Hope it makes sense. Lmk if I should add more – Joe B Sep 5 '19 at 19:49
  • 2
    When you say "root key" do you mean everyone logs in as the root user? Are you talking about KMS? It's still not clear what problem you're trying to solve. If you're using the root user at all that's really poor practice even with MFA. Federate with your central directory or set up IAM users and IAM groups with MFA mandatory, with IAM policies that limit what each user can do and that require MFA. You can also use SCP to prevent the use of services you don't need, which further reduces the risk of bill shock. We use SCP to limit regions as well. AWS Config is useful for monitoring. – Tim Sep 5 '19 at 20:07
  • @Tim yes they are using the root user. They've been doing it for years and I just got here recently. In the process of making changes. – Joe B Sep 5 '19 at 20:12

Root User

The root user should have MFA enabled, then have it locked away and never used. Never create access keys for the root user.

IAM Administrator

Create an IAM administrator user with MFA required that has full rights, including billing.

IAM Policy and Groups

Next create an IAM policy that gives users access to the services and functions they're allowed to use. The policy should mandate MFA has been used for all functions, other than being allowed into IAM to set up MFA. Attach this policy to a group. You can create as many policies and groups as you need. You can further lock things down with Service Control Policies if you see any benefit. You can do things like region enforcement and preventing use of expensive resources (e.g. GPU instances or RedShift / RDS) in either IAM or SCP.

Federation or IAM Users

Now either federate your account(s) to on-premise active directory, or create IAM users and add them to a group. Don't add policies to the users directly. These users can have access keys, but these are subject to MFA as well.

Federation links: one, two. The key search term is "AWS Active Directory Federation".

Two Weeks

I suspect the two week request is a red herring. Once you set all your users up properly you don't need to change your access keys that often - every few months is likely sufficient, or maybe up to a year.


All of this gives you good control of your account, lets you trace who did what (make sure Cloud Trail is enabled and the bucket is protected), reduces exposure to hackers increasing the bill, and probably other benefits too.

  • Can you explain the concept of federation? I've read a bit but I'm not sure I understand entirely what happening on the backend. – Joe B Sep 6 '19 at 18:37
  • Basically AWS talks to your on-premise Active Directory / ADFS server using SAML to establish trust. That AD user who is trusted gets to assume a role that gives them permission in the account. I'll add a couple of links to my answer. – Tim Sep 6 '19 at 19:00
  • Note that there is at least one AWS operation that can only be done by the root user, which is setting RDNS for Elastic IPs. If you need that, you have no choice but to use the root login for it. – Moshe Katz Sep 12 '19 at 19:16
  • @MosheKatz perhaps you could link to some information about RDNS and it's relation to elastic IPs. You seem to have linked to the console to apply for a change. I didn't know that could only be done by the root user, I wonder if a user with the correct rights can also do it. – Tim Sep 12 '19 at 20:18
  • @Tim You need Reverse DNS configured properly for most email providers to accept mail from your server. Here is the AWS blog post introducing the feature. – Moshe Katz Sep 12 '19 at 20:38

DO NOT use an access key for your AWS account root user. Use IAM users for everyday interaction with AWS. Now that is out of the way...

Use Temporary Security Credentials

You can create IAM roles rather than users and generate temporary security credentials. These have an access key ID, a secret access key, and a security token that indicates when the credentials expire.

Normally access keys remain valid until you manually revoke them. However, temporary security credentials obtained through IAM roles and other features of the AWS Security Token Service expire after a short period of time.

In your example talking about Instances or CLI scripts rather than passing or embedding an access key to the application, define an IAM role that has appropriate permissions for your application and launch the Amazon EC2 instance with roles for EC2. This associates an IAM role with the Amazon EC2 instance and lets the application get temporary security credentials that it can in turn use to make calls. The CLI can get temporary credentials from the role automatically.

  • My understanding, which may not be correct, is that you need to have a principle that can assume a role. That can be an on-premise federated user, an IAM user, etc. Can you edit your post to give a bit more detail? – Tim Sep 6 '19 at 0:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.