Skip to content

Real-world integration test: Azure Key Vault #5

Description

@smiggleworth

Why

Every test for internal/azure runs against a hand-written fake (fakeClient) implementing the Client interface. Nothing in this package has ever talked to a real Azure Key Vault. The rollback logic in particular makes non-trivial assumptions about version-listing behavior that deserve a real check.

What to verify against a real Azure Key Vault

Write path (KeyVault.WriteMany)

  • Merge-and-write behavior against a real multi-key secret (ContentType, Tags, SecretAttributes preserved from the existing version) — confirm Key Vault actually returns these fields the way azsecrets.GetSecretResponse is assumed to shape them.
  • First-write-to-a-missing-secret (404 handling via statusCode(err, 404)) creates the secret correctly.

Rollback (KeyVault.Rollback)

  • ListSecretVersions + sort-by-Created-time-then-version — confirm real version metadata is always fully populated (ID, ID.Version(), Attributes.Created). The code deliberately fails closed (InvalidState) on any version missing this data rather than guessing at ordering — verify that's a rare/never case in practice, not something that'll routinely block rollback on real vaults (e.g. after a soft-delete/recover cycle, or a version created through the Azure portal rather than the API).
  • Confirm the "immediately prior version" selected really is the version right before current, not an artifact of how the fake orders its test data.

Reference parsing

  • canonicalVaultHost — confirm real vault hostnames actually match for all four supported clouds (*.vault.azure.net, *.vault.usgovcloudapi.net, *.vault.azure.cn, *.vault.microsoftazure.de), ideally against a real vault in at least the Gov or China cloud if accessible, not just commercial Azure.

Auth

  • azidentity.NewDefaultAzureCredential(nil) resolution against a real managed identity, az login session, and service-principal environment-variable combination.

Scope

Needs a real (disposable) Azure Key Vault and, ideally, access to a non-commercial Azure cloud instance to check the sovereign-cloud hostname patterns — if that's not available, at least confirm commercial Azure end-to-end and flag the others as still-unverified.

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is neededtestingReal-world / integration verification work

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions