Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Irrespective of an assigned role, a service principle has same privileges as an owner
See original GitHub issueWhich service(blob, file, queue) does this issue concern?
azure-storage-blob v1.2.0rc1
What problem was encountered?
I have a web server, which I want to give it read access to my Azure blob storage. Additionally, I want the web server to have independent permissions from mine (i.e., my user account). I think using the new features added to Azure (e.g., Added support for OAuth authentication for HTTPS requests) I can leverage OAuth2.0 access tokens and Azure AD roles for this purpose. Therefore, I followed this documentation, and created a service principal and assigned Azure Storage permission to it. Then in the Azure portal, under Storage -> Access Control (IAM), I defined Storage Blob Data Reader (Preview) role and assigned it to my service principal.
So, I implemented a logic similar to this to acquire access token, then I use the token to read the blob. However, I get an error saying that I am not allowed to access the blob. Then I assign myself the Storage Blob Data Reader (Preview) role, and then I’m able to read the blob. So, the service principal’s role is not effective, i.e., I cannot assign myself a Contributor (read/write) and give the service principal the Reader role.
Am I missing some important setting here?
Have you found a mitigation/solution?
No.
Update 1:
Following is a summary of the different combinations I tried and their resulted outcome:
| xyz@hotmail.com Role | Service Principal Role** | Read/Write Result | Expected Outcome |
|---|---|---|---|
| Contributor* | Contributor* | Successful (i.e., can read and write) | Successful |
| Contributor* | None | Successful (i.e., can read and write) | Fail |
| None | Contributor* | AuthorizationFailure This request is not authorized to perform this operation. RequestId:509428ef-901e-00f3-4b93-051b26000000 |
Successful |
*Contributor = STORAGE BLOB DATA CONTRIBUTOR (PREVIEW)
**Service Principal ID: 58ad99f1-19e9-4b08-8121-c372e1f14653
Update 2:
In the request for the an OIDC/OAuth2.0 access token, I set the client_id attribute is to the service principal ID.
Issue Analytics
- State:
- Created 5 years ago
- Comments:11 (5 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@VJalili I guess your service principal is created by a native application in the AAD and you are using this flow:
This means you are authenticated as the user you login (i.e.: xyz@hotmail.com). So you might expect the result according to the user role assignment, which matches the outcome in the first post.
If you’d like to authenticate with the service principal, could you please try to create an application with type: Web App /API and create a secret for it. See steps here.
When this is setup, you might want to do the same role assignment to this service principal for the storage account.
Then you can require access token with the application’s Id and secret to get an access token for this application and read the blobs under the account.
@yaxia Thanks.