Amazon Bedrock Authentication

Amazon Bedrock accepts an API key, AWS access keys, or an IAM role. The Authentication Method field, shown under Custom setup on the AgentQ Settings page once Amazon Bedrock is selected, selects between them, and each reveals only the fields it needs. This page explains what each method expects and what your AWS administrator has to set up. To connect the provider, see Add Integration.

Authentication Methods

IAM Role is the recommended method wherever it is available. Qualytics stores no secret: it authenticates with an AWS IAM identity, so there is nothing to rotate and nothing to leak.

How IAM Role Authentication Works

Qualytics runs with an AWS identity of its own: an IAM role attached to the pods that run the platform. Under IAM Role authentication, the Role ARN field decides what happens next:

• Left blank, Qualytics calls Bedrock directly as the identity it already runs as.
• Filled in, Qualytics assumes that role first and calls Bedrock as the assumed role.

Which one you want follows from where Bedrock lives relative to where Qualytics runs.

Self-hosted, Bedrock in the same AWS account

Leave Role ARN blank. Qualytics is already running inside your account under an identity you control, so all your AWS administrator has to do is grant that identity permission to invoke Bedrock:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
    "Resource": "*"
  }]
}

Narrow Resource to the model or inference-profile ARNs you intend to use if you prefer. There is no second role and no trust policy in this setup.

If Qualytics has no AWS identity yet, choose one of these deployment options:

• EKS Pod Identity (recommended): Enable the EKS Pod Identity Agent, create an IAM role that trusts pods.eks.amazonaws.com, and associate it with the ServiceAccount used by the Qualytics application pods.
• IAM Roles for Service Accounts (IRSA): Create an IAM role that trusts your cluster's OIDC provider and annotate the same ServiceAccount with that role ARN.
• Node instance role: Grant the permissions to the EKS node role. This is the simplest option, but every pod on those nodes receives the same access.

The AWS workload identity setup provides the Helm values and trust-policy examples for the first two options.

Bedrock in a different AWS account

Bedrock has no cross-account invoke: the call has to be made with credentials belonging to the account that has model access. Your AWS administrator creates a role in that account, gives it the policy above, and trusts the identity Qualytics runs as:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "<the identity Qualytics runs as>" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "<your external id>" } }
  }]
}

Enter that role's ARN in Role ARN, and the same value in External ID if you used one.

Managed deployments

This is the cross-account case above: Qualytics runs in a Qualytics AWS account and your Bedrock models are in yours, so a role in your account is the only way in. Role ARN is required. A blank value would select a Qualytics-owned AWS identity, so the configuration is refused when you save it.

Ask your Qualytics account manager for the AWS identity that AgentQ runs as before you start: Qualytics does not display it anywhere, and a save that fails because the role cannot be assumed yet reports only a generic server error (see When Validation Fails). Ask for it by name. It is a separate identity from the base role that datastore connections trust under IAM Role authentication, so do not reuse that ARN. Create the target role with the AgentQ identity as the Principal of its trust policy, enter the role's ARN, and save the configuration. Use the External ID as well: it prevents a role that trusts Qualytics from being assumed on behalf of another customer.

Things Worth Knowing

• Trust the role ARN, not the session ARN. The principal in a trust policy is arn:aws:iam::…:role/name. An arn:aws:sts::…:assumed-role/name/session string identifies one session and will not work.
• Assumed sessions last at most one hour. Qualytics' own identity is already a role, so assuming another one is role chaining, which AWS caps at 60 minutes regardless of the role's MaxSessionDuration. Qualytics refreshes credentials before they expire; there is nothing to configure.
• The External ID only matters across accounts. It protects a role that trusts a third party from being assumed on someone else's behalf. It is accepted but pointless when Qualytics and Bedrock are in the same account.
• Switching to IAM Role clears any stored credential. Moving an existing Bedrock configuration from API Key or AWS Access Keys to IAM Role discards the encrypted secret rather than leaving it in place.
• Configurations saved before this release keep working. A Bedrock integration set up under the earlier Assume IAM Role (cross-account) option now reads IAM Role, with the Role ARN and External ID it already had. It still assumes that role, because its Role ARN is filled in. Nothing has to be reconnected or re-entered.

When Validation Fails

Qualytics tests the provider before saving. When the Bedrock call itself is what fails under IAM Role authentication, the message names the AWS identity the call was made as:

Failed to validate API key for bedrock:… : AccessDeniedException …
  AWS caller identity: arn:aws:sts::123456789012:assumed-role/prod-nodes/i-0abc.
    Grant bedrock:InvokeModel to that identity.

That ARN is the useful part. Give it to your AWS administrator: it is the identity that needs the Bedrock grant. When a Role ARN is set, this message appears only if the role was assumed and the Bedrock call then failed. It names the identity Qualytics runs as and says the configured role must trust it, but at that point the trust already works, and the usual cause is a missing Bedrock permission on the role itself.

If the role cannot be assumed at all, because its trust policy does not allow it yet or the External ID does not match, the configuration is not saved and the form shows a generic server error: Unable to complete your request due to a server error. (Status: 500). That message names neither identity. Check the trust policy's Principal and the External ID against the values you were given, then save again.

A message saying Qualytics could not resolve any AWS credentials means the platform has no AWS identity. On a self-hosted deployment, complete one of the workload-identity options above.

See Also