Azure Storage ACL
You set up an azure storage acl to grant read, write, and run rights on files. This setup requires a hierarchical namespace on your storage account. Teams often rely on broad account roles first because folder rules take time to plan. Broad roles let users read every folder in a container instead of one path. When an app or engineer has wide rights, one bad script can delete vital files. Using file and folder rules limits each user to the exact path they need. How an azure storage acl works in
Azure RBAC: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an azure storage acl to grant read, write, and run rights on files. This setup requires a hierarchical namespace on your storage account. Teams often rely on broad account roles first because folder rules take time to plan. Broad roles let users read every folder in a container instead of one path. When an app or engineer has wide rights, one bad script can delete vital files. Using file and folder rules limits each user to the exact path they need.
How an azure storage acl works in practice
An azure storage acl applies POSIX style permissions to directories and individual files. Each rule links a security principal from your directory to a specific storage path. You can assign read, write, and execute bits to the owning user and group. You can also add named users, groups, or service principals to the rule list. Execute rights on a parent folder are vital for path traversal. Without execute rights on parent folders, a user cannot reach a child file. This holds true even when the user has read rights on the child file itself.
Storage accounts support two types of rules on every directory. Access rules control rights for the current folder or file right now. Default rules act as a template for new items created inside that folder later. When a user writes a new file, the parent default rule copies down to it. Updating a default rule on a folder does not change existing child files. You must run a recursive update to push new rules to old files. Teams assign group IDs instead of user IDs to avoid slow recursive updates.
Combining role assignments with file level rules
File rules do not work in isolation inside your cloud account. The platform checks role assignments and file rules together during every storage request. Role assignments work at the subscription, resource group, or storage account level. File rules work inside the container on folders and individual data objects. When a user sends a read request, the system checks the broad role first. If the role grants rights, the user gets in right away. If the role does not grant rights, the system checks the folder rule next.
Explicit deny rules in role assignments always override allow rules on folders and files. Because broad roles take precedence, you should remove wide data roles from most users. Give users a minimal role or no data role at the account scope. Then grant exact folder rights using directory groups on the paths they need. This pattern keeps users out of sibling folders that hold sensitive company records.
Azure RBAC: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What folder rules solve and what remains exposed
Folder rules solve path isolation across shared data lakes and storage containers. One team can read finance files while another team reads marketing files in peace. You do not need to create separate storage accounts for every small project team. Group based default rules also keep permissions tidy as new files arrive each day.
Still, static folder rules only decide who can open a path at log in. They do not inspect what commands or queries do while a session runs. Once an engineer or service has write rights, they can drop an entire folder. Static rules also stay active all day and night until an admin removes them. If a developer laptop gets stolen, the attacker inherits those open folder rights. Also, storage rules cannot mask sensitive fields like emails or phone numbers inside files. Anyone with read rights on a file receives the full unmasked content.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why can a user still read files after I remove their folder rule?
The user likely holds a broad data role at the storage account or subscription level. Cloud role assignments evaluate first and grant access even when folder rules are empty.
Do default rules update files that already exist in a folder?
No, default rules only apply to new files and folders created after you set the rule. To change existing items, you must apply access rules across the folder tree.
Why does a user get an error when reading a deep file?
The user needs execute permissions on the root container and every parent directory in the path. Without execute bits on parent folders, the system blocks path traversal to the file.