From the beginning of Vantage we have had the need to connect to our customer’s AWS accounts to interact with AWS services, ingest cost data and potentially take actions on resources within their account. Developing a product which has direct access to a company’s infrastructure requires diligence and we take this responsibility very seriously. We’ve invested considerable time and effort into ensuring the mechanics of our integration is secure and we thought the community would benefit from us sharing our approach.
During our invite-only, early-access period nearly a year ago we started down the “easy” path of having the customer create an IAM User in their account and then giving Vantage the access key and secret for that IAM User. While this was very quick for us to implement in a time where we needed customer feedback, it required additional effort from our customers and did not follow AWS security best practices. After doing some additional research and talking with AWS representatives we changed our approach and implemented the Cross-Account IAM Role methodology.
Connecting to a customer’s AWS account via a Cross-Account IAM Role requires more effort on the part of the provider (in this case, Vantage), but ends up being more convenient for our users and provides a much higher level of security. This method works by creating an IAM Role in the customer’s AWS account with a specific set of permissions (in the case of Vantage, a set of read-only permissions to a variety of AWS services) and then specifying which other IAM Roles have the permissions to “assume” that role. While Vantage uses this method to interact across AWS accounts from different companies, AWS recommends using this same method for interactions between AWS accounts within your own organization as well.
So what are the benefits of Cross Account IAM Roles? It is very common for companies to have multiple AWS accounts. These accounts have completely separate users, roles and permissions. To make it easier to maintain and reduce the blast radius of a security incident, best practices dictate maintaining your IAM users in a management account and specifically granting permissions for those users to assume predefined roles present in the other accounts in the organization.
There are a few benefits with this approach:
- If an IAM user’s password is compromised you only have to reset it in one place (the management account).
- When Vantage assumes a role, the access to that role is temporary and the credentials expire after a specified period of time - which is defined via a TTL.
- The customer ultimately can add or remove IAM permissions on their IAM Role very easily.
- The customer can revoke access to Vantage very easily.
Vantage’s Cross Account IAM Role Architecture
In the Vantage AWS account we create an IAM User and IAM Role per customer. This IAM User has access to assume that IAM Role and that role is what is configured to assume the role in the customer’s account. This process is called Role Chaining and again creates a model where the user is maintained separately from the role. This allows Vantage to make API calls on behalf of the customer.
One more layer of security we employ is the use of an External ID. This is an unique ID we generate per customer account and supply in the creation of the IAM Role in the customer’s account. Only if you supply that specific ID when assuming the role does it actually grant you access. The primary function of the External ID is to address and prevent the “confused deputy problem”. This prevents malicious users from guessing the ARN of another Vantage user’s IAM Role and submitting a connection to Vantage claiming to be the owner of that ARN. Because the External IDs won’t match between accounts, the connection to assume this role will fail. Without the use of an External ID, a malicious user could get all the same privileges of the compromised account.
Heightened Security Doesn’t Mean Sacrificing Developer Experience
At Vantage we strongly believe in providing an intuitive developer experience in all aspects of our product. While the details mentioned above are obviously complex, we believe it’s our responsibility to ensure our self-service onboarding process is as easy as possible. In this case, we wanted to maintain a “one-click” (or copy and paste CLI command) experience for our customers onboarding to Vantage without the need to manually research and configure a multitude of things.
As a result, we turned to AWS CloudFormation to automate the creation of the IAM Role in the customer’s account and also communicate back to Vantage to hand us the information necessary to complete the connection. In order to communicate back to Vantage we took advantage of the AWS SNS Custom Resources functionality which allows you to specify an SNS topic and the data which will be sent to that topic inside of a CloudFormation template.
Conclusion
Overall we thought this was a great process built on primitives provided by AWS. AWS representatives also told us that not everyone was utilizing this method to connect to third-party AWS accounts. In light of that, we thought it would be useful to share our implementation with the community to ensure as many products as possible were utilizing the cross-account method.
This blog post details how we connect to a single AWS account. Our larger customers have requirements for connecting dozens or maybe hundreds of AWS accounts. The next post in this series will cover our implementation of CloudFormation StackSets which make it very easy for our users to connect all of their organizational member accounts in two simple commands in five minutes or less.
Reactions from the Community
Colm MacCarthaigh, VP / Distinguished Engineer at Amazon Web Services
A community member in response to Corey Quinn of The Duckbill Group
A community member mentioning the Vantage IAM integration with AWS accounts.
