AWS IAM Roles, keys & STS

Amazon Web Services (AWS) IAM roles are sets of authorization that serve as a regular way to assign access to users or services. Identity and Access Management Roles can be assigned to any external or internal IAM users, AWS services, Third party applications and user accounts outside of AWS. Roles hold by users enable additional permissions for specific tasks. Applications and Services using roles obtain the access needed to interact with AWS services without the need to use AWS keys. IAM roles are a common solution to grant additional access required temporarily.

Assuming IAM roles is the action of obtaining the set of authorization designated by the role. When a service assumes a role, the Security Token Service (STS) issues a set of role credentials which serve as a encrypted token to access the corresponding environment. role can be assumed by AWS Management Console, or windows PowerShell, the AWS CLI, or the SDKs for various programming languages. For more additional control, policies can also be used to further limit the role permissions. Requests made after the role is acquired are performed with this new identity, But CloudTrail logs can be used to catch the underlying service assuming that role.

Amazon web Services Account ID:
Amazon web Services account IDs are unique for every AWS account and misuse can compromise your account. While sharing the ID does not cause an account to compromise, but hacker can use account id for some kind of attacks. You should keep your AWS account IDs private, but leverage the benefits of cross account services you need to share it with different groups, sometime that leads to exposed to the public unintentionally.

You should avoid following practice to share you Account IDs:

• Screenshots sharing via emails or any online mode
• All Third party code repositories including GitHub
• Sharing AWS error messages (even access denied) on public platforms for online help
• Through Public EBS snapshots
• Promoting Public AMIs (EC2 -> AMIs -> Public images) for references
• Avoid RDS public snapshots (RDS -> Snapshots -> All Public Snapshots)
• Do not post ID on online posts, when you are desperately looking for solutions

If an hacker has your ID, various hacking scenarios are open for them, Identity and access management role assumption leads to explore existing roles and users, Lambda function can be misused to gain access to your account.

Simple steps can Prevent big hacking attempts:

• Identity and access management user and accounts should be created mindfully considering requirements of users and services.
• Everybody should not have full access, It should be driven by requirements.
• Additional Access/Assume Role for service or user account require strict policies.
• All tags or resources names should be carefully planned on code names not easy to guess. ( Do not use common company or department names )
• AWS account ID are suppose to be shared only with designated members, should not be shared publicly.