Amazon Web Services (AWS)
  • 9 minutes to read
  • Print
  • Share
  • Dark

Amazon Web Services (AWS)

  • Print
  • Share
  • Dark

The Amazon Web Services (AWS) adapter includes a broad set of global cloud based products. It supports EC2, ECS, EKS, IAM, EBS, ELB, RDS, S3, VPC, Workspaces, Lambda and Route 53.

To connect Axonius to your AWS resources, you will need to create an IAM user, assemble the required credentials (Access key id & Secret access key) and configure your account/accounts if necessary.

The Amazon AWS Adapter connection requires the following parameters:

  1. Region Name or Get All Regions (optional) – Set the region name for a specific region or If you would like Axonius to try connecting to all regions, select the "Get All Regions" option.
  2. AWS Access Key ID (optional) - Provide AWS Access Key ID or choose to use EC2 instance attached IAM role.
  3. AWS Access Key Secret (optional) - Provide AWS Access Key Secret or choose to use EC2 instance attached IAM role.
  4. Account Tag (optional) - Optional tag for the EC2 instance ("nickname").
  5. Proxy (optional) - An optional https proxy.
  6. Roles to assume (optional) – A file with a list of comma-delimited role-ARNs which the AWS Adapter will try to assume for cross-account access with the single IAM user.
  7. Use attached IAM role (optional) - Select to use the EC2 instance (Axonius installed on) attached IAM role instead of using the AWS Access Key ID and AWS Access Key Secret credentials supplied.
  8. Choose Instance - If you are using multi-nodes, choose the Axonius node that is integrated with the adapter. By default, the 'Master' Axonius node (instance) is used. For details, see Connecting Additional Axonius Nodes


Connecting the Amazon Web Services (AWS) Adapter

To connect this adapter, you will first need to create an IAM user:

  1. Open your AWS Dashboard and go to the IAM service.


  1. Go to the "Policies" tab and click "Create policy". You will need to create a policy that grants read-only access to specific AWS Resources.


  1. Click JSON and copy-paste the following JSON, which provides Axonius read-only access to the EC2, ECS, EKS, IAM, SSM, RDS,S3, Workspaces and Lambda services
    "Version": "2012-10-17",
    "Statement": [
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
            "Resource": "*"
  1. Click "Review policy" and fill in the details. Then click "Create policy".

  2. Next, click "Users" and then "Add User". Select "Programmatic access" to allow Axonius use the AWS API, and proceed to the permissions screen.


  1. In the permissions screen, click "Attach existing policies directly", then attach the policy we just created.


  1. Finally, click "Create User". You will see an access key ID and a secret access key you can show. Save both of them in a secure location (they will not appear again) for the adapter configuration.


  1. At this point we can use the credentials to access Axonius. Fill in all required fields in the adapter configuration, click save, and the AWS adapter is configured.

  2. However, if you would like to use AWS EKS or AWS Roles, the configuration requires additional steps. Proceed to the next section to add permissions to your IAM User.

EKS Configuration

When an Amazon EKS cluster is created, the IAM entity (user or role) that creates the cluster is added to the Kubernetes RBAC authorization table as the administrator. Initially, only that IAM user can make calls to the Kubernetes API server using kubectl. Thus, we need to add our new IAM account to the kubectl configurations to get read-only permissions.

First, we need to get the ARN of the user we just created. In the IAM Service, click "Users" and select the new user we just created. Copy its User ARN.


  1. We need to use kubctl, Kubernetes' admin command line interface to add a read-only group and map our AWS user to it. For each cluster you want Axonius to connect to, do the following steps.

As a logged-in admin, create a ClusterRoleBinding that maps the "view" ClusterRole to the group "axonius-readonly":

kubectl create clusterrolebinding axonius-view-cbr --clusterrole=view --group=axonius-readonly


  1. Then, edit the Kubernetes AWS auth configurations, and add a new user mapping. If you don't have the mapUsers block already, create it.
    Open the editor to edit the configurations:
kubectl edit -n kube-system configmap/aws-auth

Then, append the new user mapping, while replacing the 'userarn' field with the ARN we got before.

mapUsers: |
    - userarn: arn:aws:iam::405773942477:user/Axonius-Readonly

      username: axonius-readonly


        - axonius-readonly

The first part of the most basic configuration file should look similar to this:


  1. Save the file.
  2. You should see a message indicating your edit was successful.

Your IAM account can now authenticate against the Kubernetes cluster.

AWS Roles configuration

Axonius supports IAM Roles in the AWS adapter alongside the current IAM User for cross-account access, meaning that the AWS adapter can assume specified roles to allow fetching devices from other AWS accounts. To do this, you will have to create a role in the desired additional AWS account(s), and allow the IAM User which is being used in the adapter to assume this role. In each of your additional accounts:

  1. Go to IAM and create the same policy created at steps 1-4.
  2. Go to IAM -> Roles and create a new role. Choose "Another AWS Account". Fill in your primary account ID (the one in which the primary IAM user resides) and leave the other 2 options unchecked.


  1. Click "Next" and select the read-only policy.


  1. Click "Next" and fill in the details to create the role.


  1. Now select the role you just created. Change the maximum session duration to 4 hours and click "Save changes".


  1. Go to "Trust relationships" and click "Edit trust relationship". You will need to edit this trust relationship to allow only your specific IAM user to assume this. Change the 'AWS' parameter in the policy document to the IAM UserARN you created in the beginning of the guide. If you don't know it, log in to your primary account , go to IAM -> Users and click the IAM user to get its ARN.


  1. Save the policy and keep the role ARN.

  2. Do this for every additional account you want the AWS Adapter to connect to. After you are done, go back to your main account (the one with the IAM User you created). Go to IAM -> Policies to create a policy which allows your IAM User to assume the roles you created. Click "Create Policy" and switch to the JSON tab.

  3. Paste the following JSON Policy and append your Role ARNs. In this example, we have 2 roles.

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
  1. Click "Next" and give this policy a name, then create it.


  1. Finally, go to IAM -> Users, select the user you created for Axonius and click "Add permissions". Attach the policy you created to allow this user to assume the roles. Attach the policy.


  1. At this stage you can use Axonius to assume the roles you created. To assume these roles, create a comma-delimited file which contains all the role ARNS and use it in the adapter settings screen. As an example, such a file could be:
arn:aws:iam::817364327683:role/AxoniusDevRole, arn:aws:iam::802876684602:role/Axonius-Readonly-Role

Configuring AWS Correlation Logic and Retrieved Information

The Amazon Web Services (AWS) adapter has unique, advanced settings which enable configuring the logic around correlation of the AWS cloud servers (devices) and the information Axonius will fetch for each of them.

To configure the AWS Adapter advanced settings, open the AWS adapter screen, click "Advanced Settings", and then click the "AWS Configuration" tab:


  • Correlate ECS containers with their EC2 Instance (default: False) - Check this to correlate ECS containers with the EC2 host they are running on. Otherwise, they will be shown as two different devices.
  • Correlate EKS containers with their EC2 Instance (default: False) – Check this to correlate EKS containers with the EC2 host they are running on. Otherwise, they will be shown as two different devices.
  • Fetch information about EC2 attached roles (default: False) – Check this to fetch information about each EC2 attached roles.
  • Fetch information about ELB (Elastic Load Balancers) (default: False) – Check this to fetch information about all available load balancers and assign information to relevant EC2 instances. Each ELB will be represented then as a separate device.
  • Fetch information about SSM (System Manager) (default: False) – Check this to fetch additional information from AWS SSM for each host.
  • Fetch information about NAT Gateways (default: False) – Check this to consider NAT gateways as devices. If selected, the adapter will fetch all available NAT gateways as well.
  • Fetch ELB IP using current DNS (default: False) - Check this to fetch the IP of each ELB using the current DNS server.
  • Fetch information about RDS (Relational Database Service) (default: False) - Check this to fetch the information on the existing Amazon RDS instances.
  • Fetch information about S3 (default: False) - Fetches information about S3 Buckets, such as their ACL's, locations and their public status.
  • Fetch information about IAM Users (default: False) - Fetches information about IAM users, attached groups, attached policies and access keys.
  • Fetch information about Workspaces (default: False) - Check this to fetch information on Amazon workspaces.
  • Fetch information about Lambdas (default: False) - Check this to fetch information on AWS Lambdas.
  • Fetch information about Route 53 (default: False) - Check this to fetch information on Amazon Route 53 DNS records.
  • Show verbose notifications about connection failures – Check this to create a notification with all failed AWS connections on each cycle.
  • Shodan API key for more IP info (optional, default: empty) – Specify an API key which will be used to query information about public IP addresses.
  • Verify all IAM roles (default: True) - Whether or not to verify all IAM roles. If one of the IAM roles is not valid, the adapter connection will fail.
  • Verify primary account permissions (default: True) - Whether or not the primary account permissions should be used when the adapter connections fetch data from AWS.
    • If enabled, all connections for this adapter will use the primary account permissions to fetch data from AWS. If the primary account permissions are insufficient, the adapter connections will fail to fetch the data.
    • If disabled, all connections for this adapter will only use the primary account to assume the roles attached to it, and the adapter connections will use those role permissions to fetch data from AWS. This setting should be disabled only if you want to use the primary account assumed roles permissions instead of the primary account permissions when fetching assets from AWS.
  • Do not fetch EC2 machines that are turned off (default: False) - Whether or not to fetch EC2 devices that their power state is turned off.
    • If enabled, all connections for this adapter will only fetch EC2 devices which their power state is turned on.
    • If disabled, all connections for this adapter will fetch all EC2 devices, regardless of their power state.
Was this article helpful?