I would like to create an Azure customised role (in JSON format) with Global Admin perms but with a limitation to creating resources. Anyone can help with that?
(or a more relevant built-in Azure role?)
Much appreciated!
Not an expert of Azure/JSON
By default, global-administrator built-in role won't assign RBAC roles to Azure resources. You can see the same mentioned here.
Azure AD and Azure resources are secured independently from one another. That is, Azure AD role assignments do not grant access to Azure resources, and Azure role assignments do not grant access to Azure AD.
If you just want the role not to create resources, you would need to clone all perms of global administrator & Owner roles & individually exclude create actions like Microsoft.Compute/*/create, Microsoft.Storage/*/read etc., in notActions list
Related
Is there a way to create RBAC roles in such a way that only provides a user to create a project and be admin for that project?
I cannot create cluster-admin role restricted for a project as we dont know what project it can be.
The usecase is , a user should be able to create a project and be admin to only his project
It's not possible to create an RBAC policy that will let them create a specific project. We handle this by having an onboarding system that permits people to request projects through a github pull request; when we approve the PR, our tooling creates the project and then sets up the requester as a project admin by creating per-project groups and rolebindings.
Have you looked at the self-provisioner role? I think this is what you are looking for.
That allows user to create projects. In that project they will then have local admin rights, except to modify quotas. Note that they actually have to use new-project to do this, they still can't just randomly create namespaces. (This is one of the reasons projects exist.)
Look at the docs for RBAC, including self-provisioner and differences between admin and cluster-admin.
Also see the section of project creation including how you template out the new projects.
We have a centralized development instance for Azure API Management Service where developers from different agencies/organization creates their Products, API and subscription. Essentially they have contributor role on resource group of APIM instance. This is a centralized shared APIM instance.
I can probably create a Custom RBAC role that allows me to edit only my API but not sure how to hide my own API and products from others.
Is there a way for developers to hide their Products and API entirely from other developers in Admin portal as well as in Developer portal?
Have you tried implementing the restriction at the product level?
Check your user list.
Create a group with by selecting the required members.
Create an product( Add required APIs) -> Go to access control -> Add a group (you may remove the Administrator group)
I would like to create an Azure Active Directory Custom role with the following perimeters:
Who to assign the role to:
Either a user, or group
What access will the role have:
Default role permissions from "User Access Administrator" directory role
Scope:
The custom role would only grant access in the specified AAD Groups
(My idea is to have users with this custom role, be able to fill the roles of a User Access Administrator ONLY in the Scoped AAD Groups)
This would provide application administrators the required rights to assign application roles to the specified "Scope" AAD groups, with least privileged in Active Directory
Is it possible to scope an Azure Active Directory custom role to an AAD Group? Not assign the role to a group, but rather the custom role only grant permissions to manage the AAD Group (Assign / Remove application roles to the group... etc)?
Meaning no rights/permissions exist in AAD, except for User Access Administration of that specified "Scope" AAD Group
If so, what would the scope format be, when creating the custom role? Preferable in JSON or Powershell
There is no support today for custom roles in Azure Active Directory. Only the predefined Administrator Roles, as described in the documentation, are available for use.
You may, however take a look at the advanced self-service or delegated group management capabilities and combine them with some existing role (like User Access Adminsitrator or Application Administrator). You may also like to see the difference between Application Administrator and Cloud Application Administrator.
In persuade for least privilege access, you may find the Least Privilege Role by Task document useful. And also the Microsoft Azure AD Privileged Identity Management to control and audit privileged tasks.
Last, but not least, a preview feature - Administrative Units may be of interest to you.
To summarize it
As of today (2018-12-04), there is no option to create custom role within Azure AD. Neither to constrain given role to a specific Group (be it security or office)
I believe this is already available now? https://learn.microsoft.com/en-us/azure/active-directory/users-groups-roles/roles-custom-overview
I have multi-tenant application, which exposes some API for our customers to use. I would like to expose it using Azure API Management. Mostly to provide Development Portal to our customers, which I find very useful, and maybe use some other features.
If I understand correctly, our customers will set up their own subscription keys for authentication, which API Management proxy will validate.
Question: How can I link and identify user/subscription to the tenant of my application, to ensure that only data from this tenant are returned.
One direction I can see to explore is to use delegated sign up, which I guess will help me to link subscription to the tenant. But then still the question is how to get user id in my backend API?
Any direction to documentation or samples is very appreciated
You could create separate groups in APIM to represent your tenants and then put users into those groups using delegation hookups. Withing APIM policy in expressions you can reference context.User.Groups to list groups user making the call belongs to and forward that information to backend.
Alternatively you could use Note field to store tenant name and access it as context.User.Note. Or if you're willing to store mapping on your side the just take an id context.User.Id.
All of above could be passed as a header using set-header policy like:
<set-header name="userId">
<value>#(context.User.Id)</value>
</set-user>
All scenarios would require you to have delegation setup to fill this information automatically for every new user created.
I want some guidance as to how to go about this:
I want to have some objects in my S3 bucket by accessible only be a few users (users from my web app). I looked through the AWS docs and it seems as though I need to give each of my users AWS access keys(?).
Obviously I don't want to do this, so is there any way in my app to lock out some users and let other in? I'm using Node.JS and MySQL (to store my users) if that makes a difference.
Thanks a lot for the help.
The very simple description of the S3 access / permission scheme is...Access to S3, like most other AWS resources is based on IAM-centric access controls. So, you can either grant access to your S3 buckets by either granting users access to it (setting it on S3) or granting S3 access to a user (setting it in IAM as a policy). So, whatever or whomever is accessing S3 must be authenticated to AWS. Again, that is a very high-level description and meant to simply point out that access is based on user/role authentication.
Now, assuming your web-app is running on AWS (EC2?), than your EC2 instance has been (hopefully) assigned an IAM role. Once that IAM Role has been assigned the permissions to do so, the application running on the EC2 instance can now access any AWS resource via that Role.
But, you don't want ALL of your webapp users to access S3, so my two thoughts are:
1) Check the users credentials within your app (assuming the user needs to authenticate somehow with your application) and make the determination of whether or not to call S3 based on the users credentials. You would then use the IAM Role assigned to the EC2 instance (an EC2 instance can only have 1 IAM Role assigned to it) and access S3 or not.
This second idea is a pretty bad one and smells bad to me. I'm pointing it out merely as a possibility and to highlight how the use of IAM Users / Roles works.
2) This suggestion would not utilize the IAM Role assigned to the EC2 instance, though I would always advocate for assigning a Role to the instance, you can always lock down that role and deny access to all AWS resources, but you can't add a role to the instance after launched.
Have two IAM Users (S3Granted and S3Denied, each of which obviously have appropriate policies for accessing S3). Each user of your webapp (e.g. Hillary Clinton, Donald Trump, Bernie Sanders and Ted Cruz) would then each map to one of the two IAM Users based on whether or not they should have access to S3. This would be a field in your MySQL database. You wouldn't bother checking the credentials up-front (because then you would just be performing Option #1 and would proceed with the S3 call regardless of the user and S3 will either grant or deny access based on the IAM User account your webapp user is associated with. You technically wouldn't need the S3Denied User (you could just have no user), but I figured it would be cleaner to specify the IAM User.
e.g.:
WebAppUser/Bernie Sanders --> IAMUser/S3Granted
WebAppUser/Hillary Clinton --> IAMUser/S3Denied
WebAppUser/Ted Cruz --> IAMUser/S3Granted
WebAppUser/Donald Trump --> IAMUser/S3Denied
For Option #2, you would then need to store the Access keys for both IAM Users m(S3Granted and S3Denied) somewhere so that you could properly authenticate.
Also, you would need to do a bit of exception handling so that you could properly notify your users that they have been denied access.
Overall, #2 is just a bad idea. It would be much cleaner if you simply had a field in your MySQL database that specified whether or not they can access S3 and either make the S3 call via the IAM Role or refuse to do so within your webapp. Don't leave it to S3 to grant or deny access.