13.5. 보안


13.5.1. 보안 기본 사항

보안은 특히 클라우드 네이티브 애플리케이션을 실행할 때 OpenShift Container Platform 배포의 중요한 구성 요소입니다.

다음과 같은 주요 보안 고려 사항에 따라 대역폭이 높은 네트워크 배포에 대한 보안을 강화할 수 있습니다. 이러한 표준 및 모범 사례를 구현하면 대부분의 사용 사례에서 보안을 강화할 수 있습니다.

13.5.1.1. RBAC 개요

RBAC(역할 기반 액세스 제어) 오브젝트에 따라 사용자가 프로젝트 내에서 지정된 작업을 수행할 수 있는지가 결정됩니다.

클러스터 관리자는 클러스터 역할 및 바인딩을 사용하여 OpenShift Container Platform 플랫폼 자체 및 모든 프로젝트에 대해 다양한 액세스 수준을 보유한 사용자를 제어할 수 있습니다.

개발자는 로컬 역할 및 바인딩을 사용하여 프로젝트에 액세스할 수 있는 사용자를 제어할 수 있습니다. 권한 부여는 인증과 별도의 단계이며, 작업을 수행하는 사용자의 ID를 결정하는 것이 더 중요합니다.

권한 부여는 다음 권한 부여 오브젝트를 사용하여 관리됩니다.

규칙
특정 오브젝트에 대해 허용된 작업 세트입니다. 예를 들어 규칙은 사용자 또는 서비스 계정에서 Pod를 생성할 수 있는지 여부를 결정할 수 있습니다. 각 규칙은 API 리소스, 해당 API 내의 리소스 및 허용된 작업을 지정합니다.
역할

사용자 또는 그룹이 수행할 수 있는 작업을 정의하는 규칙 컬렉션입니다. 규칙을 여러 사용자 또는 그룹에 연결하거나 바인딩할 수 있습니다. 역할 파일에는 해당 역할에 허용된 작업 및 리소스를 지정하는 하나 이상의 규칙이 포함될 수 있습니다.

역할은 다음 유형으로 분류됩니다.

  • 클러스터 역할은 클러스터 수준에서 정의할 수 있습니다. 단일 네임 스페이스에 연결되어 있지 않습니다. 사용자, 그룹 또는 서비스 계정에 바인딩할 때 모든 네임스페이스 또는 특정 네임스페이스에 적용할 수 있습니다.
  • 프로젝트 역할은 특정 네임스페이스 내에서 생성할 수 있으며 해당 네임스페이스에만 적용됩니다. 특정 사용자에게 권한을 할당하여 해당 네임스페이스 내에서 역할 및 역할 바인딩을 생성하여 다른 네임스페이스에 영향을 미치지 않도록 할 수 있습니다.
바인딩

역할이 있는 사용자와 그룹 간 연결입니다. 역할 바인딩을 생성하여 역할의 규칙을 특정 사용자 ID 또는 그룹에 연결할 수 있습니다. 그러면 역할과 사용자 또는 그룹을 결합하여 수행할 수 있는 작업을 정의합니다.

참고

사용자 또는 그룹에 둘 이상의 역할을 바인딩할 수 있습니다.

RBAC에 대한 자세한 내용은 "RBAC를 사용하여 권한 정의 및 적용"을 참조하십시오.

13.5.1.1.1. 운영 RBAC 고려 사항

운영 오버헤드를 줄이려면 여러 클러스터에서 개별 사용자 ID를 처리하는 대신 그룹을 통해 액세스를 관리합니다. 조직 수준에서 그룹을 관리하면 액세스 제어를 간소화하고 조직 전체의 관리를 간소화할 수 있습니다.

13.5.1.2. 보안 계정 개요

서비스 계정은 구성 요소가 API에 직접 액세스할 수 있는 OpenShift Container Platform 계정입니다. 서비스 계정은 각 프로젝트 내에 존재하는 API 오브젝트입니다. 서비스 계정을 사용하면 일반 사용자의 자격 증명을 공유하지 않고도 API 액세스 권한을 유연하게 제어할 수 있습니다.

서비스 계정을 사용하여 Pod에 역할 기반 액세스 제어(RBAC)를 적용할 수 있습니다. Pod 및 배포와 같은 워크로드에 서비스 계정을 할당하면 다른 레지스트리에서 가져오는 것과 같은 추가 권한을 부여할 수 있습니다. 또한 서비스 계정에 더 낮은 권한을 할당하여 해당 Pod에서 실행되는 Pod의 보안 공간을 줄일 수 있습니다.

서비스 계정에 대한 자세한 내용은 "서비스 계정 이해 및 생성"을 참조하십시오.

13.5.1.3. ID 공급자 구성

ID 공급자를 구성하는 것은 클러스터에서 사용자를 설정하는 첫 번째 단계입니다. ID 공급자를 사용하여 조직 수준에서 그룹을 관리할 수 있습니다.

ID 공급자는 클러스터 수준이 아닌 조직 수준에서 유지 관리되는 특정 사용자 그룹을 가져올 수 있습니다. 이를 통해 조직의 기존 사례를 따르는 그룹에서 사용자를 추가하고 제거할 수 있습니다.

참고

클러스터의 변경 사항을 가져오려면 자주 실행하도록 cron 작업을 설정해야 합니다.

ID 공급자를 사용하여 조직 내의 특정 그룹에 대한 액세스 수준을 관리할 수 있습니다. 예를 들어 다음 작업을 수행하여 액세스 수준을 관리할 수 있습니다.

  • 클러스터 수준 권한이 필요한 팀에 cluster-admin 역할을 할당합니다.
  • 애플리케이션 관리자에게 해당 프로젝트만 관리할 수 있는 특정 권한을 부여합니다.
  • 운영 팀에 클러스터 전체의 보기 액세스 권한을 제공하여 수정을 허용하지 않고 모니터링을 활성화합니다.

ID 공급자 구성에 대한 자세한 내용은 "ID 공급자 구성 이해"를 참조하십시오.

13.5.1.4. kubeadmin 사용자를 cluster-admin 사용자로 교체

cluster-admin 권한이 있는 kubeadmin 사용자는 기본적으로 모든 클러스터에서 생성됩니다. 클러스터 보안을 강화하기 위해 kubeadmin 사용자를 cluster-admin 사용자로 교체한 다음 kubeadmin 사용자를 비활성화하거나 제거할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자를 생성했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 보안 스토리지를 위해 가상 자격 증명 모음에 대한 관리자 액세스 권한이 있습니다.

프로세스

  1. htpasswd ID 공급자를 사용하여 긴급 cluster-admin 사용자를 생성합니다. 자세한 내용은 " htpasswd 인증 정보"를 참조하십시오.
  2. 다음 명령을 실행하여 새 사용자에게 cluster-admin 권한을 할당합니다.

    $ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>
  3. 긴급 사용자 액세스를 확인합니다.

    1. 새 긴급 사용자를 사용하여 클러스터에 로그인합니다.
    2. 다음 명령을 실행하여 사용자에게 cluster-admin 권한이 있는지 확인합니다.

      $ oc whoami

      출력에 긴급 사용자의 ID가 표시되는지 확인합니다.

  4. 긴급 사용자의 암호 또는 인증 키를 가상 자격 증명 모음에 안전하게 저장합니다.

    참고

    중요한 인증 정보를 보호하려면 조직의 모범 사례를 따르십시오.

  5. 다음 명령을 실행하여 kubeadmin 사용자를 비활성화하거나 제거하여 보안 위험을 줄입니다.

    $ oc delete secrets kubeadmin -n kube-system

13.5.1.5. 보안 고려 사항

워크로드는 민감한 데이터를 처리하고 높은 신뢰성을 필요로 할 수 있습니다. 단일 보안 취약점으로 인해 클러스터 전체에서 광범위한 손상이 발생할 수 있습니다. OpenShift Container Platform 클러스터에서 다양한 구성 요소가 실행되므로 각 구성 요소를 보호하여 위반이 발생하지 않도록 해야 합니다. 모든 구성 요소를 포함한 전체 인프라 전반에 걸쳐 보안을 보장하는 것은 네트워크의 무결성을 유지하고 취약점을 방지하는 데 필수적입니다.

다음과 같은 주요 보안 기능은 민감한 데이터를 처리하는 모든 산업에 필수적입니다.

  • SCC(보안 컨텍스트 제약 조건): OpenShift Container Platform 클러스터에서 Pod 보안을 세부적으로 제어합니다.
  • PSA(Pod Security Admission): Kubernetes 네이티브 Pod 보안 제어
  • 암호화: 처리량이 높은 네트워크 환경에서 데이터 기밀성을 보장합니다.

13.5.1.6. Kubernetes 및 OpenShift Container Platform의 Pod 보안 개선

처음에는 Kubernetes에 제한된 Pod 보안이 있었습니다. OpenShift Container Platform 통합 Kubernetes는 Red Hat에서 SCC(보안 컨텍스트 제약 조건)를 통해 Pod 보안을 추가했습니다. Kubernetes 버전 1.3에서는 PodSecurityPolicy (PSP)가 유사한 기능으로 도입되었습니다. 그러나 PSA(Pod Security Admission)가 Kubernetes 버전 1.21에 도입되어 Kubernetes 버전 1.25에서 PSP가 더 이상 사용되지 않습니다.

PSA는 OpenShift Container Platform 버전 4.11에서도 사용할 수 있습니다. PSA는 Pod 보안을 개선하는 반면 특정 사용 사례에는 여전히 필요한 SCC에서 제공하는 기능이 없습니다. 따라서 OpenShift Container Platform은 PSA 및 SCC를 계속 지원합니다.

13.5.1.7. 베어 메탈 인프라

통신 업계의 OpenShift Container Platform 클러스터용 베어 메탈 인프라에는 특정 하드웨어 및 네트워크 구성이 필요합니다.

하드웨어 요구 사항
통신 및 재무와 같은 여러 업계에서 클러스터는 주로 베어 메탈 하드웨어를 기반으로 구축됩니다. 즉, 가상 머신을 사용하지 않고 RHCOS(Red Hat Enterprise Linux CoreOS) 운영 체제가 물리적 머신에 직접 설치됩니다. 이렇게 하면 네트워크 연결의 복잡성이 줄어들고 대기 시간을 최소화하고 애플리케이션의 CPU 사용량을 최적화합니다.
네트워크 요구 사항
이러한 업계의 네트워크는 표준 IT 네트워크에 비해 훨씬 더 높은 대역폭을 필요로 하는 경우가 있습니다. 예를 들어 Telco 네트워크는 일반적으로 듀얼 포트 25GB 연결 또는 100GB NIC(네트워크 인터페이스 카드)를 사용하여 대규모 데이터 처리량을 처리합니다. 보안은 매우 중요하며 민감한 개인 데이터를 보호하기 위해 암호화된 연결 및 보안 끝점이 필요합니다.

13.5.1.8. 라이프사이클 관리

업그레이드는 보안을 위해 중요합니다. 취약점이 발견되면 최신 z-stream 릴리스에서 패치됩니다. 그런 다음 이 수정 사항은 지원되는 모든 버전이 패치될 때까지 각 하위 y-stream 릴리스를 통해 롤백됩니다. 더 이상 지원되지 않는 릴리스는 패치를 받지 않습니다. 따라서 지원되는 릴리스를 유지하고 취약점으로부터 계속 보호되도록 OpenShift Container Platform 클러스터를 정기적으로 업그레이드하는 것이 중요합니다.

라이프사이클 관리 및 업그레이드에 대한 자세한 내용은 "OpenShift Container Platform 클러스터 업그레이드"를 참조하십시오.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

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

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

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

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동