Fine grained access control examples
APPUiO Cloud allows fine-grained control over which projects a user may access through standard RBAC roles.
This is useful for organizations that have multiple projects and want to restrict some users access to only certain projects.
You can either create Teams, which show up as an OpenShift group organization+team or assign users directly.
The examples below assume the following structure:
mycompany (organization)
├── mycompany-user1 (user)
├── developers (team)
└── operations (team)
Prerequisites for all examples
For this guide, it’s assumed that:
-
You are logged in to APPUiO Cloud using the
oc logincommand.
User may access only certain projects in the organization
| OpenShift has no notion of group hierarchy, so you need to add the user to all groups that should have access to the project. |
|
There are multiple relevant RoleBindings in each Namespace:
|
-
Remove the user from the
mycompanyorganization -
Add the user to the
developersteamThe hierarchy should now look like this:
mycompany (organization) ├── developers (team) │ └── mycompany-user1 (user) └── operations (team) -
Allow only organization
mycompanyand teammycompany+developersaccess to your project (including access to the user workload monitoring)ORGANIZATION=mycompany TEAM=developers PROJECT=mycompany-web-portal for rb in admin monitoring-edit monitoring-edit-probe alert-routing-edit; do oc -n "${PROJECT}" patch rolebinding "${rb}" -oyaml --patch """ subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: ${ORGANIZATION} - apiGroup: rbac.authorization.k8s.io kind: Group name: ${ORGANIZATION}+${TEAM} """ done-
The user can be referenced directly as well.
ORGANIZATION=mycompany USER=mycompany-user1 PROJECT=mycompany-web-portal for rb in admin monitoring-edit monitoring-edit-probe alert-routing-edit; do oc -n "${PROJECT}" patch rolebinding "${rb}" -oyaml --patch """ subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: ${ORGANIZATION} - apiGroup: rbac.authorization.k8s.io kind: User name: ${USER} """ done
-
User may not create new projects in their organization
-
Remove the user from the
organizationgroup -
Add the user to a team that has access to the required projects
The hierarchy should now look like this:
mycompany (organization) ├── developers (team) │ └── mycompany-user1 (user) └── operations (team) └── mycompany-user1 (user) -
Allow access to the required projects
See User may access only certain projects in the organization for an example.
Give a team or user edit permissions for user workload monitoring resources in a project
-
Remove the user from the
organizationgroup -
Add the user or team which should have access to user workload monitoring to role bindings
monitoring-edit,monitoring-edit-probeandalert-routing-editin the required projects.ORGANIZATION=mycompany TEAM=developers PROJECT=mycompany-web-portal for rb in monitoring-edit monitoring-edit-probe alert-routing-edit; do oc -n "${PROJECT}" patch rolebinding "${rb}" -oyaml --patch """ subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: ${ORGANIZATION} - apiGroup: rbac.authorization.k8s.io kind: Group name: ${ORGANIZATION}+${TEAM} """ done
Give a team or user permissions to manage resource quotas in a project
-
Remove the user from the
organizationgroup -
Add the user or team which should have permission to manage resource quotas to the role binding
resource-quota-editin the required projects.ORGANIZATION=mycompany TEAM=developers PROJECT=mycompany-web-portal oc -n "${PROJECT}" patch rolebinding resource-quota-edit -oyaml --patch """ subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: ${ORGANIZATION} - apiGroup: rbac.authorization.k8s.io kind: Group name: ${ORGANIZATION}+${TEAM} """ done