Additional Information
Helpful Tips
The overall process of the AWS Secrets Manager integration is like other PAM integrations, as follows:
-
Tenable One Vulnerability Management or Tenable Security Center pass the policy and credential values down to Tenable Nessus. This includes the AWS region, AWS Access Key ID, AWS Secret Access Key, optional Session Token, and the Credential ID (secret name or ARN).
-
The Tenable Nessus scanner communicates with the AWS Secrets Manager API using AWS Signature Version 4, and the API returns the secret payload containing the username, password, and/or SSH key required for target authentication.
-
The scanner uses these values for target authentication.
Testing Integration Connectivity
To verify that the IAM identity and the secret are reachable from outside Tenable, install the AWS CLI on the same network segment as the Tenable Nessus scanner and run:
aws secretsmanager get-secret-value --region <region> --secret-id <credential-id>
A successful response includes the secret's ARN, Name, VersionId, CreatedDate, and a SecretString field containing the JSON payload that the integration parses. If the AWS CLI command fails for the IAM identity used in the credential, the Tenable integration also fails with an equivalent error code.
The integration calls the same API (secretsmanager.GetSecretValue) as the AWS CLI command above. If the AWS CLI returns the secret successfully but the integration does not, capture the per-integration log (see Debug Log Reporting) and contact Tenable Technical Support.
API Authentication
All API requests are sent over HTTPS to the AWS Secrets Manager regional endpoint, secretsmanager.<region>.amazonaws.com. The integration signs every request using AWS Signature Version 4 (AWS4-HMAC-SHA256).
To ensure successful authentication, verify the following:
-
Region match — the region configured in the credential matches the region the secret was created in.
-
System clock — the scanner's clock is within 15 minutes of the AWS server clock; AWS Signature V4 rejects requests outside that window.
-
Outbound network access — the scanner can reach secretsmanager.<region>.amazonaws.com on TCP port 443.
-
Endpoint TLS — TLS is required; plain HTTP is rejected.
-
Header set — the integration sends Content-Type, Host, X-Amz-Date, X-Amz-Target: secretsmanager.GetSecretValue, an Authorization header with the AWS4-HMAC-SHA256 signature, and X-Amz-Security-Token when a session token is configured.
Example HTTPS request:
curl -s -X POST "https://secretsmanager.us-east-2.amazonaws.com/" \
-H "Content-Type: application/x-amz-json-1.1" \
-H "X-Amz-Date: 20260626T192121Z" \
-H "X-Amz-Security-Token: <redacted>" \
-H "X-Amz-Target: secretsmanager.GetSecretValue" \
-H "Authorization: AWS4-HMAC-SHA256 Credential=<access-key-id>/20260626/us-east-2/secretsmanager/aws4_request, SignedHeaders=content-type;host;x-amz-date;x-amz-security-token;x-amz-target, Signature=<redacted>" \
-d '{"SecretId":"<credential-id>"}'
AWS Secrets Manager Credential Fields, Usage, and Limitations
Required Fields
AWS Region
The AWS region where the secret is stored — for example, us-east-1, us-west-2, or eu-central-1. The integration constructs the API host as secretsmanager.<region>.amazonaws.com and signs requests using this region in the AWS Signature V4 credential scope. The default value is us-east-1; if your secret lives in a different region, you must change this value or AWS will return a ResourceNotFoundException even when the credentials are otherwise valid.
AWS Access Key ID
The IAM access key ID for the identity that reads the secret. This value is sent in the Authorization header as part of the AWS4 credential string and is visible in the debug log.
AWS Secret Access Key
The IAM secret access key paired with the access key ID. The secret access key is used as the seed for the AWS Signature V4 HMAC-SHA256 signing key and is never sent on the wire.
AWS Session Token
Optional. Supply this field when you are using AWS STS temporary credentials (for example, those returned by aws sts assume-role or by an EC2 instance profile). When set, the integration sends the token in the X-Amz-Security-Token header and includes it in the canonical headers used for signing. Leave this field blank when using long-lived IAM user access keys.
Credential ID
The identifier of the secret to read. AWS Secrets Manager accepts either the secret's friendly name (for example, tenable/scan/web-server) or the full ARN (for example, arn:aws:secretsmanager:us-east-1:123456789012:secret:tenable/scan/web-server-AbCd12).
The expected payload of the secret is a JSON object containing one or more of username, password, ssh_key, passphrase, and domain. If the secret is stored as plain text rather than JSON, the entire string is treated as the password and no username, SSH key, passphrase, or domain is extracted.
When the target uses an SSH private key, the key must be embedded in the JSON payload as a single string with line breaks encoded as the \n escape sequence. The simplest reliable approach is to construct the secret using a JSON-aware tool, for example:
json.dumps({"username": "svc", "passphrase": "...", "ssh_key": open("id_rsa").read()})
Then pass the resulting file to:
aws secretsmanager create-secret --secret-string file://secret.json
Pasting raw, unescaped key text into the AWS console Plaintext editor will produce invalid JSON and the integration will fall back to treating the entire payload as a password — SSH authentication will then fail.
Supported SSH private key formats: The integration forwards the ssh_key (or PEM-bearing password) string to the scanner's SSH stack, which accepts RSA, DSA (legacy), ECDSA (nistp256, nistp384, nistp521), and Ed25519 key types. Supported encodings are PEM/PKCS#1, PEM/PKCS#8, and OpenSSH format. PuTTY .ppk keys are not supported — convert them with puttygen before storing them in the secret. Encrypted keys require the matching passphrase to be supplied via the passphrase field of the same secret.
Optional Fields
Username
When set, this value overrides the username field stored in the AWS secret. Use this field when the same secret stores only a password and is reused across multiple targets that each have a different login name.
Domain (Windows only)
When set, this value is used as the Windows or Active Directory domain for SMB authentication. Combined with Fetch Domain, the domain resolution order is: KDC Domain (when Use Kerberos KDC is on) > Domain (this field) > domain field from the AWS secret (when Fetch Domain is on). The first non-empty value in that order is used.
Use Kerberos KDC
Available on Windows and SSH credentials. When enabled, Kerberos authentication is used and additional Key Distribution Center (KDC) fields appear (KDC host, KDC port — default 88, KDC transport — TCP or UDP, and KDC Domain). The integration still fetches the username and password from AWS Secrets Manager, but the scanner uses Kerberos rather than NTLM (or password authentication for SSH) at the target.
Fetch Domain
Available on Windows, SSH, VMware ESX SOAP, and VMware vCenter credentials. Default Off. When set to On, the integration uses the domain field stored in the AWS secret JSON payload as the Windows / AD domain.
Elevate privileges with (SSH only)
Selects the privilege escalation mechanism for SSH credentialed scanning. Supported values are .k5login, Cisco 'enable', dzdo, pbrun, su, su+sudo, sudo, and Nothing (the default). When set to anything other than Nothing, an Escalation Credential ID field appears.
Escalation Credential ID (SSH only)
The ID, name, or ARN of an additional secret containing the password used for privilege escalation (for example, the sudo password or the Cisco enable password). The integration retrieves this secret with a separate GetSecretValue call and uses its password field. If Elevate privileges with is set but Escalation Credential ID is left blank, the integration falls back to the secret named in Credential ID.
Database Port, Database Name, Auth type, Service type, Service (Database only)
Standard database connection options. The default port varies by database type (see the Scan Configuration table). Database Name is required for DB2 and optional elsewhere. Auth type is required for SQL Server (Windows or SQL) and Oracle (SYSDBA, SYSOPER, or NORMAL). Service type and Service are required for Oracle and select between SID and Service Name.
Potential Issues when First Enabling the AWS Secrets Manager Integration
Incorrect AWS region
If the AWS Region field does not match the region the secret was created in, AWS returns ResourceNotFoundException even when the IAM credentials are otherwise valid. This appears in the integration debug log as a failure on GetSecretValue with HTTP 400 and an AWS error code of ResourceNotFoundException. Confirm the secret's region in the AWS console and update the credential.
Missing IAM permission to read the secret
If the IAM identity does not have secretsmanager:GetSecretValue on the secret's ARN, AWS returns AccessDeniedException (HTTP 400). The integration logs the failure and the calling Settings plugin logs Failed to retrieve AWS Secrets Manager PAM <type> credentials. Add the missing permission to the IAM policy attached to the identity, or use a wildcard ARN to grant access to a group of secrets.
Customer-managed KMS key with no kms:Decrypt permission
Secrets encrypted with a customer-managed AWS KMS key require the IAM identity to have kms:Decrypt on that key in addition to secretsmanager:GetSecretValue on the secret. Without it, AWS returns AccessDeniedException referencing the KMS key. Secrets that use the default aws/secretsmanager AWS-managed key do not require an explicit KMS grant.
Expired AWS session token
When the credential uses a session token from AWS STS, the token has a maximum lifetime (15 minutes to 36 hours, depending on how it was issued). After expiration, the API returns ExpiredTokenException. Either issue a longer-lived token or switch to long-lived IAM user access keys. Tenable does not refresh session tokens automatically.
Secret payload missing username, password, or ssh_key
If the secret value is a JSON object that does not contain password or ssh_key, the integration returns NULL_ACCOUNT and logs Password or SSH key missing from the secret. Open the secret in the AWS console and confirm the JSON keys match the integration's expected schema (username / password / ssh_key / passphrase / domain). Plain-text secrets are accepted and treated as a password-only secret.
SSH private key stored without escaped newlines
PEM-encoded SSH private keys are multi-line, but the AWS Secrets Manager SecretString is a single JSON string. Newlines in the key must be encoded as \n inside the JSON value. When the key is pasted into the AWS console Plaintext editor with raw line breaks, the resulting payload is invalid JSON; the integration then falls back to treating the whole SecretString as a password and SSH authentication fails on the target. Construct the secret with a JSON-aware tool, for example:
secret = json.dumps({"username": "svc", "passphrase": "...", "ssh_key": open("id_rsa").read()})
aws secretsmanager create-secret --name tenable/scan/host --secret-string file://secret.json
If you must use the AWS console, paste the key into a JSON value with each line break replaced by \n, for example: {"ssh_key": "-----BEGIN OPENSSH PRIVATE KEY-----\nb3BlbnNza...\n-----END OPENSSH PRIVATE KEY-----\n"}.
Encrypted SSH key without a passphrase field
Encrypted PEM keys require the matching passphrase to be supplied in the passphrase field of the same secret. If the passphrase field is missing or wrong, the SSH stack on the scanner cannot decrypt the key and the SSH credentialed check logs a key-decoding or authentication failure. Add the passphrase key to the secret payload alongside ssh_key (or use an unencrypted key).
System clock skew (Signature V4)
AWS Signature Version 4 rejects requests where the X-Amz-Date timestamp is more than 15 minutes from the AWS server clock. If the Tenable Nessus scanner's clock has drifted, AWS returns SignatureDoesNotMatch or RequestTimeTooSkewed. Configure NTP on the scanner host.