Quartz 5

Lab: Storage delegated access and key rotation

Properties1
tagslab, az-104, storage, sas, access-keys

4 min read

Lab: Storage delegated access and key rotation

Outcome

Grant a client the smallest practical Blob permission, prove that a stored access policy revokes a service SAS, and rotate an account key without confusing account-key SAS with a user-delegation SAS.

Before you begin

Use a disposable general-purpose v2 storage account, a private container named training, and a harmless blob such as readme.txt. Keep generated SAS URIs out of shell history, screenshots, repositories, and chat. Use the portal if your training account cannot create a user-delegation SAS.

Do: least-privilege service SAS

  1. In Storage account > Data storage > Containers, create training with private access and upload readme.txt.
  2. Generate a service SAS for that container with only Read and List permissions, a short expiry, HTTPS only, and, if your training workstation has a stable public IP, that IP range. Open the blob URI in a private browser window and record the successful read.
  3. Try to upload blocked.txt with that URI or with a client configured with the same SAS. The request must fail because the SAS has no Write permission. Generate a separate short-lived Write SAS only if the exercise needs an upload; do not broaden the original token.

Do: stored access policy revocation

  1. Create a stored access policy on training with Read and List permissions and a short, recorded expiry. Create a service SAS associated with that policy, rather than copying permissions and expiry into an ad hoc SAS.
  2. Verify that the policy-backed URI lists or reads the training blob.
  3. Change the policy to remove Read permission, or delete the policy. Retry the same URI and record the authorization failure. Restore the policy only long enough to show that a newly generated policy-backed URI works, then remove it.

Do: key rotation without a false rule

  1. Create a throwaway client configuration that reads readme.txt through a connection string using key1. Record a successful request without saving the secret in your notes.
  2. Regenerate key1 in Access keys. The old connection string and any service/account SAS signed with key1 should fail; update the client configuration with the new key1 and verify recovery. Rotate the unused key only after every client has moved off it.
  3. If permitted, generate a user-delegation SAS using an Entra principal that has the required data role and generateUserDelegationKey action. Record its signing type. Do not use stored access policies with it: user-delegation and account SAS are ad hoc only. Account-key rotation does not revoke a user-delegation SAS; revoking its user-delegation key is the direct emergency action.

Verify

Capture the service SAS resource, permissions, expiry, protocol, and optional IP restriction; the missing-Write failure; the policy-backed SAS before and after policy change; the old-key client failure and new-key recovery; and the signing type of every SAS. You should now understand: a SAS delegates only the rights and time encoded in it; a stored policy governs service SAS; an account key and an Entra user-delegation key are different signing roots.

Break and fix

  1. Give a test SAS a past expiry or omit List, then diagnose the resulting 403 by inspecting its time and sp claims.
  2. Delete the stored policy and attempt the old service SAS. Fix only by restoring a suitable policy or issuing a new least-privilege SAS; do not rotate both account keys as the first response.
  3. Rotate the active key before updating the throwaway client. Diagnose the failed authentication, update its secret from the newly generated key, and verify recovery.

Scenario practice

  1. Configure: A browser must download one blob for 15 minutes. Choose a service or user-delegation SAS, resource, permissions, expiry, protocol, and distribution method.
  2. Diagnose: A policy-backed SAS returned 403 immediately after the policy changed. Which policy, token type, and propagation evidence do you inspect?
  3. Distinguish: Contrast revoking a service SAS through its stored policy, invalidating a SAS signed with a rotated account key, and revoking a user-delegation SAS.

Clean up

Delete every stored access policy, temporary SAS-bearing client configuration, test blob, container, and disposable resource group. Regenerate a key only when no real client uses it; do not rotate production keys for a lab.

Sources and re-audit

Re-audit when SAS authorization, revocation, or CLI/portal flows change.

sas-token · stored-access-policy · storage-access-keys · rbac · All labs

Graph View

Backlinks