Rethink before creating an IAM user
There are few scenarios in which we might need IAM credentials (static). i.e. in automations like terraform and if it runs on-premises. Creation of static IAM credentials should be avoided .
So, what are the options if it’s part of your workflow/automations etc. :-
1. Explore IAM Roles anywhere document →
AWS Identity and Access Management (IAM) has now made it easier for you to use IAM roles for your workloads that are running outside of AWS, with the release of IAM Roles Anywhere. This feature extends the capabilities of IAM roles to workloads outside of AWS. You can use IAM Roles Anywhere to provide a secure way for on-premises servers, containers, or applications to obtain temporary AWS credentials and remove the need for creating and managing long-term AWS credentials.
2. Automation in cloud →
Run your automation in cloud and attach IAM role to ec2 instance directly (make sure to enable imdsv2 only).
3. SSM-Agent on-premises →
Configure on-premises servers that uses SSM agent to use temporary credentials.
If you have strong business justification and have to use IAM credentials due to legacy systems or integration with third parties then use below points to make sure you cover it all :-
- Craft your IAM policy very carefully ( Don’t use wildcards).
Example : You have to have more clarity about permissions allowed i.e ec2:* vs ec2:StartInstances. You might need to add some list/readonly permission together with RW permissions. Try below IAM policy generator :
2. Whitelist your on-premises egress IP’s only.
Checkout your organization egress IP’s. You can check all datacenters/POP location and whitelist. Here is an example to check it from terminal : curl ifconfig.me (but the list can be long/multiple subnets as your org might present in multi DC.)
3. Store IAM secrets in safe place.
Store credentials in safe place E.g — Secrets Manager, Vault etc. Do not store it in plaintext form. E.g :- ~/.aws/credentials etc.
4. Rotate credentials every 90 days (or if key team member leaves organization).
As per best practices, we should rotate credentials every 90 days. You can simply achieve it by creating a second set of IAM creds and start using it. Disable old IAM keys and delete it after few days. Same can be done whenever a key team player leaves organization.
5. Monitor/alert for any changes in IAM policy via Cloudtrail.
Always push changes via Infrastructure as a Code policy so all team members have consensus about the change and knows about the change as well. If it’s critical policy then setup alert for any modifications.
Tip:
For sanity purposes, you can also look into discovering all IAM roles/users which are not in use from last n number of days and can mark them for removal (with approval process):
