17.5. 보안

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

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

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

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

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

운영 RBAC 고려 사항

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

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

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

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

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

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

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

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

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

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

다음과 같은 주요 보안 기능은 통신에 필수적입니다.

처음에는 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 보안이 향상되지만 telco 사용 사례에는 여전히 필요한 SCC에서 제공하는 일부 기능이 없습니다. 따라서 OpenShift Container Platform은 PSA 및 SCC를 계속 지원합니다.

CNF(클라우드 네이티브 네트워크 기능) 배포에는 다음과 같은 주요 영역이 포함되어 있습니다.

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

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

NFV(네트워크 기능)는 목적으로 구축된 하드웨어 장치인 물리적 네트워크 기능(PNF)으로 시작되었습니다. 시간이 지남에 따라 PNF는 CPU, 메모리, 스토리지 및 네트워크와 같은 리소스를 제어하는 동시에 기능을 가상화한 VNF(가상 네트워크 기능)로 발전했습니다.

기술 발전으로 VNF는 클라우드 네이티브 네트워크 기능(CNF)으로 전환되었습니다. CNF는 가볍고 안전하며 확장 가능한 컨테이너에서 실행됩니다. 루트가 아닌 실행과 최소한의 호스트 간섭을 포함하여 엄격한 제한을 적용하여 보안 및 성능을 향상시킵니다.

pNFS는 간섭 없이 독립적으로 작동할 수 있는 무제한 루트 액세스 권한을 가지고 있었습니다. VNF로 전환하면서 리소스 사용량이 제어되었지만 프로세스는 가상 머신 내에서 root로 실행될 수 있었습니다. 반면 CNF는 다른 컨테이너 또는 호스트 운영 체제와의 간섭을 방지하기 위해 루트 액세스 및 컨테이너 기능을 제한합니다.

CNF로 마이그레이션하는 주요 문제는 다음과 같습니다.