Table of Contents

• Projects and namespaces
  • Default projects
• Role Based Access Control
  • Default cluster roles
  • Evaluating authorization
• Manage Roles
  • Local Role Binding Commands
  • Cluster Role Binding Commands
  • Create Custom Roles
• Removing the kubeadmin user

A Kubernetes namespace provides a mechanism to scope resources in a cluster.

Namespaces provide a unique scope for:

• Named resources to avoid basic naming collisions.
• Delegated management authority to trusted users.
• The ability to limit community resource consumption.

Most objects in the system are scoped by namespace, but some are excepted and have no namespace, including nodes and users.

A project is a Kubernetes namespace with additional annotations and is the central vehicle by which access to resources for regular users is managed. A project allows a community of users to organize and manage their content in isolation from other communities. Users must be given access to projects by administrators, or if allowed to create projects, automatically have access to their own projects.

Projects can have a separate name, displayName, and description.

• The mandatory name is a unique identifier for the project and is most visible when using the CLI tools or API. The maximum name length is 63 characters.
• The optional displayName is how the project is displayed in the web console (defaults to name).
• The optional description can be a more detailed description of the project and is also visible in the web console.

Each project scopes its own set of:

Cluster administrators can create projects and delegate administrative rights for the project to any member of the user community. Cluster administrators can also allow developers to create their own projects.

OKD comes with a number of default projects, and projects starting with openshift- are the most essential to users. These projects host master components that run as pods and other infrastructure components. The pods created in these namespaces that have a critical pod annotation are considered critical, and the have guaranteed admission by kubelet. Pods created for master components in these namespaces are already marked as critical.

Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project.

Cluster administrators can use the cluster roles and bindings to control who has various access levels to the OKD platform itself and all projects.

Developers can use local roles and bindings to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.

There are two levels of RBAC roles and bindings that control authorization:

A cluster role binding is a binding that exists at the cluster level. A role binding exists at the project level.

OKD includes a set of default cluster roles that you can bind to users and groups cluster-wide or locally. You can manually modify the default cluster roles, if required.

Be mindful of the difference between local and cluster bindings. For example, if you bind the cluster-admin role to a user by using a local role binding, it might appear that this user has the privileges of a cluster administrator. This is not the case. Binding the cluster-admin to a user in a project grants super administrator privileges for only that project to the user. That user has the permissions of the cluster role admin, plus a few additional permissions like the ability to edit rate limits, for that project. This binding can be confusing via the web console UI, which does not list cluster role bindings that are bound to true cluster administrators. However, it does list local role bindings that you can use to locally bind cluster-admin.

The relationships between cluster roles, local roles, cluster role bindings, local role bindings, users, groups and service accounts:

OKD evaluates authorization by using:

The user name and list of groups that the user belongs to.

The action you perform. In most cases, this consists of:

• Project: The project you access. A project is a Kubernetes namespace with additional annotations that allows a community of users to organize and manage their content in isolation from other communities.
• Verb: The action itself: get, list, create, update, delete, deletecollection, or watch.
• Resource Name: The API endpoint that you access.

The full list of bindings, the associations between users or groups with a role.

OKD evaluates authorization by using the following steps:

1. The identity and the project-scoped action is used to find all bindings that apply to the user or their groups.
2. Bindings are used to locate all the roles that apply.
3. Roles are used to find all the rules that apply.
4. The action is checked against each rule to find a match.
5. If no matching rule is found, the action is then denied by default.

Remember that users and groups can be associated with, or bound to, multiple roles at the same time.

Project administrators can use the CLI to view local roles and bindings, including a matrix of the verbs and resources each are associated with.

You can use the oc adm administrator CLI to manage the roles and bindings.

Binding, or adding, a role to users or groups gives the user or group the access that is granted by the role. You can add and remove roles to and from users and groups using oc adm policy commands.

You can bind any of the default cluster roles to local users or groups in your project.

oc adm policy who-can <verb> <resource>

oc adm policy add-role-to-user <role> <user>

oc adm policy add-role-to-user <role> <user> -n <project>

For example add admin role to alice in project joe

oc adm policy add-role-to-user admin alice -n joe

oc adm policy remove-role-from-user <role> <user>

oc adm policy remove-user <user>

oc adm policy add-role-to-group <role> <group>

oc adm policy add-role-to-group <role> <group> -n <project>

oc adm policy remove-role-from-group <role> <group>

oc adm policy remove-group <group>

oc describe rolebinding.rbac -n <project>

oc adm policy add-cluster-role-to-user <role> <user>

oc adm policy remove-cluster-role-from-user <role> <user>

oc adm policy add-cluster-role-to-group <role> <group>

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

Users with the cluster-admin default cluster role bound cluster-wide can perform any action on any resource, including viewing cluster roles and bindings.

oc adm policy add-cluster-role-to-user cluster-admin <user>

oc describe clusterrolebinding.rbac

oc create role <name> --verb=<verb> --resource=<resource> -n <project>

In this command, specify:

• <name>, the local role’s name
• <verb>, a comma-separated list of the verbs to apply to the role
• <resource>, the resources that the role applies to
• <project>, the project name

For example:

oc create role podview --verb=get --resource=pod -n blue

To bind the new role to a user:

oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue

oc create clusterrole <name> --verb=<verb> --resource=<resource>

In this command, specify:

• <name>, the local role’s name
• <verb>, a comma-separated list of the verbs to apply to the role
• <resource>, the resources that the role applies to

For example:

oc create clusterrole podviewonly --verb=get --resource=pod

To bind the new role to a user:

oc adm policy add-cluster-role-to-user podviewonly user2

https://docs.okd.io/latest/authentication/using-rbac.html

OKD creates a cluster administrator, kubeadmin, after the installation process completes.

This user has the cluster-admin role automatically applied and is treated as the root user for the cluster. The password is dynamically generated and unique to your OKD environment. After installation completes the password is provided in the installation program’s output. For example:

INFO Install complete!
INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI.
INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes).
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com
INFO Login to the console with user: kubeadmin, password: <provided>

After you define an identity provider and create a new cluster-admin user, you can remove the kubeadmin to improve cluster security.

If you follow this procedure before another user is a cluster-admin, then OKD must be reinstalled. It is not possible to undo this command.

Prerequisites:

• You must have configured at least one identity provider.
• You must have added the cluster-admin role to a user.
• You must be logged in as an administrator.

Remove the kubeadmin secrets:

oc delete secrets kubeadmin -n kube-system

https://docs.okd.io/latest/authentication/remove-kubeadmin.html