Tutorial / Cram Notes
Stored access policies provide an additional level of control over Shared Access Signatures (SAS) on Azure Storage services including Blob Containers, File Shares, Queues, and Tables. They provide a way to manage constraints for one or more SAS tokens without having to regenerate them.
How to Configure Stored Access Policies
Here’s how you can configure stored access policies on Azure Blob Containers, although similar steps apply to File Shares, Queues, and Tables:
1. Create a Stored Access Policy:
- Navigate to the Azure Portal and go to your storage account.
- In the Blob service section, select the container for which you want to set a stored access policy.
- Click on the ‘Access Policy’ under the ‘Settings’ section.
- Under Shared Access Policies, click the ‘Add policy’ button.
- Give your access policy a name, which must be unique within the container.
- Set the start time, expiry time, and permissions for the access policy. Permissions can include Read, Write, Delete, List, Add, Create, Update, and Process.
- Click OK to save the new policy.
2. Create a Shared Access Signature (SAS) with a Stored Access Policy:
- On the container’s Access policy page, click ‘Generate SAS’.
- Select the stored access policy you’ve just created from the dropdown menu.
- Configure any additional settings for the SAS if needed, such as Allowed IP addresses or Allowed Protocols.
- Click ‘Generate SAS token and URL’.
- The SAS token will now include the identifier of the stored access policy.
3. Modify a Stored Access Policy:
Modifying a stored access policy affects all SAS tokens associated with it.
- Navigate to the stored access policy that you wish to change, and click on it.
- You can change the start time, expiry time, and permissions.
- Click OK to save the changes.
4. Revoke a Stored Access Policy:
- To immediately revoke all associated SAS tokens:
- Simply delete the stored access policy. Click on the ellipsis (…) next to the policy and select ‘Delete’.
- Confirm the deletion, and all SAS tokens linked to that policy will become invalid.
Example: A Practical Use Case
Suppose you have a Blob Container called ‘documents’ and you want to provide a contractor read-only access for the next month. You would:
- Create a stored access policy on the ‘documents’ container with read permissions and an expiry time set to one month from the current date.
- Generate a SAS token tied to this stored access policy.
- Provide this SAS token to the contractor.
Now, if for any reason you need to revoke that access earlier than planned, you can modify the stored access policy to have an earlier expiry date or delete it entirely to revoke access immediately.
Comparison Table: SAS vs. Stored Access Policies
| Feature | SAS Token | Stored Access Policy |
|---|---|---|
| Scope | Blob/File/Queue/Table | Container/File Share/Queue/Table |
| Granularity | Single entity | Multiple entities |
| Lifetime | When created | Defined by the policy |
| Revocation | Must regenerate SAS | Delete/modify the policy |
| Supports IP restrictions? | Yes | No (but SAS using policy can) |
| Supports Protocol restrictions? | Yes | No (but SAS using policy can) |
| Passes on Policy changes? | No (unless recreated) | Yes, immediately affects associated SAS |
Notes:
- Always practice the Principle of Least Privilege (PoLP) when setting permissions.
- Be careful with setting long expiration times for stored access policies, as it could pose a security risk.
- Regularly audit your stored access policies and associated SAS tokens to ensure they are up to date and adhere to your security requirements.
Conclusion
In conclusion, stored access policies are a powerful feature for managing shared access to your storage resources more effectively. By understanding and utilizing this feature, as demonstrated, you can streamline access control and manage security risks across your Azure storage accounts.
Practice Test with Explanation
True or False: A stored access policy provides additional control over service-level SAS via the Azure portal.
- (A) True
- (B) False
Answer: A) True
Explanation: A stored access policy provides additional control over service-level SAS, which includes the ability to manage constraints for a SAS without regenerating the SAS itself.
Which of the following is NOT an attribute of a stored access policy?
- (A) Start Time
- (B) Expiry Time
- (C) Permissions
- (D) Access Tier
Answer: D) Access Tier
Explanation: Access Tier is not an attribute of a stored access policy. A stored access policy’s attributes include Start Time, Expiry Time, and Permissions.
True or False: Once set, the properties of a stored access policy cannot be modified.
- (A) True
- (B) False
Answer: B) False
Explanation: The properties of an existing stored access policy can be modified. Changing a stored access policy automatically affects all associated SAS tokens.
How many stored access policies can you have per container, queue, table, or file share in Azure Storage?
- (A) 5
- (B) 10
- (C) 50
- (D) 100
Answer: A) 5
Explanation: You can have up to 5 stored access policies per container, queue, table, or file share in Azure Storage.
A stored access policy is required to create a service-level SAS.
- (A) True
- (B) False
Answer: B) False
Explanation: A stored access policy is not required to create a service-level SAS, but it allows you to manage a group of similar SAS tokens and provides additional control.
True or False: A stored access policy can be used to extend the expiry time of a service SAS that has been already issued.
- (A) True
- (B) False
Answer: A) True
Explanation: A stored access policy can be used to extend the expiry time of a service SAS or to change its permissions, without reissuing the SAS.
You can create a shared access signature (SAS) without associating it to a stored access policy.
- (A) True
- (B) False
Answer: A) True
Explanation: A shared access signature (SAS) can be created without being associated with a stored access policy. This type of SAS is called an ad hoc SAS.
True or False: When a stored access policy is deleted, any associated SAS tokens continue to work until they naturally expire.
- (A) True
- (B) False
Answer: B) False
Explanation: Once a stored access policy is deleted, any associated SAS tokens immediately become invalid, regardless of their set expiry time.
What does a stored access policy’s permission attribute specify?
- (A) Network rules
- (B) Storage account type
- (C) Set of permissions for the SAS
- (D) Geographic location constraints
Answer: C) Set of permissions for the SAS
Explanation: The permission attribute of a stored access policy specifies the set of permissions that the SAS will have.
True or False: Stored access policies apply to both Account SAS and Service SAS.
- (A) True
- (B) False
Answer: B) False
Explanation: Stored access policies are only available for Service SAS, not for Account SAS.
Which of the following types of Azure Storage supports stored access policies?
- (A) Queues
- (B) Tables
- (C) Blobs
- (D) All of the above
Answer: D) All of the above
Explanation: Stored access policies are supported by Azure Storage services like Blob containers, Queue message containers, and Table message containers.
When defining a stored access policy, which of the following must be specified?
- (A) An identifier
- (B) The Storage account key
- (C) A CORS rule
- (D) Virtual network rules
Answer: A) An identifier
Explanation: When defining a stored access policy, an identifier must be assigned to the policy. This identifier is used to associate the access policy with a SAS.
Thank you for the insightful post on configuring stored access policies! It really helped me understand the concept better.
Great step-by-step guide, but can someone explain the difference between setting permissions at the blob level versus the container level?
One thing to watch out for is the expiration date on a stored access policy. If it passes, your shared access signatures will no longer work.
I’m curious how a shared access signature (SAS) token works in conjunction with stored access policies?
Does anyone know if it’s possible to update a stored access policy without downtime?
Great article! Could someone provide a real-world example where stored access policies are especially useful?
Just curious, what happens to existing SAS tokens if you delete a stored access policy they’re based on?
To anyone using PowerShell for this, remember to use `New-AzStorageContainerSASToken` with the `Policy` parameter to link to your stored access policy.