AWS Security Best Practice: Attach or Replace AWS IAM Roles to Existing EC2 Instances

One of the approaches our AWS Consultants consistently take is Security by Design. By building security in from the beginning–rather than as an afterthought–security rules, processes and controls are inherent to the system. We like to think of it as a race car with the roll cage built into the frame vs. a race car built and the roll cage added afterward. Truthfully, which car would you feel safer helming?


Unfortunately, not all infrastructure is built with Security by Design (SbD) in mind, or may have been built before some of the best practices were introduced. The ability to go back, perform an AWS security assessment, and add SbD is thus pivotal in re-platforming and enhancing the security of an existing setup which is why we are excited to hear that AWS announced the ability to attach or replace AWS IAM roles to existing Amazon EC2 instances.

Before we fully dive-in to discuss this new feature, let’s back up just a little and explain whey IAM, in general, is a part of the standard Flux7 build:

• IAM provides flexible credential management, giving you control to enforce stricter security standards like Multifactor Authentication (MFA) for users who access the AWS Management Console or use APIs. Or, there is a host of other ways you can authenticate users — from passwords to keypairs. This flexibility allows you to use credentials optimum for your environment. For example, for a financial services firm that had strict security parameters, we used IAM to institute MFA at the firm, thereby further tightening security controls and ensuring it met its internal security and regulatory compliance requirements.
• You can leverage your existing identity system, like Active Directory (AD), with IAM in order to streamline management and more easily grant employees access based on their role within the organization. We have done this work for many organizations now, linking AD or another service to assign permissions and easily update systems with new employee arrival or departures.

Beyond IAM, however, AWS has IAM roles which allow you to define a set of permissions and then let authenticated users or EC2 instances use them, in the process, giving them temporary access to these resources. The result: you don’t have to share long-term credentials or create permissions every time an EC2 instance requires access to a resource. Auditors like IAM roles because they enable applications running on EC2 to use temporary security credentials which greatly reduces the risk associated with an elongated key compromise.

We would argue IAM roles should be part of your AWS build as they are a key component of Security by Design and a security best practice. As the name implies, Identity and Access Management roles allow granular control over which user has access to which resources. We worked with a client recently who had given every developer complete access to every resource. Not only does this open the door to potential malicious activity, but more often than not, employees will accidentally cause security or operational issues by for example inadvertently terminating an EC2 instance.

We’ve discussed in prior blogs one key use case for IAM roles, which is Cross-Account Access. Users may have multiple accounts – say for development and production environments – and in wanting to avoid the operational overhead that comes with managing multiple accounts prefer instead to have cross-account access. IAM roles enable cross-account access, eliminating the challenges of having multiple accounts while retaining the benefits of having separate AWS environments.

Earlier this week we shared the story of a customer whose use of automation helped save the day in an emergency AWS migration. In that piece, we noted that the company was not using IAM roles even though it would have been an enhancement. They were not in use because their ec2 instances predated the introduction of IAM roles as a feature by AWS. The customer had not gone back and added the use of IAM roles because they had the shortcoming that they could not be attached to a running instance — you could only attach a profile when you created the instance.

When we were creating their new VPC and instances, we had only a binary choice: add them or choose to let the opportunity to add them pass us by. Because we did not want to miss the opportunity to enable the customer to use IAM roles in the future, we made the decision to attach IAM instance profiles with empty policies. However, with this new feature, we would have had a third option: to go back and add the IAM role at a time of our choosing.

As you can see, IAM roles enable security best practices, and as a result, we include them as part of the standard Flux7 AWS build. (For steps to enable or replace IAM roles for existing EC2 instances, check out the AWS Security Blog.) For organizations that have not included IAM roles in their initial build, we greatly encourage you to do so and with this new feature, it is easier than ever. For additional reading on Flux7’s approach to building security in, please see our Security by Design best practices resources. And, for additional insights, tips and tricks and news analysis, please subscribe to our blog by clicking below.