I hired a contractor to work on a web service that uses DocumentDB to store our data. I need the contract to be able to login to Azure and access DocumentDB, but I do not want him playing with major things like users and my subscription. I also do not want him scaling anything up or down.
How do I add him as a user and let him access DocumentDB?
If he needs to manage the docdb resource in the Azure portal, you can give him reader or contributor rights on the invididual resource or on the resource group that contains the documentdb resource. By making him contributor (in case he needs to change things), you ensure that he cannot change any user permissions. Readers obviously cannot change anything.
If you require more complex permissions, you could consider using another built in role or even creating a custom role.
In case he just needs to write an application that accesses the DocDB contents, all you have to give him is a connection string and no portal access at all.
Related
I have a requirement to customize the contributor role at Azure Subscription level, such that, people added to that customized contributor role can NOT view or read the data from the storage account (under that subscription).
This is how i'm doing this:
Step1
Step2
Step3 ( Actions shows * )
This MSFT link does NOT show me the JSON details that can be removed or added so that the read access to the storage account can be blocked.
Hence, I'm trying below ways to customize this (two assignable scopes to cover subscription as well as block viewing the storage data):
Note, The idea is to People need a contributor role to manage the subscription. However, they MUST NOT view the data from the storage under this particular subscription.
I think this is not the right approach. Are there any other ways to achieve this? Thanks.
If you want to create a custom role, then you should have a look at the resource provider operations. From there, you can see all the available actions per resource provider.
You would probably be interested in the DataActions such as Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read and others depending on what you want to filter out.
If you want to block particularly Azure Storage under Subscription Scope Level.
Kindly Exclude Azure Storage under Add Permission Section in order to block Azure Storage only while creating RBAC Role
I would like to give our team members the necessary permissions to use the Query Performance Insight feature for an Azure SQL database, including the possibility to see the query text of long-running queries.
They already have "Reader" and "Monitoring Contributor" roles, so they can access the Query Performance Insight feature in the Azure Portal and see the IDs of long-running queries. However, when they click on a long-running query, they cannot see the query text. An error is shown indicating that "The connection timed out while running the query".
If I assigned them the "SQL DB Contributor" role, they would be able to use that feature, but they could then also change database settings such as the pricing tier, which I do not want.
Is there a role assignment that does what I need?
I think you will need to create an Azure Custom Role, as described in https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles .
You can start with Reader, and then include permissions you want, or start with SQL DB Contributor, and remove permissions you don't want. This will require experimentation.
From your subscription, create a new Custom Role:
Then from that role, you will add or exclude permissions:
Permissions that would be interesting to me would be:
List Query Store texts - for adding to a Reader
and Update Database - for excluding from a DB Contributor
Once that's done, you would go to the Access Control blade for the server that contains your database, and then add your users with that new custom role. Test, tweak, repeat until you have the security profile you want. Which role you use as your basis depends upon how close to a least-privilege security model you wish to adopt.
Edit: One possible way to figure out the permission to assign would be:
Scale the database up
Scale it back down
Go to the resource group, select your database, and Export Template
Inspect the JSON, which will be the ARM that was applied during the operation (you might need to look at multiple deployments to figure this out)
Once you find the operation, the provider in the JSON should give you a clue as to what to exclude from any roles you create.
Adding to #WaitingForGuacamole's answer: We ended up creating a custom role definition containing Microsoft.Sql/servers/databases/queryStore/write and Microsoft.Sql/servers/databases/topQueries/queryText/action. Assigning this custom role definition to team members who already had the Reader role on the Azure SQL Server then allowed them to view the query texts in Query Performance Insight.
The actual two permissions were provided to us by a very helpful Azure support engineer. YMMV, it might also work with just Microsoft.Sql/servers/databases/topQueries/queryText/action (in addition to the read permissions), as indicated by an Azure Docs Github issue. However, the support engineer was positive we'd also need the Microsoft.Sql/servers/databases/queryStore/write one and we didn't follow up by researching why.
I want a group of people to be able to completely manage a subscription, including managing access to resources within it, except for managing the subscription itself. So (for example) when a new resource group with a storage account is added to the subscription, I want them to be automatically (by inheritance) have all rights to the storage account, including the right to give people roles on that storage account. I just don't want them to be able to give other people roles on the subscription itself, so no adding administrators to the subscription etc.
Is a role (or combination of roles) built-in that I can use for that? Will I have to look into creating a custom role, or is what I'm looking for not possible?
well, I might be wrong, but I dont see how this could be possible:
You want a user to inherit rights from subscription level (only way to get rights to a newly created resource group)
you want rights to assign permissions
you want to block rights to assign permissions on subscription level
so, essentially you are asking for 2 things that conflict. this would not be possible even when using Azure Blueprints, because you cannot block inheritance yet. so you cannot block rights on a specific level, you can only block rights on that level and all "downward" levels
I want to create an Azure key vault with fairly restricted access (one or two of our apps). I've created the Key Vault through the Azure portal, but when I look at the Access Control section, I find that several Apps and Users have the Contributor role (inherited from the subscription) for the key vault, which gives them more access than they should have.
Since the subscription is the highest level at which access control can be set, there is no way for me to revoke access for these apps/users without revoking it at the subscription level, and this would probably cause all sorts of problems. (it's not really clear what permissions these need, so it'd be a bit painful to have to give those permissions at a resource group or resource level). What's more, there'd be nothing stopping someone who comes along later from adding contributor roles at the subscription level (for some new app, for instance), and breaking the security of the key vault.
So with all of this in mind, what would be the best way to limit access to an azure key vault, so that only the apps/users I want have access to it, despite the fact that several apps/users already have these permissions at the subscription level?
More info: We're using the Azure Resource Manager model, and everything is currently stored in one subscription.
It looks like you can not achieve this with the way RBAC works today.
Here are a couple of feedback requests already running on Feedback Forums - https://feedback.azure.com. One is for Key Vault and another takes the example of a storage account but essentially looking for the same feature to override the inherited permissions.
You may want to vote up for these requests.
Deny users with inherited permissions to Azure Key Vault Service from modifying Access Policies
Exclude / override RBAC permissions inhereted from a subscription at a resource group level
UPDATE (to answer additional queries from comments):
Not granting subscription-level access in the first place (except to
admins)
Yes this would definitely help.
Another suggestion would be to try and use Resource Groups to organize your resources and then assign roles on these Resource Groups (scope). This way, you don't need to give access to individual items, but at the same time you can avoid giving access at the highest level of subscription.
An option you have is to create a blueprint that you can use to configure locks on your keyvaults.
If you deploy this BP as readonly the locks can't be removed from your vault so no-one can alter te permissions of your vault until you change the blueprint config again to don't lock and then remove the lock from your vault.
Applications etc having access to your vault (aka dataplane) de still access the keys ofcource
A group of friends and I are working on an private project and are considering hosting it on Azure.
I have an account on Azure and will be the one controlling the costs.
Is it possible to assign a pool of resources (e.g. Functions + database) to another user(s), preferably also assigning a cost limit for it to avoid things exploding?
You can give them access to a subscription / resource group / resource by going to e.g. the subscription and clicking on Access Control (IAM).
There you can enter their email address, and give them the role needed. Reader for read-only, Contributor for Read/Write, and Owner for Read/Write + access management. There are a bunch of others too. More about Role-based access control
I am not aware of a way to limit cost for individual users, though you can for example setup Billing alerts.
You can use ARM policies to limit the types of resources that can be used. As an example, you can deny the use of certain very expensive VMs to a group of users. Some samples of these policy templates can be found here
As stated in other answers, you can assign access to others on various levels. You can assign to "live" accounts (Hotmail,outlook,live.com etc) but as part of your subscription you can also create an Azure Active Directory instance on which you can create users. You would also want to use this AAD to create service accounts in the future, register applications for authentication, etc.