Amazon Web Services (AWS)

  • 4 minute read
Prev Next

You can access the required APIs in AWS using an IAM user with the appropriate Secret Access Key, or you can configure the option to use IAM roles linked to the instances themselves.

Normally, the IAM user must be within the same AWS account as the environment. You can get over this limitation by using the AWS concept of “assumed roles”. This allows the root IAM user to jump to a different user/role personae in different accounts/regions.  

For all IAM roles specified, you will need a new access policy for AppGate ZTNA or you can use an existing Amazon EC2 policy; one with a read-only policy for AppGate ZTNA is perfect. The reason is that once we know the tags or other entities from the entitlements, we need to access the instance metadata in order to retrieve the IPs. 'Describe*' gives read-only access to any EC2 objects.

Attach the AppGate ZTNA policy to the user or role. If using roles, this will be included automatically in the profile when launching an AppGate ZTNA instance from the Marketplace.

The following is the appropriate policy to set up:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeInstances",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeVpcs",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeTags"
            ],
            "Resource": "*"
        }
    ]
}

If you are enabling RDS, EKS, or an API Gateway, use the following policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeInstances",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeVpcs",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeTags",
                "apigateway:GET",
                "eks:DescribeCluster",
                "eks:ListClusters",
                "rds:DescribeDBInstances"
            ],
            "Resource": "*"
        }
    ]
}

For more information about this example, see docs.aws.amazon.com.

Now you can use the special name resolver syntax to define hosts in your entitlements.

AWS assume role configuration

Let's say you have VMs in VPC A that have network access to VMs in VPC B (they have VPC peer connectivity). Assume that these VPCs are managed by two different accounts A and B. You want the Gateway in account A to be able to resolve VMs with a certain tag that resides in account B. This will not work immediately as these belong to different accounts, and the IAM credentials for the Gateways will not work in account B. Here is where you can use assumed roles to make this work:

In AWS account B

Create an IAM role and attach the appropriate policy to it as in the section above under Amazon Web Services (AWS). The existing AmazonEC2ReadOnlyAccess policy could also be an option; see docs.aws.amazon.com

Edit the trust relationship of the created IAM role, adding the trusted entities that can assume this role plus any conditions associated with this Role as in the example below:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::ACCOUNT_A_ID:role/name_of_role"},//Role ARN in account A that will assume this role
"Action": "sts:AssumeRole"
"Condition": {"StringEquals": {"sts:ExternalId": "12345"}} //Read Note below
}]
}

NOTE

When a role policy includes an external ID, anyone who wants to assume the role must include the correct external ID in the AssumeRole API call. The external ID can be any secret identifier that is known by the two accounts.

For more information, refer to: https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

In AWS account A

You may already have an IAM role with the AmazonEC2ReadOnlyAccess or similar policy attached to it. If not, create a new IAM role which needs to be associated to your instance. Then create a new policy selecting Service > STS, Action > Write (AssumeRole), Resources > Specific and then under Role specify the ARN from Account B (this will allow it to assume the role already defined in Account B and attach it to the role).

The policy should look similar to the following:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::ACCOUNT_B_ID:role/name_of_role" //Role ARN in account B that will be assumed
}
]
}

Under Permissions, attach the new policy to your role.

Once done, your Gateways will have the permissions from the role they are assuming allowing them listing and describing instances in account B. You can now configure it in the resolver using the usual syntax.

Related articles