Specifying AWS access and secret keys at an EC2 instance violates AWS recommendations

According to AWS documentation, it is recommended to use IAM roles to manage permissions Security best practices in IAM - AWS Identity and Access Management

If we hardcode the access keys in a config file then the following difficulties might occur:

  • If access and secret keys were retrieved by assuming a role (AWS STS assume role API), then the maximum session length for such keys is 12 which is not enough for ODM processing. We can create an IAM user of cause and enable secret keys there. These keys do not have limitations regarding session length. But it violates other aws security best practices. IAM users are used mainly to connect external systems to AWS.
  • Security compliant organizations might have alerts enabled at AWS Config and some of them would be in an alarm state, e.g. ec2-instance-profile-attached - AWS Config
  • We want to have config files version-controlled. In this case, it’s not good to keep secret keys in a GitHub repo.

It would be great if you guys had accessKey and secretKey configuration parameters as optional so that ClusterODM users could configure IAM roles for EC2 themselves. It would be also nice to have examples of IAM policies in the documentation or (Cloudformation?) scripts to create the IAM policies, roles, instance profiles, etc.

1 Like

This is an informative review of recommendations and options. Are you able to open a pull request with implementation? I have found modification of ClusterODM to be reasonably straightforward, and pull requests are quickly accepted.

Regardless, thanks for bringing this up!

2 Likes