AWS IAM Overview

AWS IAM Policies

The Aviatrix Controller 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 Controller 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 in the Aviatrix Controller and in AWS.

Please note that both the Aviatrix Controllers and the Aviatrix Gateways need access to the IAM policies.

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

Auditing and Updating AWS IAM Policies in the Aviatrix Controller

To update your AWS IAM policies from your Aviatrix Controller, log in to the Controller.

  1. Select Accounts > Access Accounts from the lefthand menu.

  2. Select an AWS account and click Audit near to the top of the page. If this account needs an update, text under Account Audit at the top of the page reads "[Account Name] is not using the latest IAM policy."

  3. If the account is not using the latest IAM policy, click Update Policy. The latest IAM policy will be updated for this account.

IAM Roles for Secondary Access Accounts

The primary access account is the first account on the Controller.

If the 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 Controller, 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 Controller 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, or the first account on the Controller, is using a custom EC2 IAM role name for the 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 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.

To onboard an AWS China account, see Account with Access Key for AWS China Accounts.