Existing issues

• I have searched the existing issues.

Affected area

Auth

Problem to solve

Since v2.117, config diff and config push read the remote config through a single endpoint, GET /v2/projects/{ref}/config. Its x-fga-permissions in the bundled OpenAPI spec require all of these at once:

database_config_read, database_read, database_ssl_config_read, database_network_restrictions_read, auth_config_read, data_api_config_read, realtime_config_read, storage_config_read

Neither command can be limited to the sections a project actually manages (only --project-ref and --exit-code exist). A scoped PAT that worked with v2.115 for config push (Storage Config read-write; Data API Config, Database Config, API Keys, API Key Secrets, Add-ons read) now fails with:

Access denied for project <ref>: your account does not have permission to view its configuration.

The problematic one is database_read: it also grants POST /v1/projects/{ref}/database/query/read-only, so a CI token that only pushes [storage] must now be able to read every row in the production database.

Proposed solution

Any of these would restore a least-privilege setup:

• Let config diff / config push read only the sections config.toml declares (e.g. via the existing per-section v1 endpoints), so a token needs read access only to those.
• Or add a flag to limit them to named sections, e.g. --only storage.
• Or have the v2 endpoint return the blocks the token may read and omit the rest. The push already handles a missing block ("not returned" / unavailable), so the CLI would only need to stop treating a partial read as a 403.

Alternatives considered

• Pinning the CLI to v2.116.0 keeps the old per-section endpoints, but loses config diff and later fixes.
• Calling PATCH /v1/projects/{ref}/config/storage directly works with a storage-only token, but duplicates what config.toml + config push already do.
• Granting database_read to the CI token: works, but gives a storage job read access to all data.

Additional context

No response