AWS access from within AWS instances is achieved by either encoding AWS keys into AWS API calls, or by assigning the instance to a role which has an appropriate permissions policy for the access required. AWS Access allows access to the APIs of AWS in order to use AWS resources, and manage AWS account resources.
AWS IAM roles reduce the risks associated with sharing and rotating credentials that can be used outside of AWS itself. If credentials are compromised, they can be used from outside of the AWS account they give access to. In contrast, in order to leverage role permissions an attacker would need to gain and maintain access to a specific instance to use the privileges associated with it.
If credentials are encoded into compiled applications, or other hard to change mechanisms, they are even more unlikely to be properly rotated due to service disruption risks. As time goes by, credentials that aren't rotated are more likely to be known by an increasing number of individuals, some may no longer work for your organization.
To remediate an instance by attaching a role, follow these steps:
- Select the instance.
- From Actions, press Instance Settings, then Attach/Replace IAM Role.
- Select an existing role to attach to the instance, or use the AWS wizard to create a new role.
If your environment has dependencies on a dynamically assigned PRIVATE IP address you can create an AMI from the existing instance and destroy the old one. Following this, when launching from the AMI, manually assign the previous private IP address.
If your environment has dependencies on a dynamically assigned PUBLIC IP address there is no way to ensure the address is retained and assigned an instance role. Having dependencies on dynamically assigned public IP addresses is bad practice. When possible, rebuild the instance with a new elastic IP address and make the investment to remediate affected systems while assigning the system to a role.
Updated about 2 years ago