OAuth client missing AWS / GCP cloud-configuration scopes — `pup cloud {aws,gcp} list` always 401

[luphaz]

Is your feature request related to a problem?

pup cloud azure list works end-to-end, but the AWS and GCP equivalents always return 401 Unauthorized — even on a freshly re-authenticated session that already carries every default scope (pup auth login without --scopes and --read-only, including the generic manage_integrations).

Root cause: pup's OAuth client does not register aws_configuration_read or gcp_configuration_read as known scopes. Passing them via --scopes is silently dropped:

⚠️  Unknown scope ignored: aws_configuration_read
⚠️  Unknown scope ignored: gcp_configuration_read

The Datadog API does expose AWS and GCP cloud-integration listing endpoints; they are just not reachable via pup today, while the Azure equivalent is. This asymmetry forces a fallback to API + App key auth (DD_API_KEY / DD_APP_KEY) for AWS / GCP only, which defeats the OAuth session model that pup otherwise provides.

Repro

$ pup --version
pup 0.54.1

$ pup auth login   # standard interactive flow, defaults
$ pup auth status | jq '.scopes | length'
83

$ pup cloud azure list --output json | jq '.status'
"success"

$ pup cloud aws list
Error: failed to list AWS accounts: ResponseError(ResponseContent { status: 401, content: "{\"errors\":[\"Unauthorized\"]}", ... })

$ pup cloud gcp list
Error: failed to list GCP integrations: ResponseError(ResponseContent { status: 401, content: "{\"errors\":[\"Unauthorized\"]}", ... })

A session with manage_integrations granted (verified in pup auth status JSON output) still gets 401 from pup cloud aws list, so the existing generic integration scopes do not cover the AWS / GCP cloud-config listing endpoints.

Describe the solution you'd like

Register AWS and GCP cloud-configuration read scopes in pup's OAuth client manifest, alongside the existing azure_configuration_read, so they can be requested at login (either as part of the default profile or via --scopes).

Cloud-related scopes pup currently knows (extracted from pup auth status JSON):

Scope	Known to pup?
azure_configuration_read	✅
oci_configuration_read / _edit / _manage	✅
cloud_cost_management_read / _write	✅
integrations_read, manage_integrations	✅ (generic, do not satisfy AWS / GCP listing)
aws_configuration_read	❌ Unknown scope ignored
gcp_configuration_read	❌ Unknown scope ignored

The exact scope name is up to you — aws_configuration_read / gcp_configuration_read was a guess by analogy with the existing azure_configuration_read. Whichever names the Datadog OAuth provider exposes for the AWS and GCP cloud-integration listing endpoints would be ideal.

Describe alternatives you've considered

• API + App key auth (DD_API_KEY + DD_APP_KEY): bypasses the OAuth scope mechanism but needs one key pair as a secret, which defeats the OAuth session model pup is built around.
• --scopes aws_configuration_read,gcp_configuration_read: silently dropped as "Unknown scope ignored", session ends up with the same scope set as before.
• Re-using existing scopes (manage_integrations, integrations_read): verified empirically — granted in the session, but the AWS / GCP cloud-config listing endpoint still returns 401.

Additional context

The asymmetry between cloud providers shows up on any workflow that needs to audit cloud integrations programmatically: Azure surfaces every (tenant, App Registration) pair via pup cloud azure list, but AWS and GCP both return 401 on the same flow regardless of the user's underlying RBAC, even with all default scopes granted.

Adding the scopes to pup's default profile (alongside azure_configuration_read) would mean a single pup auth login re-run unlocks parity. If you prefer to keep them opt-in, even surfacing them so --scopes aws_configuration_read,gcp_configuration_read is no longer dropped as "Unknown scope" would be sufficient — operators can then opt in explicitly.

Happy to test pre-release builds or provide more diagnostics.

Proposed command syntax (if applicable)

No new commands. Existing commands gain working coverage:

pup cloud aws list --output json
pup cloud gcp list --output json

And the login flow can request the new scopes when needed:

pup auth login --scopes aws_configuration_read,gcp_configuration_read,...

[srosenthal-dd]

I'm working on this now! We should be able to get AWS & GCP integrations working with pup+OAuth without much effort. Will report back.

[srosenthal-dd]

This should be fixed now as of https://github.com/datadog-labs/pup/releases/tag/v0.56.3

Note: you have to re-run pup auth login to get the updated scopes