Skip to content

[Cosmos] Disable key authentication in AAD live-test lanes #49020

Description

Is your feature request related to a problem? Please describe.

The Cosmos AAD live-test lanes set COSMOS_TEST_DATA_AUTH_MODE=aad, but their provisioned accounts still allow local/key authentication. This means accidental key-authenticated data-plane usage can succeed instead of exposing gaps in AAD coverage.

Simply setting disableLocalAuth today would break the test harness. Shared session setup in tests/conftest.py creates databases and containers with ACCOUNT_KEY, and TestConfig.create_test_clients() plus its async counterpart deliberately create key-authenticated setup clients. The custom AAD role in sdk/cosmos/test-resources.bicep also needs to be reviewed for the database lifecycle operations currently performed through those key clients.

This follow-up was identified while reviewing PR #48459.

Describe the solution you'd like

Make the seven AAD live-test lanes run against provisioned Cosmos accounts with local/key authentication disabled.

  • Audit every test selected by the AAD markers for direct or helper-mediated key authentication.
  • Convert shared database/container setup and cleanup to use AAD or an appropriate ARM control-plane path.
  • Update the custom AAD role with only the additional data actions required for test-owned database lifecycle operations.
  • Add a Bicep parameter for disableLocalAuth and enable it only for AAD matrix configurations, leaving key-auth lanes unchanged.
  • Ensure AAD lanes do not depend on ACCOUNT_KEY after deployment.
  • Add a targeted assertion that key authentication is rejected on the AAD account so regressions are visible.
  • Validate all seven AAD lanes, including long, query, split, multi-region, circuit-breaker, and per-partition automatic-failover coverage.

Describe alternatives you've considered

Leaving local authentication enabled preserves the current harness but cannot detect accidental key usage. Enabling disableLocalAuth immediately without migrating setup would fail during session initialization rather than provide meaningful AAD coverage.

Additional context

PR #48459 intentionally keeps AAD lanes on per-run provisioned accounts because their role assignments target the current test tenant's principal. This issue is separate from moving key-auth lanes to fixed rotation-friendly accounts and should be completed before considering the AAD lanes fully key-independent.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions