Limiting how many projects a user can request by defining three different privilege levels

The label is named level, and the possible values are bronze, silver,
gold, and platinum. Platinum users do not have a maximum number of project
requests, gold users can request up to 10 projects, silver users up to 7
projects, bronze users up to 5 projects, and any users without a label are by
default only allowed 2 projects.

Each user can only have one value per label. For example, a user cannot be both
gold and silver for the level label. However, when configuring the
master-config.yaml file, you could select users that have any value for a
label with a wildcard; for example, level=*.

To define privilege levels for project requests:

Apply label selectors to users. For example, to apply the level label selector with a value of bronze:

$ oc label user <user_name> level=bronze

Repeat this step for all bronze users, and then for the other levels.

Optionally, verify the previous step by viewing the list of labeled users for each value:

If you use a custom project template to limit the number of projects per user,
then you must ensure that you keep the modifications by including the
following:

ProjectRequester = "openshift.io/requester"

Ownership is established using the openshift.io/requester annotation, so
your custom project template must have the same annotation.

Controlling and Monitoring Resource Usage

If you configure a project to have ResourceQuota restrictions, then the amount
of the defined quota currently being used is stored on the ResourceQuota object
itself. In that case, you could check the amount of used resources, such as CPU
usage:

$ oc get quota

However, this would not tell you what is actually being consumed.
To determine what is actually being consumed, use the oc describe command:

$ oc describe quota <quota-name>

Alternatively, you can set up
cluster metrics for more detailed statistics.

Determining Which Roles Users Get by Default

When a user first logs in, there is a default set of permissions that is
applied to that user. The scope of permissions that a user can have is
controlled by the
various types
of
roles within OpenShift:

ClusterRoles

ClusterRoleBindings

Roles (project-scoped)

RoleBindings (project-scoped)

You may want to modify the default set of permissions. In order to do this, it’s important to understand the default groups and roles assigned, and to be aware of the roles and users bound to
each project or
the entire cluster.

Leveraging Default Groups

There are special groups that are assigned to users. You can target users with these groups, but you cannot modify them. These special groups are as follows:

Group

Description

system:authenticated

This is assigned to all users who are identifiable to the API. Everyone who is not system:anonymous (the user) is in this group.

system:authenticated:oauth

This is assigned to all users who have identified using an oauth token issued by the embedded oauth server. This is not applied to service accounts (they use service account tokens), or certificate users.

system:unauthenticated

This is assigned to users who have not presented credentials. Invalid credentials are rejected with a 401 error, so this is specifically users who did not try to authenticate at all.

You may find it helpful to target users with the special groups listed above.
For example, you could share a template with all users by granting
system:authenticated access to the template.

The "default" permissions of users are defined by which roles are bound to the
system:authenticated and sytem:authenticated:oauth groups. As mentioned
above, you are not able to modify membership to these groups, but you can
change the roles bound to these groups.
For example, to bind a role to the system:authenticated group for all projects
in the cluster:

$ oc adm policy add-cluster-role-to-group <role> system:authenticated

Currently, by default the system:authenticated and sytem:authenticated:oauth
groups receive the following roles:

Role

Description

shared-resource-viewer

For the openshift project. Allows users to see templates and pull images.

basic-user

For the the entire cluster. Allows users to see their own account, check for information about requesting projects, see which projects they can view, and check their own permissions.

self-provisioner

Allows users to request projects.

system:oauth-token-deleter

Allows users to delete any oauth token for which they know the details.

cluster-status

Allows users to see which APIs are enabled, and basic API server information such as versions.

system:webhook

Allows users to hit the webhooks for a build if they have enough additional information.

Viewing Roles and Users for a Project

To view a list of all users that are bound to the project and their roles:

These commands can generate huge lists, so you may want to pipe the output into a text file that you can search through more easily.

Controlling User Permissions with Roles

You can define
roles (or permissions)
for a user before their initial log in so they can start working immediately.
You can assign many different types of roles to users such as admin,
basic-user, self-provisioner, and cluster-reader.

For a complete list of all available roles:

$ oc adm policy

The following section includes examples of some common operations related to
adding (binding) and removing roles from users and groups. For a complete list
of available local policy operations, see
Managing Role Bindings.

Adding a Cluster Role to a Group for All Projects

Removing a Cluster Role from a Group for All Projects

To remove a role from a specified group for all projects in the cluster:

$ oc adm policy remove-cluster-role-from-group <role> <groupname>

Restricting Role Bindings

By default, a project administrator can create role bindings within the project
that specify any users, groups, or service accounts in the cluster as subjects
of those bindings. However, the cluster administrator can define restrictions in
order to allow only specific subjects.

The administrator defines these restrictions in the form of
RoleBindingRestriction objects. An individual RoleBindingRestriction object is
specific to a project or namespace. Role bindings in a namespace are restricted
by the RoleBindingRestriction objects in that namespace. Restrictions on
subjects are enforced as follows:

If no RoleBindingRestriction object exists within a particular namespace, then
no restrictions are enforced in that namespace (for example, any subject is allowed).

If any RoleBindingRestriction object in the namespace matches a subject, then
that subject is allowed.

If one or more RoleBindingRestriction objects exist in the namespace, but none
matches a given subject, then that subject is not allowed.

Each RoleBindingRestriction object can match subjects of one type: users,
groups, or service accounts. Users can be matched by name, label selector, or
group membership. Groups can be matched by name or label selector. Service
accounts can be matched by name or namespace.

Role binding restrictions are enforced by the RestrictSubjectBindings admission
control plug-in, which is disabled by default. To enable it, add the following
stanza to the master-config.yaml file:

Match against user subjects. A RoleBindingRestriction specification must specify
exactly one of userrestriction, grouprestriction, or
serviceaccountrestriction.

2

Match any user with the name john or jane.

3

Match any user that is in the group1 group.

4

Match any user that matches the specified label selector.

With the foregoing RoleBindingRestriction, role bindings with the subject
john or jane will be allowed. Role bindings with subjects that are members
of the group1 group, or that match the specified label, will also be
allowed. The admission control plug-in will prohibit bindings with any subject
that is not matched by some RoleBindingRestriction in the namespace:

Match any service account with the name service_account_name1 in the
namespace called namespace1.

3

Match any service account with the name service_account_name2 in the same
namespace as the RoleBindingRestriction object.

4

Match any service account in the namespace2 namespace.

Sharing Templates for Use in Projects Across the Cluster

Templates are project-scoped resources, so you cannot create them to be readily
available at a cluster level. The easiest way to share templates across the entire
cluster is with the openshift project, which by default is already set up to
share templates. The templates can be annotated, and are displayed in the web
console where users can access them. Users have get access only to the
templates and images in this project, via the shared-resource-viewer role.

The shared-resource-viewer role exists to allow templates to be shared across
project boundaries. Users with this role have the ability to see all existing
templates and pull images from that project. However, the user still needs to
know which project to look in, because they will not be able to view the project
in their oc get projects list.

By default, this role is granted to the system:authenticated group in the
openshift project. This allows users to process the
specified template from the openshift project and create the items in the
current project:

$ oc process openshift//<template-name> | oc create -f -

You can also add the registry viewer role to a user, allowing them to view and
pull images from a project:

$ oc policy add-role-to-user registry-viewer <user-name>

Creating a Cluster Administrator User

Cluster administrator is a very powerful role, which has ultimate control
within the cluster, including the power to destroy that cluster. You can grant
this role to other users if they absolutely need to have ultimate control.
However, you may first want to examine the other available roles if you do not
want to create such a powerful user. For example, admin is a constrained
role that has the power to do many things inside of their project, but cannot
affect (or destroy) the entire cluster.

Creating an Administrator Within a Project

To create a basic administrator role within a project:

$ oc adm policy add-role-to-user admin <user_name> -n <project_name>

Creating a Cluster Administrator

To create a cluster administrator with ultimate control over the cluster:

Be very careful when granting cluster administrator role to a user. Ensure that
the user truly needs that level of power within the cluster. When OpenShift is
first installed, a certificate based user is created and the credentials are
saved in admin.kubeconfig. This cluster administrator user can do absolutely
anything to any resource on the entire cluster, which can result in destruction
if not used carefully.