Articles

AWS connections

Set up read-only AWS access

Connect NetworkLink.EU to your AWS accounts using an access key and a read-only IAM role. Every setup step below uses the AWS Management Console; no command line is needed.

Reviewed against AWS documentation and the app’s permission policies on 25 September 2026.

How the connection works

The access key belongs to an IAM user. NetworkLink.EU uses it to request temporary credentials for an IAM role through AWS STS AssumeRole. The app then reads your inventory with those role credentials. You do not create permanent access keys for the role.

Your computer → IAM user credentials → AssumeRole → read-only inventory role → AWS APIs.
The source user and target role may belong to the same AWS account or different accounts. Your desktop connects directly to AWS; you do not grant access to a NetworkLink.EU-owned AWS account.

There are three separate permission documents: the role’s trust policy identifies the source user, the source user’s policy permits assuming the role, and the role’s inventory policies permit reading AWS configuration. See AWS’s cross-account role guide.

Can I use an existing access key?

Yes. An existing active IAM user key works when that user is trusted by the role and allowed to assume it. No new key is required specifically for AssumeRole.

We recommend a dedicated IAM user for this app, with permission only to assume your inventory roles. This makes access easier to review, rotate and remove independently. A second key on an existing administrator user still has that user’s permissions; it does not create a restricted identity. Never enter root account access keys.

AWS recommends temporary credentials where possible. This version of NetworkLink.EU accepts explicitly supplied access keys, including temporary credentials with a session token; it does not offer AWS SSO/profile sign-in or interactive MFA prompts. This guide covers the supported IAM user → role flow. Keep your organisation’s authentication requirements in place and consult your AWS administrator if they require a different flow. AWS access-key guidance.

Before you begin

Use your usual authorised AWS administrator sign-in to configure IAM. That administrator needs permission to create users, keys, roles and policies and attach permissions. Those setup permissions are not required by the app’s source user.

  • Source account: contains the IAM user whose key you enter in the app.
  • Target account: contains the resources you want to scan and the read-only role.
  • For a single-account setup, both are your own account. For multiple accounts, repeat the target-side setup in each account.
  • The current app supports the commercial AWS partition (arn:aws:), not AWS China or GovCloud.

The account numbers below are examples: 111111111111 is the source and 222222222222 is the target. Replace them with your actual IDs. Use the same real ID in both places for a single-account setup.

1. Create or select the source user

  1. Sign in to the source account and open the IAM console.
  2. Open Users → Create user. Name it NetworkLinkEUSource. Leave console sign-in access disabled; the app needs programmatic access only.
  3. Continue without attaching permissions or adding it to a group. Review and create the user. We will grant the scoped AssumeRole permission in step 4.
  4. Open the user and copy its ARN. For example: arn:aws:iam::111111111111:user/NetworkLinkEUSource. Copy the complete ARN, including any path.

If you use an existing user, open it and copy its ARN instead. It must already exist before you create the role’s trust policy. See AWS’s console instructions for creating a programmatic user; use the limited permissions in this guide rather than the broad example policy in that tutorial.

2. Create the inventory permission policies

Sign in to the target account. Download these two JSON documents. They contain the app’s current inventory and investigation read permissions. The supplement provides additional read-only inventory permissions separately because of AWS’s policy size limit. Attach both policies:

  1. In IAM, open Policies → Create policy and select the JSON editor.
  2. Open the first downloaded file in a text editor and paste its entire contents, replacing the editor’s initial document.
  3. Review validation messages, choose Next, enter the corresponding policy name above, then Create policy.
  4. Repeat for the second file. Keep them as two separate customer-managed policies.

The documents are split to stay within AWS’s 6,144-character limit per customer-managed policy, excluding whitespace. Do not combine them into one policy. See creating policies in the console and IAM policy size limits.

What API access do these policies grant?

The downloadable JSON files are the complete IAM action lists for this app version. They cover supported network, compute, storage, database, messaging, security and other inventory services, plus cloudtrail:LookupEvents for change investigations. Examples include ec2:DescribeVpcs, ec2:DescribeInstances, ec2:DescribeRouteTables, directconnect:ListVirtualInterfaceRoutes and route53:ListResourceRecordSets.

API Gateway uses apigateway:GET on the listed management paths; this does not grant API invocation. Some IAM action names differ from their SDK operation names. Use the supplied policies rather than deriving permissions from API names.

Resource: "*" allows those listed reads across resources in scope; it does not mean all actions are allowed. Many inventory list/describe operations require this scope. The policies grant no resource creation, modification or deletion, secret-value retrieval or KMS decryption. Readable configuration can still contain sensitive information, such as environment variables and network settings.

These are allow policies, not a restriction on other grants. Keep the role dedicated and free of additional write permissions. Administrators may reduce permissions for a narrower scan scope; missing required reads will produce incomplete coverage. Selecting fewer services in the app limits calls, but does not change IAM permissions.

3. Create the inventory role

  1. Still in the target account, open IAM → Roles → Create role.
  2. Choose Custom trust policy. Replace the editor contents with the following JSON, substituting the exact source user ARN from step 1.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TrustNetworkLinkEUSourceUser",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:user/NetworkLinkEUSource"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Download trust policy template. This belongs in the role’s trust policy, not in the permission policies created in step 2.

  1. Choose Next. On the permissions step, select both NetworkLinkEUReadOnlyInventory and NetworkLinkEUReadOnlyInventorySupplement.
  2. Continue, name the role NetworkLinkEUInventory, review and create it.
  3. Open the role and copy its ARN, for example arn:aws:iam::222222222222:role/NetworkLinkEUInventory. Confirm both policies appear under Permissions and the correct user appears under Trust relationships.

AWS: create a role with a custom trust policy.

External ID and MFA requirements

The template does not require an External ID. Leave the app field empty unless your administrator requires one. If required, add the following Condition inside the trust statement, alongside Principal and Action, and enter the same value in the app:

"Condition": {
  "StringEquals": {
    "sts:ExternalId": "replace-with-your-agreed-external-id"
  }
}

An External ID is not a password and does not replace the trusted user. See AWS’s External ID explanation. This desktop setup does not require granting a vendor account access.

The app cannot supply an MFA device serial number and one-time code on its AssumeRole request. If your organisation requires that flow, ask your administrator for an approved authentication approach; do not remove required MFA controls to follow this guide.

4. Allow the user to assume this role

Return to the source account. Open IAM → Users → NetworkLinkEUSource → Permissions → Add permissions → Create inline policy. Select JSON and paste the following, replacing the example role ARN with the exact ARN from step 3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeNetworkLinkEUInventoryRole",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/NetworkLinkEUInventory"
    }
  ]
}

Choose Next, name the policy NetworkLinkEUAssumeInventory, then create it. See AWS’s instructions for assigning identity permissions. Download source permission template.

Attach the inventory read policies to the role; the source user only needs the permission above. For several target accounts, make Resource an array containing their exact inventory role ARNs. Each target role must also trust this source user. Create a separate connection in the app for each target role.

5. Create the user’s access key

Return to the source account. Open IAM → Users → NetworkLinkEUSource → Security credentials. This is the user you created in step 1. If you chose an existing user in that step, select that user instead.

Skip this step if you already have an active access key and its secret for this user.

  1. Scroll to Access keys and choose Create access key.
  2. Review AWS’s guidance, select Other, then choose Next.
  3. Enter a description such as NetworkLink.EU desktop so you can identify this access key later, then choose Create access key.
  4. Copy the Access key ID and Secret access key, or choose Download .csv file, and store them securely. AWS only reveals the secret at creation time.

Enter these credentials in the desktop app only. Do not paste them into this documentation site, reports or support messages. See AWS’s console instructions for managing user keys.

6. Connect and create a snapshot in the NetworkLink.EU app

The AWS console setup is now complete. Open the NetworkLink.EU desktop app on your computer and follow the steps below to add your AWS connection and create your first snapshot.

  1. Activate a valid NetworkLink.EU license with an available slot in its shared AWS/Azure allowance. Select AWS in the cloud dropdown, then open AWS connections → Add connection.
  2. Give the connection a name and select the AssumeRole authentication method.
  3. Enter the source user’s access key ID and secret, and the target Role ARN copied in step 3 for NetworkLinkEUInventory. Paste your actual ARN, not the example account number. Leave Session token empty for an IAM user’s long-term key; temporary credentials require their matching token.
  4. Leave External ID empty unless the trust policy requires one. The default role session name NetworkLink.EU is suitable.
  5. Optionally click Test identity to confirm the target account. Saving also verifies identity. A successful check confirms authentication; it does not check all inventory permissions.
  6. Click Discover regions to load the target account’s enabled regions, then select the regions and services you want to scan. This is the recommended next step after testing identity. You can also save first and discover regions from the saved connection, but you must select regions before scanning.
  7. Choose whether to save credentials using OS encryption, then Save connection. Saving also verifies identity and checks the account allowance. If secure credential storage is unavailable, AWS credentials remain available only for the session.
  8. Select the saved connection and click Scan selected accounts. This creates the inventory snapshot. Discover regions does not create a snapshot.

Include VPC, EC2 and relevant network services to see their relationships. A successful identity check confirms authentication, not every inventory permission; review scan coverage after the first snapshot. Global services are collected once per account; regional services follow your region selection.

Troubleshooting and maintenance

  • AssumeRole is denied: check the source user ARN in the trust policy, the target role ARN in the source policy and app, any External ID, and organisational policies or permission boundaries. Allow statements cannot override an explicit deny.
  • Identity works but resources are missing: confirm both inventory policies are attached, the relevant services and regions were selected, and inspect the snapshot’s scan coverage for denied or failed reads.
  • Invalid or expired credentials: check the key is active and belongs to the trusted user. Temporary source credentials need a valid session token and must be replaced when they expire.
  • The connection is not saved: read the form’s error message. Required fields, AWS identity verification and license/account allowance checks must succeed.
  • Key rotation: create a replacement key, update the app connection and verify access before deactivating the old key. Avoid disrupting other applications if you reuse a user.

The role session is temporary and refreshed by the app when needed. Disabling the source key prevents new sessions, but does not instantly cancel already issued role credentials. Follow AWS’s role-session revocation instructions when immediate removal of existing role access is required.

When adding new supported services, review the updated app permission documents and update the two IAM policies through their JSON editors as needed.