I create Azure storage account, and I have ensured following i have such permissions:
Contributor
Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.
Subscription (Inherited)
--
Storage Blob Data Contributor
Allows for read, write and delete access to Azure Storage blob containers and data
Subscription (Inherited)
--
Storage Blob Data Owner
Allows for full access to Azure Storage blob containers and data, including assigning POSIX access control.
Subscription (Inherited)
--
Storage Blob Data Reader
Allows for read access to Azure Storage blob containers and data
Subscription (Inherited)
--
Then I go to App Registrations, and registered. I use Application (client) ID and also generated Client Secret
but still get:
azure.core.exceptions.HttpResponseError: This request is not authorized to perform this operation using this permission.
ErrorCode:AuthorizationPermissionMismatch
Error:None
To resolve the error, make sure to grant roles to service principal (Your Azure AD app) along with your user account like shown in the below screenshot:
Go to Azure Portal -> Storage Accounts -> Your Storage Account -> Access Control (IAM) -> Add role assignment
Note: Make sure to add Storage Blob Data Contributor role to your service principal (Azure AD App).
Now you have the permission to access the Azure Blob Storage and can connect to it without any permission issues.
Related
Added a policy in my test subscription and it works as expected.
The same policy at my PROD sub work does not do anything, it should move blobs to the cool access tier from hot.
On my test sub I have owner rights and storage blob data contributor rights.
On my PROD sub I have storage account contributor and storage blob data owner, should I also add storage blob data contributor rights?. Wouldn't that be included in storage account contributor?
In order to work with Azure Storage Account Life Cycle Management policies, you need role that includes Microsoft.Storage/storageAccounts/managementPolicies/write permission.
The valid roles that allow you to work with Life Cycle Management policies are:
Owner - It grants you full access to manage all resources along with assigning roles.
Contributor - It won't allow you to assign roles but grants full access to manage all resources.
Storage Account Contributor - It grants you full access to manage storage accounts(only).
As your Test subscription has Owner rights, it allowed you to manage Life Cycle Management policies.
To confirm this, click on the role and check for storage management policies:
There is no need to assign Storage Blob Data Contributor role to Prod subscription as it already has Storage Account Contributor role that includes below actions:
I tried to reproduce the same in my environment by assigning Storage Account Contributor role and got below results.
I created a Life Cycle Management policy to move blobs to the cool access tier from hot tier like below:
Go to Azure Portal -> Storage Accounts -> Your account -> Lifecycle management -> Add a role
When I checked the blobs, they are still in Hot access tier like below:
As I created the policy recently, it may take upto 48 hrs to be effective as mentioned below:
If that's your case, please wait for intended time period and check after a couple of days.
Blobs moved to cool access tier from hot when I checked after a few days like below:
UPDATE:
Please check the below note from this Microsoft Doc that confirms management policies will be blocked if firewall rules are enabled for your storage account.
You need to select exception as below that allows access to trusted Azure services:
References:
Grant access to trusted azure services | Microsoft Docs
Managing the lifecycle policies - Azure Storage | Microsoft Docs
Recently enabled storage analytics on ADLS Gen2 storage account.I can see the $logs container and the logs are writing to this on an hourly basis. But when I'm trying to add service principal to this container getting permission denied. I have storage data contributor role on this storage account, any special permission is required to achieve this?
In general, being able to manage IAM requires higher level roles to be granted to your account. I assume, that you're trying to grant access via Access Control (IAM) feature / API call. Using Storage Data Contributor is not sufficient as it only allows you to access containers and blobs with read / write / delete access.
You need a role which grants you Microsoft.Authorization/*/write permission in order to get it working.
The problem is resolved by adding the SP/groups from the portal at the container level instead of storage explorer.
I need to allow Azure AD user to manage - via the Azure Portal - containers, blobs, keys for a given storage account.
Docs state that the Storage Blob Data Contributor role by itself will not provide sufficient permissions to navigate through the portal to the blob in order to view it. So to enable user to navigate through the Portal - the Reader role is required.
Am I right that I need to assign Reader, Storage Account Contributor and Storage Blob Data Contributor roles to achieve what I want?
I have an Azure Storage Account and want to grant read access to a colleague. All identities are in the same Azure Active Directory so it was easy to add him to the "Reader" role in the Access Control blade of the Azure portal.
When he opens Microsoft Azure Storage Explorer the subscription and storage account are visible but the node for Blob Containers can't be expanded. Exception says:
Could not obtain keys for Storage Account. Please check that you have
the correct permissions
This is expected behavior. Essentially to list storage keys, the user should be in a role that allows listKeys operation. The built-in Reader role does not have permission to perform listKeys operation.
The rationale (a bit convoluted though) behind this decision is that a user in Reader role should only be able to Read and not perform any inserts/updates or deletes. Considering if someone has account key for a storage account, they can do these operations. Thus the user in Reader role is not granted permission to list the account keys.
What you could do is create a Shared Access Signature (SAS) with read/list permissions and share that SAS URL with your colleague. Then they will be able to access the data in that storage account but won't be able to perform any create/update/delete operations.
Looks like this is now possible (In preview). Your AD users can be given the "Storage Blob Data Reader" privilege.
https://azure.microsoft.com/en-us/blog/announcing-the-preview-of-aad-authentication-for-storage/
I have a Service Principal that has been granted Contributor roles on a storage account.
When I attempt to create a container within that account I receive the following error message
One-time registration of Microsoft.Storage failed - The client 'd38eaaca-1429-44ef-8ce2-3c63a62849c9' with object id 'd38eaaca-1429-44ef-8ce2-3c63a62849c9' does not have authorization to perform action 'Microsoft.Storage/register/action' over scope '/subscriptions/********'
My goal is to allow a Service Principal READ-ONLY to the blobs contained within a given storage account and to create containers within that storage account. What are the steps needed to configure my principle to do that.
Regarding your error, please see this thread: In Azure as a Resource Group contributor why can't I create Storage Accounts and what should be done to prevent this situation?.
My goal is to allow a Service Principal READ-ONLY to the blobs
contained within a given storage account and to create containers
within that storage account. What are the steps needed to configure my
principle to do that.
As of today, it is not possible to do so. Simply because RBAC only applies to the control plane of the API. So using RBAC, you can control who can create/update/delete a storage account. Access to the data inside a storage account is still controlled by an account key. Anyone who has access to the account key will have complete control over that storage account.