AWS IAM Overview

AWS IAM Policies

The Aviatrix Platform in AWS is launched by a CloudFormation script. During the launch time, two IAM roles are created, aviatrix-role-ec2 and aviatrix-role-app. Two associated IAM policies are also created, aviatrix-assume-role-policy and aviatrix-app-policy.

These two roles and their associated policies allow the Aviatrix Platform to use AWS APIs to launch gateway instances, create new route entries and build networks. As more features are added by Aviatrix with each release, the IAM Access Policy may need to be updated to allow the Controller to launch new services.

This document shows you, an Aviatrix user, how to update your AWS IAM policies.

Please note that the Aviatrix Controller and CoPilot and the Aviatrix Gateways need access to the IAM policies.

Please ensure that IAM policies are consistent across all AWS accounts that the Controller, CoPilot, and Gateways are located in.

Auditing and Updating AWS IAM Policies in Aviatrix CoPilot

To update your AWS IAM policies from Aviatrix CoPilot:

  1. Go to Aviatrix CoPilot > Cloud Resources > Cloud Accounts.

  2. Find the AWS account to audit and update and click the three dots icon on the right > Audit Account.

  3. If this account needs an update, text in the Comment section reads "[Account Name] is not using the latest IAM policy."

  4. If the account is not using the latest IAM policy, click Update.

The latest IAM policy will be updated for this account.

IAM Roles for Secondary Access Accounts

When the Aviatrix Platform goes through the initial Onboarding process, the primary access account is created. Using the primary access account, the Controller can launch gateways and build connectivity in the VPCs that belong to this account.

If the Aviatrix Controller needs to build connectivity in AWS accounts that are different from the Controller instance’s AWS account, secondary access accounts need to be created.

To create a secondary AWS access account on the Aviatrix Platform, you need to first create IAM roles, policies and establish a trust relationship to the primary AWS account.

Follow the steps below to create IAM roles and policies for the AWS secondary access account.

(If you like to customize the conditions of the policies published by Aviatrix, consult this link.)

What Permissions are Required in App Role Policy and Why

The App role policy (example), has different “Actions” to allow on certain resources. Your Aviatrix Platform needs those policies to function.

  1. ec2 – to create/delete/list/modify VPCs, Aviatrix Gateways, security groups, route tables, tags, start instance, stop instance, reboot instance, associate/de-associate IP address, etc.

  2. elasticloadbalancing – to create/configure/delete/modify ELB for Aviatrix VPN Gateway

  3. s3 – to create/add/delete s3 buckets for save-and-restore and cloudTrail features

  4. sqs – to create/delete/list/send/get SQS and SQS messages for Controller-to-gateway communication

  5. sns – to create/delete/list/subscribe/unsubscribe SNS and SNS topic for Gateway HA feature

  6. route53 – to create/delete/list hosted zone, and change the resource record for GeoVPN feature

  7. cloudwatch – to put/delete alarm for Aviatrix Gateway HA feature

  8. iam – to support role-based IAM account

Notes for the Custom IAM Role Name Feature

If the primary access account is using a custom EC2 IAM role name for the Aviatrix Controller, then any secondary IAM based access accounts must use an identical name for the EC2 IAM role.

The primary and secondary access accounts must use identical names under the following conditions:

  • You are using custom IAM roles for the primary access account.

  • You are NOT using custom gateway IAM roles on the secondary account.

Example:

The Aviatrix Controller is using 'custom-role-app' and 'custom-role-ec2' on a secondary access account. Custom role 'custom-role-ec2' also exists on the primary account because that is where the Controller is hosted.

When you launch a gateway under the secondary access account, the Controller takes the primary access account EC2 role name, in this case 'custom-role-ec2' and passes it to the API call to create the instance. The API call refers to a role on the secondary CSP account, not the role of the primary account.