AWS Centralised Root Access Management : Simplifying Operations

I’m sure many of us came across managing Root credentials for multiple account and setting up password for those accounts, setting MFA for those accounts. It is one of the manual process that I don’t find efficient and also sometimes can leads human error. And if we don't set up root credentials, we have critical finding in SecurityHub then ;)

Also, previously each AWS account was provisioned with root user credentials that granted unrestricted access which kind of contradictory to AWS principle "Least Privilege Access." ;)

But Recently AWS launched new capability in IAM where you can centrally manage root access for member accounts in AWS Organizations which I find really nice one. Even for root now, you can have short-term credentials and limited access. Let's explore this feature.

Key Features:

• Newly created accounts in AWS Organizations come without root credentials by default, ensuring member accounts cannot sign in as the root user or recover passwords for it. So these are accounts are secure by default like no one can login with root until and unless org admin enables it.
• After centralising root access, you can opt to delete root credentials from member accounts. This includes removing the root user password, access keys, signing certificates, and deactivating or deleting multi-factor authentication (MFA).
• Centralised monitoring of root credential status across all member accounts aids in demonstrating compliance with security policies and regulatory requirements.

And one good thing is, the new capability does not provide full root access but allows temporary credentials for five specific actions:

1. Re-enabling Account Recovery: Reactivating account recovery without root credentials.
2. Auditing Root User Credentials: Read-only access to review root user information.
3. Deleting Root User Credentials: Removing console passwords, access keys, signing certificates, and MFA devices.
4. Unlocking an S3 Bucket Policy: Editing or deleting an S3 bucket policy that denies all principals.
5. Unlocking an SQS Queue Policy: Editing or deleting an Amazon SQS resource policy that denies all principals.

Let's get hands-on on this.

Prerequisites

• Your AWS accounts must be managed under AWS Organizations.
• Enable trusted access for AWS Identity and Access Management (IAM) in AWS Organizations.
• The following permissions are necessary:
  • iam:EnableOrganizationsRootCredentialsManagement
  • iam:EnableOrganizationsRootSessions
  • organizations:RegisterDelegatedAdministrator
  • organizations:EnableAwsServiceAccess

Hands-On

Enabling Centralised Root Access

• In the AWS Management Console, navigate to the IAM section, select "Root access management" from left pane and enable the desired features. In this demo, I have enabled all features where I can delete S3, SQS policy and root password recovery.
• Additionally, if you want delegated admin for this type of activity, assign a dedicated member account as the delegated administrator for IAM to manage root access and perform privileged tasks, ensuring separation of duties and enhanced security.

Now you can either manage these root credential from delegated admin or management i.e Organizations account account.

Once enabled, you will get below view type. We can see in screenshot, for one account root user credentials are present and for other credentials are not present.

New Account Creation

Here I have created new account named - cloudgyan45-dataplatform and by default there are not credentials. Even if you try Forgot password wizard which we normally do for Root user, you will not able to reset password. I have tried and get below message:

• Forgot password output : Got an email for password Reset:

• But if I click on link, we get output :

Existing Account

Even for existing account, you will be able to delete root credentials and you don't need to manage root password anymore in your password storage or file ;)

Select existing account, on top right corner, click on Take privileged action

Once you delete root credential, you don't need worry about root logins as no one can logged in with root now. But make sure you haven't configured root credential or keys in your application. :)

Taking Privileged action

Now, let's try out last part, taking privileged action. Imagine scenario where by mistake someone put S3 bucket bucket policy as Deny to all or Deny to admin roles as well. Normally, in this case, we logged via root and we delete policy. Consider below kind of policy :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<bucket-name>",
        "arn:aws:s3:::<bucket-name>/*"
      ]
    }
  ]
}

I tried applying below policy to one of the bucket I have.

> Please note that I have created bucket for demo purpose. Don't try this on your production or any other major workload.

• Apply S3 bucket policy:
  

• Access is blocked to bucket
  

• Now, take privileged action - delete bucket policy in this case by login into management account or delegated admin for root access management.
  

• After deletion, we can access bucket again and also policy got deleted.

Things to consider while implementing feature

• Make sure access to organisation or delegated admin account is very well protected.
• Monitor CloudTrail events : AssumeRoot . This API operation generated someone try to take any action via root access management.

Centralising root access management in AWS Organisations is a powerful feature that simplifies administration and reduces security risks. Properly applied, this feature can significantly enhance your organisation’s security posture and operational efficiency.

Thank you reading this blog, appreciate your time !!

Comments

[Jatin Mehrotra]

Thank you for writing this. I was about to implement this for my organization this will surely help me.

I will book mark this.