Storage access keys and SAS tokens in Azure - Commands & Configuration

Introduction

Storage access keys and SAS tokens control who can access your Azure storage and what they can do. Access keys give full control, while SAS tokens allow limited, time-bound access to specific resources.

When you want to give an application full access to your storage account for management tasks.

When you need to share a file or container with someone temporarily without exposing your full storage account.

When you want to restrict access to only read or write operations on a specific blob or file.

When you want to limit access to storage resources by time and permissions for security.

When you want to rotate keys regularly to keep your storage account secure.

Commands

This command lists the access keys for the specified storage account. Access keys provide full control over the storage account.

Terminal

az storage account keys list --account-name mystorageaccount --resource-group myresourcegroup

Expected Output

[

  {

    "keyName": "key1",

    "permissions": "FULL",

    "value": "abcd1234efgh5678ijkl9012mnop3456qrst7890uvwx1234yzab5678cdef9012"

  },

  {

    "keyName": "key2",

    "permissions": "FULL",

    "value": "1234abcd5678efgh9012ijkl3456mnop7890qrst1234uvwx5678yzab9012cdef"

  }

]

→

--account-name - Specifies the name of the storage account.

→

--resource-group - Specifies the resource group of the storage account.

This command generates a SAS token for the container 'mycontainer' with read, write, and list permissions that expires at the end of 2024. The token only works over HTTPS for security.

Terminal

az storage container generate-sas --account-name mystorageaccount --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --https-only

Expected Output

sv=2023-01-01&ss=b&srt=sco&sp=rwl&se=2024-12-31T23%3A59%3A00Z&spr=https&sig=abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890

→

--permissions - Sets allowed actions: r=read, w=write, l=list.

→

--expiry - Sets when the SAS token expires.

→

--https-only - Restricts access to HTTPS requests only.

This command uploads a file named example.txt to the container using the SAS token for authentication, demonstrating how to use SAS tokens for limited access.

Terminal

az storage blob upload --account-name mystorageaccount --container-name mycontainer --name example.txt --file ./example.txt --sas-token "sv=2023-01-01&ss=b&srt=sco&sp=rwl&se=2024-12-31T23%3A59%3A00Z&spr=https&sig=abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890"

Expected Output

Uploading ./example.txt to blob example.txt

Upload succeeded

→

--sas-token - Uses the SAS token for authentication instead of access keys.

This command regenerates the primary access key for the storage account to improve security by rotating keys.

Terminal

az storage account keys renew --account-name mystorageaccount --resource-group myresourcegroup --key primary

Expected Output

No output (command runs silently)

→

--key - Specifies which key to regenerate: primary or secondary.

Key Concept

If you remember nothing else from this pattern, remember: access keys give full control, but SAS tokens let you share limited, time-bound access safely.

Common Mistakes

Using access keys in client apps or sharing them publicly.

Access keys provide full control and exposing them risks your entire storage account.

Use SAS tokens to grant limited, temporary access instead of sharing access keys.

Generating SAS tokens without setting an expiry time.

Tokens without expiry can be used forever, increasing security risks.

Always set a reasonable expiry time when creating SAS tokens.

Not restricting SAS tokens to HTTPS only.

Without HTTPS restriction, tokens can be intercepted over insecure connections.

Use the --https-only flag to ensure tokens work only over secure connections.

Summary

List storage account access keys to see full control credentials.

Generate SAS tokens to share limited, time-bound access to storage resources.

Use SAS tokens for operations like uploading blobs without exposing full access keys.

Rotate access keys regularly to keep storage account secure.

Practice

1. What is the main difference between a storage access key and a SAS token in Azure Storage?

easy

A. SAS tokens provide full access; storage access keys provide limited access.

B. Both provide full access but SAS tokens expire faster.

C. Storage access keys provide full access; SAS tokens provide limited, temporary access.

D. Storage access keys are only for blobs; SAS tokens are for all storage types.

Solution

1. Step 1: Understand storage access keys

   Storage access keys give full control over the entire storage account without restrictions.

2. Step 2: Understand SAS tokens

   SAS tokens grant limited, time-bound access to specific resources or actions within the storage account.

3. Final Answer:

   Storage access keys provide full access; SAS tokens provide limited, temporary access. -> Option C

4. Quick Check:

   Access scope = Full vs Limited [OK]

Hint: Full control = access keys; limited control = SAS tokens [OK]

Common Mistakes:

• Confusing SAS tokens as full access keys
• Thinking SAS tokens never expire
• Assuming access keys are resource-specific

2. Which of the following is the correct way to generate a SAS token for a blob container using Azure CLI?

easy

A. az storage blob generate-sas --container-name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage

B. az storage container generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage

C. az storage account generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z

D. az storage generate-sas --container mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z

Solution

1. Step 1: Identify the correct Azure CLI command for container SAS

   The command to generate a SAS token for a container is az storage container generate-sas.

2. Step 2: Check parameters

   az storage container generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage correctly uses container name, permissions, expiry, and account name parameters.

3. Final Answer:

   az storage container generate-sas --name mycontainer --permissions rwl --expiry 2024-12-31T23:59:00Z --account-name mystorage -> Option B

4. Quick Check:

   Correct CLI command and parameters [OK]

Hint: Use 'container generate-sas' for containers, not 'blob generate-sas' [OK]

Common Mistakes:

• Using 'az storage blob generate-sas' for containers
• Omitting required parameters like --account-name
• Using incorrect command syntax

3. Given this SAS token snippet for a blob: ?sv=2023-01-01&ss=b&srt=sco&sp=rl&se=2024-07-01T00:00:00Z&st=2024-06-01T00:00:00Z&spr=https&sig=abc123, what permissions does it grant?

medium

A. Read and List permissions on blob service

B. Read and Write permissions on blob service

C. Full control on storage account

D. Only write permission on blob service

Solution

1. Step 1: Decode the SAS token parameters

   sp=rl means permissions are Read (r) and List (l).

2. Step 2: Understand service and resource types

   ss=b means the service is Blob storage.

3. Final Answer:

   Read and List permissions on blob service -> Option A

4. Quick Check:

   sp=rl means Read+List [OK]

Hint: Check 'sp' parameter for permissions letters [OK]

Common Mistakes:

• Confusing 'rl' with read-write
• Assuming full control from SAS token
• Ignoring service type 'ss' parameter

4. You created a SAS token with --permissions rwd but users report they cannot delete blobs. What is the likely cause?

medium

A. The SAS token lacks the 'Delete' permission 'x'.

B. The SAS token expired before use.

C. The storage account keys were regenerated.

D. The SAS token was generated for the wrong resource type.

Solution

1. Step 1: Understand permissions for delete

   Delete permission is represented by 'd', so 'rwd' includes delete.

2. Step 2: Check resource type relevance

   If the SAS token is generated for a container but used on blobs, or vice versa, permissions may not apply correctly.

3. Final Answer:

   The SAS token was generated for the wrong resource type. -> Option D

4. Quick Check:

   Permissions + resource type must match [OK]

Hint: Match SAS token resource type with intended use [OK]

Common Mistakes:

• Assuming 'x' is delete permission
• Ignoring resource type mismatch
• Not checking token expiry

5. You want to allow a third-party app to upload files to a specific blob container for 2 hours without exposing your storage account keys. Which approach is best?

hard

A. Generate a SAS token scoped to the container with write permission and 2-hour expiry.

B. Create a new storage account for the app.

C. Share the storage account access keys with the app.

D. Use a SAS token with full permissions and no expiry.

Solution

1. Step 1: Avoid sharing storage account keys

   Sharing keys gives full control and is insecure for third parties.

2. Step 2: Use SAS token with limited scope and expiry

   Generating a SAS token scoped to the container with write permission and a 2-hour expiry limits access and duration.

3. Step 3: Evaluate other options

   Creating a new storage account is unnecessary overhead; SAS token with full permissions and no expiry is insecure.

4. Final Answer:

   Generate a SAS token scoped to the container with write permission and 2-hour expiry. -> Option A

5. Quick Check:

   Limited scope + expiry = SAS token best practice [OK]

Hint: Use SAS tokens for limited, timed access, not keys [OK]

Common Mistakes:

• Sharing full access keys with third parties
• Using SAS tokens without expiry
• Creating unnecessary storage accounts