I was going via this Link
where it says "A maximum of 500 role-assignable groups can be created in a single Azure AD organization (tenant)."
This looks like a big limitation in Azure. The question is, how are big organization ( having more than 500 groups - I'm sure they must have considering different departments/towers/groups/applicaions) manages this limitations?
What are the best practice or architecture decission must be followed while creating groups/access package? considering limitation.
Thanks.
According to restriction for role assignable groups, and as you already mentioned that - A maximum of 500 role-assignable groups can be created in a single Azure AD organization (tenant).
First of all, The purpose of role assignable groups is to prevent potential breaches of misuse of assigned permission and it can be created only by Global administrator role or PIM role (privileged identity management). Since the purpose of role assignable security group is to assign role and underline permissions specific to the requirement regarding the deployment of azure resources or likewise scenarios, The role assignable security groups being of high value concern are mostly number few than the other group type.
That limit cannot be changed for particular subscription . Usually smaller institutions or organizations use single tenant and that limit suffices those cases.
Most of the larger institutions(say which have over 1 million users) use multi tenant architechture, to avoid such kind of tenant and quota limitations/ restrictions on services.
Multi-tenant architecture is approached for the regional cases to make easy for larger organisation.
This condition is made bigger institution to manage limitation easily.
Reference : github issue
Related
I'm exploring options for securing some Azure resources within a subscription from tampering, even by subscription owners.
The intent is to standardize our subscriptions which are used by other teams for their engineering. We've considered giving teams custom RBAC roles similar to Owner and Contributor, but slightly reduced--however we've found this approach to be high friction and not to cover 100% of our scenarios. In some cases excluding a permission is fine--in others we need to grant them those permissions but restrict them from being used on our resources.
Our preferred design is to create a resource group of a known-name in each standardized subscription, place the resources users aren't allowed to modify or delete in the group, and explore options to prevent subscription owners from tampering with that RG or its resources.
So far we've explored most options we're aware of:
excluding the action/permission isn't an option as the users need those actions/permissions to manage other resources of the same type (i.e. denying users the ability create/modify/delete resource groups isn't viable)
defining an Azure Resource Policy to either deny all operations on the RG (which doesn't appear to function)
defining an Azure Resource Policy to require our standard resources -- this still does nothing to prevent deletion
Blueprints (in Preview) to create a locked (with some kind of lock other than a Resource Lock?!?) RG and apply deny assignments
Other options begin to get "sloppy". They leave gaps, or create significant complexity. Such as...
Relying on Policy to report (and possibly redeploy) when required resources were destroyed
These resources are security and compliance related--Policy can eventually detect their absence, but the gap between deletion and detection leads to these subscriptions being potentially tainted
Denying our users the resource lock permissions, so we can exclusively lock our RG and they are unable to unlock it
When the RG is unlocked there is no protection -- so we would need to coordinate unlocking it, applying updates, relocking it, and re-verifying that nothing else snuck in while it was unlocked
Give our teams a single RG per subscription and only grant them permissions at the RG level
This may have merit if RGs could be nested -- and perhaps is one of the few viable options, but taking away Resouce Group management from Azure engineers feels wrong and would likely lead to RGs being 'bloated' with multiple deployments as well as
Blueprints may be an option, but raise similar questions around coordinating the unlocking and relocking of resources
And, Terraform is our IaC platform -- Blueprints are in some ways another layer of IaC, so while we may get this to work it will require some analysis to use Blueprint for just the minimum to create protections and Terraform to continue to do the bulk of the work
After learning more about Azure Policy I'm gaining the understanding that it's not capable of setting policies to prevent deletion. It can define conventions for creating or updating resources, it can create resources if they are absent, but it doesn't trigger during deletion and so resources required by Policy cannot be protected by Policy.
Overall this seems somewhat counter-intuitive--as delete operations are a /write permission just like create and update.
So overall I don't believe Policy is actually a permissions component. It lacks any context of who is performing an action and instead effectively is good for saying "if you do X it needs to meet criteria Y". And not saying "your subscription is required to comply with X".
This is surprising--does Azure not have any way of setting resource-level permissions at the Subscription level or above?
After communicating with our Azure contacts this is a known limitation. Presently there is currently no way to retract permissions once granted. I.e. if you grant a user the ability manage resource groups you can not deny them those permissions to a specific instance.
There are some half-baked abilities in AWS Blueprint, which can deploy a Resource Group with an RBAC Deny Assignment (only available via Blueprints). When assigning the Blueprint the "lock" is actually an RBAC Deny -- not a Resource Lock (confusing?).
Hoever they explicitly block that permission from being inherited. So while the resource group itself is "ReadOnly" nothing within it is. Using ARM templates deployed via Blueprints may support this -- but in our case that would involve rewritting months of work.
Hopefully Microsoft will add Deny Assignments directly to RBAC. They have the API and ability but are keeping it hidden/locked at the moment.
I need to create two users in same subscription.Let users be A and B.the resource creating by user A should not be visible to user B and vice versa.It would be great if some one help me on this.
Assign RBAC to the user in the resource group Level, the user not able to access the resource until the user has permission to that resource group.
for more details please refer to this document
it would depend on the type of resources being created. it works in a hierarchy fashion, so if a user had access to read and write resources under the subscription, then they could see it all the resources under that. but you could for example create a resource group and only give users access to that, so they won't see other resource groups that they don't have access to.
Other than that, you could create more subscriptions, then use management groups for a level of management above that.
there may be other options, like creating custom roles that only allow very specific creation and not reading resources and such, which may or may not work. but that would need to be tested.
I'm trying to configure some management groups in Azure, I have three subscriptions (prod, dev and core), I have three mnagement groups by the same name, I then have six application groups (prod1, prod2, dev1, dev2, core1 and core2), what I;'m trying to work out is whether we can have the root management group, going into three subscription groups, which then go into 2 application groups, per subscription group and then have the two application groups going into one subscription? Or does it not work like that? All the reading I've been doing shows one management group per subscription, but I can't see why we can't do this. Help!!
Image: https://pasteboard.co/IiYTk1a.jpg
Hope that makes sense
Thanks in advance
A subscription can exist in a single management group. You can have hierarchy of groups to have more fine grain control but each group can have a single parent
If you need to control access for multiple users between different subscriptions then you can use a custom RBAC roles and give it a custom permissions.
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.
I'm looking to develop an application using Azure Active Directory, primarily because of the built-in support for easy authentication in Web API and across various Azure tools.
My application will consist of a number of projects that each contain a number of sub-projects. With authentication covered, I'm trying to work out how I can handle authorization with Azure AD now. I envision that there would be different roles associated with each of the sub-projects (5-10), with people getting assigned to them on a per-sub-project basis.
Now, I know that AD supports roles and groups. Roles are sets of permissions and groups are sets of users. While I could create a group for each of the sub-projects, I expect that some of the roles could vary based on each of the larger projects, so I can't just check to see if a given user is assigned to X group and Y role. Not to mention, because a user could be assigned to more than one group and role, I don't see a way to specify that the role is applicable to just a single group (since the user may not be intended to have that role in all groups).
So, the only way I see right now to move forward would be to create new roles each time I create a new project and sub-project that are specific to each. However, as these projects and sub-projects are created and deleted over time, I expect we'll start hitting the upper caps of how many roles AD supports altogether (especially on a per-user basis).
In traditional Active Directory, I expect this would be handled via Organizational Units that could represent each of the projects and each of the sub-projects, each with assigned roles and groups. However, according to https://learn.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-create-ou there isn't support for Organizational Units in Azure AD and that it can't be assigned via the AD Graph API.
Using Azure AD, is there a better approach to take here apart from unique roles for each sub-project at this point?
Thanks!
Edit for more information:
Right now Azure AD supports groups and roles. Let's say I have two projects, A and B and each of those has two inner sub-projects, A1 and A2, and B1 and B2. Additionally, I have a user that I want assigned to an Admin role on A1, a Power User role on B2, and no access to B2 or A1.
It seems that I could make a group for A1, A2, B1 and B2 and simply assign the user to group A1 and B2. On the backend, I can just specify that the user should be in those groups and deny access for anyone that's not.
Ok, so that handles group access, but then I want to assign the roles. I can grant them Admin and Power User, but then they'll have both of those roles on both of the groups they're in because I can't assign the roles in the context of a group.
The only other approach I can see is to create distinct roles for each of the groups, so now I have "Admin-A1", "Power User-A1", "Admin-A2", "Power User-A2", "Admin-B1", "Power User-B1", "Admin-B2", and "Power User-B2", but this is going to greatly inflate my object count over time (50 projects with 10 sub-projects apiece with 8 roles will start working up there, though 500k is quite the high threshold).
I forsee a maintainability problem with having so many roles. Since I can't correlate a role with a group and can only specify the display name and description for it (both would be useful for a project owner to see when assigning them), how might you suggest that I identify on the backend which roles are associated with which project (without having to keep my own list of guids to store the extra attributes)? Is there a way to submit custom attributes with the roles/groups?
What kind of roles you are developing with? Did you mean the application role?
Based on my understanding, we can register an separate apps for every sub-project on Azure portal and custom the roles based on every app we register and assign the roles to users/groups we want. And this role should only work for the corresponding project for the app.
More detail about manage application based on the roles you can refer the code sample here.
, I expect we'll start hitting the upper caps of how many roles AD supports altogether (especially on a per-user basis).
There is no such limitation for the roles for one single user. But if you are using the free edition version Azure AD, it supports 500,000 objects. An object is an entry in the directory service, represented by its unique distinguished name. Here are two helpful links for your reference:
Azure AD service limits and restrictions
Azure Active Directory editions