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.
Related
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
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 just purchased on OpenShift Online 3 pro account yesterday.
I want to share Web Console with another member of my team but it doesn't seem to be possible: all my teamates get a "You do not have access to Openshift Online" error message when trying to reach Web Console URL.
FYI:
I have granted them with the "admin" role in the Resources -> Membership page (try to use both their email address and pseudo)
All of them use an OpenShift Online 3 Starter account
I fear that they have to purchase an OpenShift Online v3 Pro account to be able to proceed.
Am i right? If no, can you explain me how can I allow them to use the Web Console?
Thank you.
The ability for people to sign up under a free collaborator account in the Pro tier, with the account only being able to be added against an existing project owned by a paid account isn't quite ready yet. It will be coming in a future update.
A way around the issue for now, presuming that they only need to use the command line, is to provide them with an access token and have them login from the command line using that. That token will expire every 24 hours though and they would need to be provided with a new token by the primary account owner.
Another way is if you can setup web hooks on the projects such that any commits against the Git repository trigger a new build and deployment. That way they don't need to have access to OpenShift itself if working with an existing project.
UPDATE
The ability to add non paying collaborators is described in:
https://blog.openshift.com/add-collaborators-openshift-online-pro-account/
Trying to figure out if I can do the following via the box-api.
authenticate as an enterprise admin
lookup a user (in our case a special box user named "group_xxx" where this account will serve as a non-person shared group like "group_math_dept", "group_engineering_dept", etc...).
query for the root folder info for a given user-id (perhaps "GET /users//folders/0"
(tried that it doesn't work).
View the list of enterprise users with whom the given folder has been shared.
Modify the list of enterprise users with whom the given folder has been shared.
What I'd like to do is develop an app to delegate admin of these special group accounts to an appropriate individual in the given group. We can maintain who admins what locally. I can authenticate as one of our Box Admins (i.e. I have working code for steps 1 and 2). However, I don't see support in the API v2.0 doc for steps 3, 4, and 5.
Am I missing anything?
Unfortunately my understanding is the same as what you've found; that account and meta operations like steps 3 through 5 are not currently supported through the API.
UPDATE:
Looking at Box's developers blog it looks like functionality for steps 4 and 5 were actually just added, but are not yet in the documentation.
http://developers.blog.box.com/2012/09/10/v2-api-updates-keep-rolling/
Box actually has some more enterprise/admin API methods in private beta. Those are made accessible to early testers for a controlled environment, and include methods to perform operations on behalf of other users with administrative privileges.
If you're interested, feel free to email api [at] box [dot] com to discuss the testing of beta methods.