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 login command.

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:

  • admin - allows the user to manage most resources in the Namespace

  • namespace-owner - allows the user to manage (including delete) the Namespace itself

  • monitoring-edit, monitoring-edit-probe, alert-routing-edit - allow the user to manage user workload monitoring related resources.

  1. Remove the user from the mycompany organization

  2. Add the user to the developers team

    The hierarchy should now look like this:

    mycompany (organization)
├── developers (team)
│   └── mycompany-user1 (user)
└── operations (team)

  3. Allow only organization mycompany and team mycompany+developers access 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

    1. 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

  1. Remove the user from the organization group

  2. 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)

  3. 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

  1. Remove the user from the organization group

  2. Add the user or team which should have access to user workload monitoring to role bindings monitoring-edit, monitoring-edit-probe and alert-routing-edit in 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