This is a cache of https://docs.openshift.com/dedicated/3/product_security/red_hat_responsibilities/access_control.html. It is a snapshot of the page at 2024-11-21T05:05:05.479+0000.
Access Control - Red Hat Responsibilities | Security | OpenShift Dedicated 3
    Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history bug_report picture_as_pdf
×

Access Control

Authentication

Authentication for the cluster is configured as part of the on-boarding process. OpenShift Dedicated includes a built-in OAuth server. The OAuth server generates two kinds of tokens:

  • Access tokens are longer-lived tokens that grant access to the API.

  • Authorize codes are short-lived tokens; their only use is to be exchanged for an access token.

You can integrate your cluster with various identity providers at installation time, or later by opening a support case.

Supported identity providers include:

  • Keystone

  • Google Auth

  • GitHub OAuth

  • OpenID Connect

  • LDAP

Learn more about authentication in OpenShift Dedicated.

Encryption and Key Management

By default, a new internal public key infrastructure (PKI) is created for each deployment of OpenShift Dedicated. The internal PKI uses 2048-bit RSA keys and SHA-256 signatures. The platform PKI is dedicated to managing the platform components’ certificates. This includes: the master API, controllers, and nodes. Also, by default, most of the infrastructure components deployed at install time are signed by this CA; for example: metrics, logging, and the default router wildcard certificate. By default, the PKI CA related files are stored on all OpenShift masters in the /etc/origin/master directory. The etcd cluster has its own PKI.

Encryption keys for persistent volumes are managed by the Key Management service of the underlying infrastructure solution.

Authorization

Learn how authorization is managed.

Role-based Access Control (RBAC)

There are two levels of Role-based Access Control (RBAC) roles and bindings that control authorization:

  • Cluster RBAC: Roles and bindings that are applicable across all projects. Roles that exist cluster-wide are considered cluster roles. Cluster role bindings can only reference cluster roles.

  • Local RBAC: Roles and bindings that are scoped to a given project. Roles that exist only in a project are considered local roles. Local role bindings can reference both cluster and local roles.

Cluster Roles and Local Roles

Roles are collections of policy rules, which are sets of permitted verbs that can be performed on a set of resources. OpenShift Dedicated includes a set of default cluster roles that can be bound to users and groups cluster wide or locally.

For more information on the roles supported on the cluster, see Cluster Roles and Local Roles.

Learn about managing RBAC.

Security Context Constraints

Security context constraints allow administrators to control permissions for pods. As an OpenShift Dedicated cluster administrator, you can list and view details for SCCs, but cannot edit or delete the pre-configured SCCs.

Learn about managing Security Context Constraints.

Red Hat Personnel Access

Tiered access is how Red Hat grants internal personnel limited access to OpenShift Dedicated environments.

  • Users can write and submit read-only scripts that allow a subset of non-secret data to be read from a cluster. For example, they can read node log files or pod names, but cannot read secrets, tokens, or keys. Once these scripts are reviewed and approved, developers who are called on to help diagnose and debug problems on the clusters can run them at any time. This tier is also used by the Red Hat Customer Experience and Engagement team to provide support for customer cases.

  • Users granted this level of access are given OpenShift cluster-reader access. This level of access is enabled only when absolutely needed and after the customer has approved access to debug a specific issue.

  • A very limited number of vetted users have root access on cluster nodes, including full (system:admin) command line access to the OpenShift cluster. This is limited to SRE Operations personnel responsible for the ongoing support and maintenance of the platform.

Access to all tiers is tracked and further gated by our internal ticketing system. Access to any tier first requires specific manual approval from both group managers and SRE management. All planned maintenance events are scheduled and logged through the OpenShift Dedicated Portal and the event log is available for internal audit at any time.