Error 403 InvalidClientTokenId when configuring AWS plugin

Products

Network Observability Virtual Network Assurance

Issue/Introduction

When attempting to configure the AWS plugin in the Virtual Network Assurance (VNA) Admin UI or via Swagger, the configuration fails with a 403 Forbidden error. The logs indicate an InvalidClientTokenId exception. This usually happens when temporary security credentials (STS/SSO) are used instead of permanent IAM credentials.

The VNA Admin UI displays a failure error with code 403 upon saving the plugin configuration.
The /opt/CA/VNA/wildfly/standalone/log/oc.log shows: ERROR [AWS_PLUGIN] AWSPluginConfigHandler: Failed to connect AWS region: Http status code: 403: com.amazonaws.services.identitymanagement.model.AmazonIdentityManagementException: The security token included in the request is invalid. (Service: AmazonIdentityManagement; Status Code: 403; Error Code: InvalidClientTokenId)

Environment

DX NetOps Virtual Network Assurance (VNA)
AWS Plugin

Cause

The DX NetOps VNA AWS plugin currently supports only permanent Access Key ID and Secret Access Key credentials from a standard IAM user. It does not support temporary (short-lived) credentials generated via AWS STS or AWS SSO, which require a Session Token (typically identifying with keys starting with ASIA).

Resolution

To resolve this issue, use permanent IAM user credentials:

Generate Permanent Keys: In the AWS Management Console, create a dedicated IAM user for VNA with ReadOnlyAccess and generate a permanent Access Key and Secret Key (starting with AKIA).
Verify Credentials via AWS CLI: Test the keys directly from the VNA server terminal:
bash
```
export AWS_ACCESS_KEY_ID="####"
export AWS_SECRET_ACCESS_KEY="####"
export AWS_DEFAULT_REGION="####"

aws sts get-caller-identity
```
If the keys are valid and permanent, the command returns the IAM user ARN without error.
Handle Special Characters: If the Secret Key contains special characters (e.g., #, &, +), URL-encode them in the VNA UI (e.g., use %23 for #).
Update VNA Configuration: Enter the verified permanent keys into the VNA Admin UI.

If you still experience issues, please see . Scroll to the bottom of the page and click on your respective region.

Additional Information

Subscribe to this article to be updated on future support for temporary credentials: .

How to Test AWS Credentials Outside of VNA

Before plugging the new credentials back into VNA, you can easily verify that they work using the AWS Command Line Interface (CLI).

Here are the step-by-step instructions to test the credentials using the AWS CLI on your VNA server:

1. Connect to the VNA Server

Log in to your VNA server via SSH using your preferred terminal application (e.g., PuTTY, Terminal, etc.).

2. Verify AWS CLI is Installed

Before testing, check if the AWS CLI is already installed on the server by running:

Bash 
aws --version

If it returns a version number: You are good to go to step 3.

If it says "command not found": You will need to install it quickly. You can do this by running the following commands:

Bash 
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

3. Export the Credentials as Environment Variables

To securely test the credentials without modifying any system-wide configuration files, you can load your new permanent Access Key and Secret Key directly into your active shell session as environment variables.

Based on your logs, you are targeting us-east-1 (make sure this is the correct default region), so we will set that as the default region. Run the following commands, replacing the placeholder text with your actual permanent keys:

Bash 
export AWS_ACCESS_KEY_ID="<insert_your_permanent_access_key>"
export AWS_SECRET_ACCESS_KEY="<insert_your_permanent_secret_key>"
export AWS_DEFAULT_REGION="<insert_your_default_region>"

4. Run the Authentication Test

Now that the credentials are in the session, run the STS (Security Token Service) caller identity command. This acts as a basic "ping" to AWS authentication:

Bash 
aws sts get-caller-identity

5. Interpret the Results

Success: If the keys are valid permanent keys, AWS will return a JSON block containing your UserId, your AWS Account number, and the Arn (Amazon Resource Name) of the IAM user. It will look like this:
JSON
```
{
    "UserId": "AIDASAMPLEUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/vna-monitoring-user"
}
```
If you see this, the keys are perfectly valid and you can safely paste them into the VNA Admin UI.
Failure (Invalid Token): If you still see an InvalidClientTokenId error, it means the keys you exported are still temporary SSO credentials that require a session token. You will need to generate standard, permanent IAM user keys.
Failure (Signature Does Not Match): This typically means there is a typo in either the Access Key or the Secret Key. Double-check for trailing spaces.

6. (Optional) Run a Permissions Test

Since VNA needs to read your AWS infrastructure, you can also run a quick command to ensure the newly created user has the correct read-only permissions for EC2:

Bash 
aws ec2 describe-instances --max-items 1

If this returns a JSON block with instance data (or an empty list if you have no instances), your permissions are correct. If it returns an AccessDenied error, your AWS Administrator will need to attach the AmazonEC2ReadOnlyAccess policy (or equivalent) to the IAM user.