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.

Activity

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

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