Key Vault live tests do not make use of AZURE_AUTHORITY_HOST

[danieljurek]

When running tests with a custom AZURE_AUTHORITY_HOST environment variable set many tests fail with error:

Exception: Preparer failure when creating resource KeyVaultPreparer for test test_example_keys_recover (test_samples_keys_async.TestExamplesKeyVault): , AdalError: Get Token request returned http error: 400 and server response: {"error":"invalid_request","error_description":"AADSTS900382: Confidential Client is not supported in Cross Cloud request.\r\nTrace ID: a187be58-eef5-440b-83e4-ebbf32faad00\r\nCorrelation ID: 9c512854-1e95-4fb4-b835-61eece4b285c\r\nTimestamp: 2020-04-28 06:00:26Z","error_codes":[900382],"timestamp":"2020-04-28 06:00:26Z","trace_id":"a187be58-eef5-440b-83e4-ebbf32faad00","correlation_id":"9c512854-1e95-4fb4-b835-61eece4b285c"}

(source)

This may have something to do with how the preparer uses EnvironmentCredential and EnvironmentCredential doesn't directly reference AZURE_AUTHORITY_HOST in an obvious way

[chlowell]

The right thing should happen here re the authority, given the code in master. It's certainly not obvious but in this case the client responsible for sending requests to AAD will consume AZURE_AUTHORITY_HOST (via get_default_authority) when no authority is otherwise specified.

[jongio]

@chlowell - Are you saying there is a bug in the test or in the lib code?

[chlowell]

I'm saying the preparer uses EnvironmentCredential correctly and that credential doesn't reference AZURE_AUTHORITY_HOST because that variable is consumed elsewhere.

Actually it appears the failure here occurs when creating a Key Vault, so I'd guess the management library's credential is misconfigured (in which case EnvironmentCredential doesn't enter into it).

[jongio]

@danieljurek - What part of the test is failing? I'm not seeing a KV being created in the test it self.

My local EnvCred tests work against other clouds - so I'm guessing this is something to do with the test code.

[chlowell]

The Key Vault is created by KeyVaultPreparer, one instance for each test case it decorates (almost all of them). I'm thinking the problem here is the preparer's management client not getting the right authority. I don't know how to configure a track 1 credential's authority or where that's done in CI runs, but it isn't in the Key Vault test code--I'd start with the preparer's base class, AzureMgmtPreparer in devtools_testutils.

This begins to look like a project for me, if no one else is already investigating. When do we hope to have these tests passing?

[mccoyp]

Has there been any update to this issue?

[chlowell]

A few things have changed. azure-mgmt-keyvault now has a track 2 version, so the management client should (certainly could) use an azure-identity credential which observes $AZURE_AUTHORITY_HOST. But we're now replacing KeyVaultPreparer with a pipeline job/script that creates vaults. Upshot is, this particular failure may not occur anymore but the scenario now depends on configuring that job/script. @danieljurek, are you still working on sovereign cloud testing?

[danieljurek]

Hey @chlowell and @mccoyp, questions about live testing configuration and sovereign cloud testing should go to @benbp going forward. Thanks!

[mccoyp]

KeyVaultPreparer is no longer in use and sovereign cloud testing for KV is tracked by a new issue (#20775), so I'll close this issue.