1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/security-rbac-overview.adoc

40 lines
2.5 KiB
Plaintext

// Module included in the following assemblies:
//
// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
:_mod-docs-content-type: CONCEPT
[id="security-rbac-overview_{context}"]
= RBAC overview
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 {product-title} platform itself and all projects.
Developers can use local roles and bindings to control who has access to their projects. Authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.
Authorization is managed using the following authorization objects:
Rules:: Sets of permitted actions on specific objects. For example, a rule can determine whether a user or service account can create pods. Each rule specifies an API resource, the resource within that API, and the allowed action.
Roles:: Collections of rules that define what actions users or groups can perform. You can associate or bind rules to multiple users or groups. A role file can contain one or more rules that specify the actions and resources allowed for that role.
+
Roles are categorized into the following types:
* Cluster roles can be defined at the cluster level. They are not tied to a single namespace. They can apply across all namespaces or specific namespaces when you bind them to users, groups, or service accounts.
* Project roles can be created within a specific namespace, and they only apply to that namespace. You can assign permissions to specific users to create roles and role bindings within their namespace, ensuring they do not affect other namespaces.
Bindings:: Associations between users and groups with a role. You can create a role binding to connect the rules in a role to a specific user ID or group. This brings together the role and the user or group, defining what actions they can perform.
+
[NOTE]
====
You can bind more than one role to a user or group.
====
For more information on RBAC, see "Using RBAC to define and apply permissions".
[discrete]
[id="security-operational-rbac-considerations_{context}"]
== Operational RBAC considerations
To reduce operational overhead, manage access through groups rather than handling individual user IDs across multiple clusters. By managing groups at an organizational level, you can streamline access control and simplify administration across your organization.