Secrets and least privilege
Removing hardcoded credentials, choosing Secrets Manager or Parameter Store, and trimming IAM permissions in an existing system with Access Analyzer, boundaries and Roles Anywhere.
Exam tasks: 3.2 (determine a strategy to improve security: secrets and credentials management, least privilege, traceability)
The decision: where does a credential live today, and what's the smallest change that moves it somewhere rotated and audited? Then: which permissions does each principal actually use, and how do you cut the rest safely?
Where should the credential go?
Secrets Manager vs Parameter Store
| Secrets Manager | Parameter Store (SecureString) | |
|---|---|---|
| Built for | Credentials with a lifecycle | Configuration, including some encrypted values |
| Rotation | Built in. Managed rotation for RDS, Aurora, Redshift and DocumentDB; Lambda rotation for anything else | None. Build it yourself |
| Encryption | Always KMS encrypted | SecureString uses KMS. String and StringList are plain |
| Cross-account access | Resource policy on the secret, plus a customer managed KMS key the other account can use | Advanced parameters can be shared with AWS RAM |
| Multi-Region | Replica secrets in other Regions, kept in sync | No replication |
| Size | Up to 64 KB | 4 KB standard, 8 KB advanced |
| Cost | Per secret per month + API calls | Standard tier free; advanced tier and high throughput cost extra |
Exam signal
"Rotate the database password automatically every 30 days" is always Secrets Manager. Parameter Store is right when the question stresses lowest cost and doesn't mention rotation.
Cross-account secret with the default key
A secret encrypted with the AWS managed key aws/secretsmanager can't be read from another account, because you
can't edit that key's policy. Re-encrypt it with a customer managed key and grant the other account kms:Decrypt
in the key policy, in addition to the secret's resource policy.
Removing hardcoded credentials
A typical fix for a legacy app that keeps a DB password in a config file and an access key in an environment variable:
secretsmanager:GetSecretValue on that secret only.- ECS task definitions and EKS (through the Secrets Store CSI driver) can inject secrets at start without app changes. CloudFormation can use dynamic references so templates never contain the value.
- For RDS, you can also let RDS manage the master user password in Secrets Manager, or use IAM database authentication so the app gets short-lived tokens instead of a password.
IAM Roles Anywhere
For servers outside AWS that need AWS APIs, instead of long-lived access keys:
- Register a trust anchor: AWS Private CA or your own CA certificate bundle.
- Create a profile that lists the roles the certificates may assume.
- On the server, the credential helper signs with the certificate's private key and returns temporary credentials, usable through the standard SDK credential process.
- Revoke by certificate (CRL) and scope roles with conditions on certificate attributes.
Finding unused and excess access
| Tool | Answers | Scope |
|---|---|---|
| Access Analyzer: external access | Which resources (buckets, roles, KMS keys, secrets, queues) are shared outside my account or organization? | Account or organization, free |
| Access Analyzer: unused access | Which roles, users, access keys, passwords and permissions haven't been used? | Account or organization, paid |
| Access Analyzer: internal access | Which principals inside my organization can reach this critical resource? | Organization |
| Access Analyzer: policy generation | What policy matches what this role actually did? | Reads CloudTrail activity for a chosen period |
| Policy validation and custom checks | Is this new policy valid, and does it grant new or public access? | Run in CI before deploy |
| Last accessed information | When did this principal last use each service (and actions, for some services)? | IAM entity, OU or account |
| Credential report | Every IAM user's passwords, access keys, MFA and last use | Account, CSV |
Right-sizing a role
"Reduce a role to the permissions it actually uses, based on past activity" points to Access Analyzer policy generation from CloudTrail. "Find roles nobody has used in 90 days across the organization" points to the unused access analyzer or last accessed data.
Delegating safely with permissions boundaries
A permissions boundary sets the maximum permissions an IAM user or role can have. Effective permissions are the intersection of the identity policy and the boundary (and any SCPs and RCPs that apply).
- Use it to let app teams create their own roles without being able to create an admin role.
- Also deny them the ability to change or delete the boundary policy itself.
Boundaries don't grant
A permissions boundary never grants anything by itself. A role with a boundary but no identity policy can do nothing. And an SCP restricts whole accounts, so it can't delegate role creation within one account.
Traceability
- CloudTrail records who called which API. An organization trail covers every account (see central security logging).
- Set role session names and source identity so actions through assumed roles trace back to a person.
- CloudTrail Lake or Athena on the trail bucket answers "who changed this, and when" across months.
Scenarios
Secrets Manager rotates Aurora credentials without custom code, and the app reads the current value through its instance role. Parameter Store has no rotation, so the first option means writing and maintaining it. Rebuilding AMIs and manual rotation still leave a password on disk or in a manual process.
The unused access analyzer finds unused roles, keys and permissions across the organization, and policy generation drafts least-privilege policies from what each role actually called. The credential report covers IAM users only, not roles. ReadOnlyAccess may still be broader than needed and could break write workloads, and GuardDuty detects threats, not excess permissions.
Roles Anywhere replaces the long-lived key with short-lived role credentials tied to a certificate from the existing CA. Rotating or vaulting the key still leaves a long-lived key in use, and anonymous access by IP address removes authentication altogether.
Further reading
Automated remediation
Detecting drift, risky changes and security findings in an existing environment and fixing them automatically with Config, EventBridge, Systems Manager Automation and Security Hub.
Customer authentication
Adding sign-in, federation and API authorization to an existing customer-facing app with Cognito user pools, identity pools, ALB and API Gateway authorizers.