Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

13.5. Security

13.5.1. Security basics
링크 복사

Security is a critical component of OpenShift Container Platform deployments, particularly when running cloud-native applications.

You can enhance security for high-bandwidth network deployments by following key security considerations. By implementing these standards and best practices, you can strengthen security in most use cases.

13.5.1.1. 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 OpenShift Container Platform 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.

참고

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".

13.5.1.1.1. 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.

13.5.1.2. Security accounts overview
링크 복사

A service account is an OpenShift Container Platform account that allows a component to directly access the API. Service accounts are API objects that exist within each project. Service accounts provide a flexible way to control API access without sharing a regular user’s credentials.

You can use service accounts to apply role-based access control (RBAC) to pods. By assigning service accounts to workloads, such as pods and deployments, you can grant additional permissions, such as pulling from different registries. This also allows you to assign lower privileges to service accounts, reducing the security footprint of the pods that run under them.

For more information about service accounts, see "Understanding and creating service accounts".

13.5.1.3. Identity provider configuration
링크 복사

Configuring an identity provider is the first step in setting up users on the cluster. You can manage groups at the organizational level by using an identity provider.

The identity provider can pull in specific user groups that are maintained at the organizational level, rather than the cluster level. This allows you to add and remove users from groups that follow your organization’s established practices.

참고

You must set up a cron job to run frequently to pull any changes into the cluster.

You can use an identity provider to manage access levels for specific groups within your organization. For example, you can perform the following actions to manage access levels:

  • Assign the cluster-admin role to teams that require cluster-level privileges.
  • Grant application administrators specific privileges to manage only their respective projects.
  • Provide operational teams with view access across the cluster to enable monitoring without allowing modifications.

For information about configuring an identity provider, see "Understanding identity provider configuration".

13.5.1.4. Replacing the kubeadmin user with a cluster-admin user
링크 복사

The kubeadmin user with the cluster-admin privileges is created on every cluster by default. To enhance the cluster security, you can replace the kubeadmin user with a cluster-admin user and then disable or remove the kubeadmin user.

Prerequisites

  • You have created a user with cluster-admin privileges.
  • You have installed the OpenShift CLI (oc).
  • You have administrative access to a virtual vault for secure storage.

Procedure

  1. Create an emergency cluster-admin user by using the htpasswd identity provider. For more information, see "About htpasswd authentication".

  2. Assign the cluster-admin privileges to the new user by running the following command: 

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

  3. Verify the emergency user access:

    1. Log in to the cluster using the new emergency user.

    2. Confirm that the user has cluster-admin privileges by running the following command: 

      $ oc whoami

      Ensure the output shows the ID of the emergency user.

  4. Store the password or authentication key for the emergency user securely in a virtual vault.

    참고

    Follow the best practices of your organization for securing sensitive credentials.

  5. Disable or remove the kubeadmin user to reduce security risks by running the following command: 

    $ oc delete secrets kubeadmin -n kube-system

13.5.1.5. Security considerations
링크 복사

Workloads might handle sensitive data and demand high reliability. A single security vulnerability might lead to broader, cluster-wide compromises. With numerous components running on an OpenShift Container Platform cluster, you must secure each component to prevent any breach from escalating. Ensuring security across the entire infrastructure, including all components, is essential to maintaining the integrity of the network and avoiding vulnerabilities.

The following key security features are essential for all industries that handle sensitive data:

  • Security Context Constraints (SCCs): Provide granular control over pod security in the OpenShift Container Platform clusters.
  • Pod Security Admission (PSA): Kubernetes-native pod security controls.
  • Encryption: Ensures data confidentiality in high-throughput network environments.

13.5.1.6. Advancement of pod security in Kubernetes and OpenShift Container Platform
링크 복사

Kubernetes initially had limited pod security. When OpenShift Container Platform integrated Kubernetes, Red Hat added pod security through Security Context Constraints (SCCs). In Kubernetes version 1.3, PodSecurityPolicy (PSP) was introduced as a similar feature. However, Pod Security Admission (PSA) was introduced in Kubernetes version 1.21, which resulted in the deprecation of PSP in Kubernetes version 1.25.

PSA also became available in OpenShift Container Platform version 4.11. While PSA improves pod security, it lacks features provided by SCCs that are still necessary for certain use cases. Therefore, OpenShift Container Platform continues to support both PSA and SCCs.

13.5.1.7. Bare-metal infrastructure
링크 복사

Bare-metal infrastructure for OpenShift Container Platform clusters in telco and finance industries requires specific hardware and network configurations.

Hardware requirements
In several industries, such as telco and finance, clusters are primarily built on bare-metal hardware. This means that the Red Hat Enterprise Linux CoreOS (RHCOS) operating system is installed directly on the physical machines, without using virtual machines. This reduces network connectivity complexity, minimizes latency, and optimizes CPU usage for applications.
Network requirements
Networks in these industries sometimes require much higher bandwidth compared to standard IT networks. For example, Telco networks commonly use dual-port 25 GB connections or 100 GB network interface cards (NICs) to handle massive data throughput. Security is critical, requiring encrypted connections and secure endpoints to protect sensitive personal data.

13.5.1.8. Lifecycle management
링크 복사

Upgrades are critical for security. When a vulnerability is discovered, it is patched in the latest z-stream release. This fix is then rolled back through each lower y-stream release until all supported versions are patched. Releases that are no longer supported do not receive patches. Therefore, it is important to upgrade OpenShift Container Platform clusters regularly to stay within a supported release and ensure they remain protected against vulnerabilities.

For more information about lifecycle management and upgrades, see "Upgrading OpenShift Container Platform clusters".

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동