Audit the root user's protection from an admin identity, and store secrets properly

short · 30 min · Task statement 2.3

Before you start — what this lab needs, and what it can cost

This lab runs in your own AWS account, so treat every command as real. Work in AWS CloudShell, signed in as a non-root administrative identity: an IAM Identity Center user, or an IAM user with administrator permissions. Never use the root user for this lab. Everything here uses the AWS Free Tier where possible, but charges are possible, so finish the clean-up the same day; the AWS Pricing Calculator and each service's pricing page give current rates. It relies on the AWS Budgets alert you set in lesson 1's lab, which emails you if this account starts to cost money. The commands use 111122223333 as the account ID: put your own 12-digit account ID in its place every time it appears (CloudShell prints it with aws sts get-caller-identity --query Account --output text). The point of this lab is that the root user's protection can be checked from an ordinary administrative identity, so the lab itself never signs in as root. If your account belongs to an organisation in AWS Organizations whose management account manages root access centrally, the root user's readings may differ; the Notes explain how.

This lab ends with a clean-up. Do it the same day: anything left running in your account is billed to you.

Task

Check, without going near the root user, the two things that protect it most: whether it has MFA, and whether it has access keys. You read both from your administrative identity, set an IAM account password policy, and then store an invented database password in AWS Secrets Manager and an invented feature flag in AWS Systems Manager Parameter Store, so you can say which service suits which kind of value.

Steps

Read the account summary, which reports on the root user to any identity with IAM read permissions:

aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'
aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'

The healthy result is 1 for AccountMFAEnabled (the root user has MFA) and 0 for AccountAccessKeysPresent (the root user has no access keys). Write down what you see. Any other result is a finding, and the Notes say how it is fixed. 2. Read the root user's row of the IAM credential report:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > report.csv
head -1 report.csv | cut -d, -f1,5,8,9,14
grep '^<root_account>' report.csv | cut -d, -f1,5,8,9,14

If the report is not ready, run aws iam generate-credential-report again and wait a few seconds. The columns are the user, when its password was last used, whether MFA is active and whether each of two access keys is active. password_last_used tells you when the root user last signed in: in a well-run account that date is rare and every use of it is explainable. 3. Check whether an account password policy already exists:

aws iam get-account-password-policy

If this prints a policy, your account already has one: keep it, skip step 5 and skip the password policy step of the clean-up. If it returns an error naming NoSuchEntity, carry on. 4. Before you change anything, note the setting that the policy will govern: console passwords for IAM users. It does not apply to the root user, to access keys or to IAM Identity Center users, whose rules come from Identity Center's own identity source. Count the IAM users it would cover:

aws iam list-users --query 'length(Users)'

Set a password policy for IAM users:

aws iam update-account-password-policy --minimum-password-length 14 --require-symbols --require-numbers --require-uppercase-characters --require-lowercase-characters --password-reuse-prevention 5

From now on, any IAM user who sets a console password must meet these rules. 6. Store a configuration value in Parameter Store, in a hierarchy of names, and read the hierarchy back:

aws ssm put-parameter --name /clf-lab10/app/feature-flag --type String --value on
aws ssm get-parameters-by-path --path /clf-lab10 --recursive --query 'Parameters[].[Name,Value]' --output text

Store an invented database credential in Secrets Manager, then fetch it the way an application would at run time:

aws secretsmanager create-secret --name clf-lab10-app-db --secret-string '{"username": "clf-lab10-app", "password": "invented-sample-only"}' 
aws secretsmanager get-secret-value --secret-id clf-lab10-app-db --query SecretString --output text

The secret is encrypted with an AWS KMS key and reached through IAM permissions, so it never needs to sit in source code. Secrets Manager can also rotate a credential automatically on a schedule, which Parameter Store cannot; that is the word the exam uses to separate them.

Verify

aws iam get-account-password-policy --query 'PasswordPolicy.MinimumPasswordLength'

Expected output: 14 (or your existing policy's length, if step 3 found one).

aws ssm get-parameter --name /clf-lab10/app/feature-flag --query Parameter.Value --output text

Expected output: on.

aws secretsmanager describe-secret --secret-id clf-lab10-app-db --query Name --output text

Expected output: clf-lab10-app-db.

aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'

Expected output: 0. Anything else means the root user has an access key, a finding to fix as the Notes describe.

Cost and clean-up

IAM and standard Parameter Store parameters are offered at no additional charge. A Secrets Manager secret may be charged for the time it exists and for API calls, so the clean-up deletes it at once rather than after a recovery window.

Created by this lab: the account password policy (only if step 3 found none); the parameter /clf-lab10/app/feature-flag; the secret clf-lab10-app-db; the CloudShell file report.csv.

Delete the secret immediately, with no recovery window:

aws secretsmanager delete-secret --secret-id clf-lab10-app-db --force-delete-without-recovery

Delete the parameter:

aws ssm delete-parameter --name /clf-lab10/app/feature-flag

Only if step 3 found no password policy, remove the account password policy you set in step 5. If your account had one before the lab, leave it alone:

aws iam delete-account-password-policy

Remove the credential report from CloudShell:

rm report.csv

Check it is gone

aws secretsmanager list-secrets --include-planned-deletion --filters Key=name,Values=clf-lab10 --query 'length(SecretList)'
aws ssm get-parameters-by-path --path /clf-lab10 --recursive --query 'length(Parameters)'

Expected output: 0 from both commands. A forced delete can take a minute to finish; if the first command prints 1, wait and run it again.

aws iam get-account-password-policy

Expected output: an error naming NoSuchEntity if you deleted the policy you set, or your original policy, unchanged, if step 3 found one.

Notes

If step 1 shows AccountMFAEnabled as 0, or AccountAccessKeysPresent as 1, the fix is one of the few tasks that genuinely need the root user: sign in as root once, outside this lab, turn on MFA (or delete the root access key), sign out, and go back to your administrative identity. Protect the root email inbox too, because a password reset goes there. In an organisation whose management account has turned on centralised root access, member accounts may have no root credentials at all, and the readings then show no MFA because there is no root password to protect. Secrets Manager encrypts the secret with the AWS managed key aws/secretsmanager, which AWS creates in the account on first use and manages itself; it is not a resource this lab asks you to delete.

This is an independent study companion for the AWS Certified Cloud Practitioner (CLF-C02) exam and is not produced by or endorsed by Amazon Web Services. AWS, Amazon Web Services and AWS Certified Cloud Practitioner are trademarks of Amazon.com, Inc. or its affiliates.

This is an independent study companion for AWS Certified Cloud Practitioner CLF-C02 and is not produced by or endorsed by CompTIA.