[BUG] cloud-auth persona-mappings list returns 401 with OAuth

[pedramsafaei]

Describe the bug

pup integrations aws cloud-auth persona-mappings list returns 401 Unauthorized when authenticated with OAuth2.

The OAuth session is valid, and other Datadog APIs, including AWS integration listing, work with the same token.

To Reproduce

1. Authenticate with the elevated scopes accepted by Datadog:

pup auth login --site datadoghq.com \
  --extra-scopes service_account_write,user_access_manage

2. Confirm that OAuth works for another AWS API:

pup cloud aws list --output json

3. Attempt to list WIF persona mappings:

pup integrations aws cloud-auth persona-mappings list \
  --output json

4. Observe 401 Unauthorized.

I also attempted to request the documented WIF RBAC permissions as OAuth scopes:

pup auth login --site datadoghq.com \
  --extra-scopes workload_identity_federation_config_read,workload_identity_federation_config_write

The authorization server rejected both as unrecognized scopes.

Expected behavior

The persona-mapping list command should work with OAuth when the authorizing user has the required WIF permissions.

If this API intentionally does not support OAuth, Pup should fail locally with a clear message that API and application keys are required instead of sending the bearer token and returning a generic 401.

Environment

• OS: Amazon Linux 2, Linux x86_64
• Pup version: pup 1.10.7
• Datadog site: datadoghq.com / US1
• Authentication method: OAuth2

Command output

$ pup integrations aws cloud-auth persona-mappings list --output json

Error: failed to list persona mappings: ResponseError(ResponseContent {
  status: 401,
  content: "{\"errors\":[\"Unauthorized\"]}",
  entity: Some(APIErrorResponse(APIErrorResponse {
    errors: ["Unauthorized"],
    additional_properties: {},
    _unparsed: false
  }))
})

Requesting the WIF permission names as OAuth scopes produces:

OAuth error: invalid_scope: The following scopes are not recognized:
workload_identity_federation_config_read
workload_identity_federation_config_write

Additional context

Datadog's Workload Identity Federation documentation requires the following RBAC permissions:

• workload_identity_federation_config_read
• workload_identity_federation_config_write

The documented API supports persona mappings at:

GET /api/v2/cloud_auth/aws/persona_mapping
POST /api/v2/cloud_auth/aws/persona_mapping

The published examples use API and application keys. Pup nevertheless exposes first-class persona-mapping commands and sends its OAuth bearer token to these routes.

This appears similar to previous Pup OAuth enablement gaps:

• OAuth client missing AWS / GCP cloud-configuration scopes — pup cloud {aws,gcp} list always 401 #437
• OAuth client missing logs-config scopes — pup api v1/logs/config/pipelines always 401 with logs_read_config granted #608
• [BUG] pup dashboards annotations create returns 401 when using OAuth #688

Those issues required server-side route/client enablement and, where applicable, Pup scope changes.

Could Datadog enable OAuth for the cloud-auth persona-mapping routes and expose the WIF read/write permissions as opt-in OAuth scopes? These permissions appear appropriate for --extra-scopes rather than the default scope set.

Use case: customer-run automation needs to create the initial AWS workload identity mapping without requiring long-lived Datadog API and application keys.

[srosenthal-dd]

Fixed in #723; thanks for reporting!