So if we combine our two previous posts Azure Blob Container override delete lock and How do I know the difference between control and data plane then something seems off.
- We get a warning on a Blob Storage Container for a resource lock preventing deletion.
- We learned that a Blob Storage Container lives in the data plane, which is not controlled by resource locks.
A bit of history
Initially, the separation of control and data plane was very clear for storage accounts. Access to blobs or containers was given through container accessibility (Public, Private), SAS tokens or ACLs.
Over time, new features were added and now we can add Azure RBAC role assignments and policies, which both are typically control plane activities.
Proxy resources
Microsoft explicitly defines a class of ARM resources whose real state lives outside ARM, called proxy resources. These do not have some metadata like location and tags properties.
It’s even defined that all resources in ARM (Azure Resource Manager, which is used for managing the control plane) without a location property required is a proxy resource, while those with are tracked resources.
So Storage Account Containers:
- Exist in ARM as proxy
- Are child resources on the storage account
- Support management metadata like immutability policy, public access, encryption scopres, …
However, the ARM part does not allow for blob manipulations as this are clear data plane operations.
So in short, the container delete is executed on the data plane, after the change of the management structure (child of parent account) is authorized on the control plane. And for that reason resource locks work on containers. It also explains why overriding the lock is easier on containers than on actual tracked resources.