After installing OpenShift Container Platform, you can further expand and customize your cluster to your requirements, including taking steps to prepare for users.
The OpenShift Container Platform control plane includes a built-in OAuth server. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API.
As an administrator, you can configure OAuth to specify an identity provider after you install your cluster.
By default, only a kubeadmin
user exists on your cluster. To specify an
identity provider, you must create a custom resource (CR) that describes
that identity provider and add it to the cluster.
OpenShift Container Platform user names containing |
You can configure the following types of identity providers:
Identity provider | Description |
---|---|
Configure the |
|
Configure the |
|
Configure the |
|
Configure a |
|
Configure a |
|
Configure a |
|
Configure a |
|
Configure a |
|
Configure an |
After you define an identity provider, you can use RBAC to define and apply permissions.
The following parameters are common to all identity providers:
Parameter | Description |
---|---|
|
The provider name is prefixed to provider user names to form an identity name. |
|
Defines how new identities are mapped to users when they log in. Enter one of the following values:
|
When adding or changing identity providers, you can map identities from the new
provider to existing users by setting the mappingMethod parameter to
add .
|
The following custom resource (CR) shows the parameters and default values that you use to configure an identity provider. This example uses the HTPasswd identity provider.
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
name: cluster
spec:
identityProviders:
- name: my_identity_provider (1)
mappingMethod: claim (2)
type: HTPasswd
htpasswd:
fileData:
name: htpass-secret (3)
1 | This provider name is prefixed to provider user names to form an identity name. |
2 | Controls how mappings are established between this provider’s
identities and User objects. |
3 | An existing secret containing a file generated using
htpasswd . |
Understand and apply role-based access control.
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 OpenShift Container Platform 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.
Authorization is managed using:
Authorization object | Description |
---|---|
Rules |
Sets of permitted verbs on a set of objects. For example,
whether a user or service account can |
Roles |
Collections of rules. You can associate, or bind, users and groups to multiple roles. |
Bindings |
Associations between users and/or groups with a role. |
There are two levels of RBAC roles and bindings that control authorization:
RBAC level | Description |
---|---|
Cluster RBAC |
Roles and bindings that are applicable across all projects. Cluster roles exist cluster-wide, and cluster role bindings can reference only cluster roles. |
Local RBAC |
Roles and bindings that are scoped to a given project. While local roles exist only in a single project, local role bindings can reference both cluster and local roles. |
A cluster role binding is a binding that exists at the cluster level. A role binding exists at the project level. The cluster role view must be bound to a user using a local role binding for that user to view the project. Create local roles only if a cluster role does not provide the set of permissions needed for a particular situation.
This two-level hierarchy allows reuse across multiple projects through the cluster roles while allowing customization inside of individual projects through local roles.
During evaluation, both the cluster role bindings and the local role bindings are used. For example:
Cluster-wide "allow" rules are checked.
Locally-bound "allow" rules are checked.
Deny by default.
OpenShift Container Platform includes a set of default cluster roles that you can bind to users and groups cluster-wide or locally.
It is not recommended to manually modify the default cluster roles. Modifications to these system roles can prevent a cluster from functioning properly. |
Default cluster role | Description |
---|---|
|
A project manager. If used in a local binding, an |
|
A user that can get basic information about projects and users. |
|
A super-user that can perform any action in any project. When bound to a user with a local binding, they have full control over quota and every action on every resource in the project. |
|
A user that can get basic cluster status information. |
|
A user that can get or view most of the objects but cannot modify them. |
|
A user that can modify most objects in a project but does not have the power to view or modify roles or bindings. |
|
A user that can create their own projects. |
|
A user who cannot make any modifications, but can see most objects in a project. They cannot view or modify roles or bindings. |
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 are illustrated below.
OpenShift Container Platform 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.
OpenShift Container Platform evaluates authorization by using the following steps:
The identity and the project-scoped action is used to find all bindings that apply to the user or their groups.
Bindings are used to locate all the roles that apply.
Roles are used to find all the rules that apply.
The action is checked against each rule to find a match.
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.
The cluster role bound to the project administrator is limited in a project through a local binding. It is not bound cluster-wide like the cluster roles granted to the cluster-admin or system:admin. Cluster roles are roles defined at the cluster level but can be bound either at the cluster level or at the project level. |
The default admin, edit, view, and cluster-reader cluster roles support cluster role aggregation, where the cluster rules for each role are dynamically updated as new rules are created. This feature is relevant only if you extend the Kubernetes API by creating custom resources.
A Kubernetes namespace provides a mechanism to scope resources in a cluster. The Kubernetes documentation has more information on namespaces.
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:
Object | Description |
---|---|
|
Pods, services, replication controllers, etc. |
|
Rules for which users can or cannot perform actions on objects. |
|
Quotas for each kind of object that can be limited. |
|
Service accounts act automatically with designated access to objects in the project. |
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 project