17.5. 보안

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

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

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

권한 부여는 다음 권한 부여 객체를 사용하여 관리됩니다.

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

운영 RBAC 고려 사항

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

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

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

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

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

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

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

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

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

통신사 업무는 방대한 양의 민감한 데이터를 처리하며 높은 안정성을 요구합니다. 단일 보안 취약점으로 인해 클러스터 전체에 더 큰 손상이 발생할 수 있습니다. 단일 노드 OpenShift 클러스터에서 수많은 구성 요소가 실행되므로 각 구성 요소를 보호하여 침해가 확대되는 것을 방지해야 합니다. 모든 구성 요소를 포함한 전체 인프라의 보안을 보장하는 것은 통신사 네트워크의 무결성을 유지하고 취약성을 방지하는 데 필수적입니다.

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

쿠버네티스는 처음에는 포드 보안이 제한적이었습니다. OpenShift Container Platform이 Kubernetes를 통합했을 때 Red Hat은 SCC(Security Context Constraints)를 통해 포드 보안을 추가했습니다. Kubernetes 버전 1.3에서는 PodSecurityPolicy (PSP)가 유사한 기능으로 도입되었습니다. 그러나 Kubernetes 버전 1.21에서 Pod Security Admission(PSA)이 도입되었고, 이로 인해 Kubernetes 버전 1.25에서 PSP가 더 이상 사용되지 않게 되었습니다.

PSA는 OpenShift Container Platform 버전 4.11에서도 사용할 수 있게 되었습니다. PSA는 포드 보안을 개선하지만, 통신사 사용 사례에 여전히 필요한 SCC가 제공하는 일부 기능이 부족합니다. 따라서 OpenShift Container Platform은 PSA와 SCC를 모두 계속 지원합니다.

클라우드 기반 네트워크 기능(CNF) 배포에는 다음과 같은 주요 영역이 포함됩니다.

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

수명 주기 관리 및 업그레이드에 대한 자세한 내용은 "통신사 핵심 CNF 클러스터 업그레이드"를 참조하세요.

네트워크 기능(NF)은 원래 물리적 네트워크 기능(PNF)으로 시작되었는데, 이는 독립적으로 작동하는 특수 목적의 하드웨어 장치였습니다. 시간이 지남에 따라 PNF는 CPU, 메모리, 스토리지, 네트워크 등의 리소스를 제어하면서 기능을 가상화하는 가상 네트워크 기능(VNF)으로 발전했습니다.

기술이 더욱 발전함에 따라 VNF는 클라우드 기반 네트워크 기능(CNF)으로 전환되었습니다. CNF는 가볍고 안전하며 확장 가능한 컨테이너에서 실행됩니다. 이들은 보안과 성능을 강화하기 위해 루트가 아닌 실행과 최소한의 호스트 간섭을 포함한 엄격한 제한을 시행합니다.

PNF는 간섭 없이 독립적으로 작동할 수 있는 무제한 루트 접근 권한을 가졌습니다. VNF로 전환하면서 리소스 사용이 제어되었지만 프로세스는 여전히 가상 머신 내에서 루트로 실행될 수 있습니다. 이와 대조적으로 CNF는 루트 액세스를 제한하고 컨테이너 기능을 제한하여 다른 컨테이너나 호스트 운영 체제와의 간섭을 방지합니다.

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

Red Hat Enterprise Linux CoreOS(RHCOS)는 주요 면에서 Red Hat Enterprise Linux(RHEL)와 다릅니다. 자세한 내용은 "RHCOS 정보"를 참조하세요.

통신사 관점에서 볼 때 가장 큰 차이점은 Machine Config Operator를 통해 업데이트되는 rpm-ostree 의 제어입니다.

RHCOS는 OpenShift Container Platform의 Pod에 사용된 것과 동일한 변경 불가능한 디자인을 따릅니다. 이렇게 하면 클러스터 전체에서 운영 체제의 일관성이 유지됩니다. RHCOS 아키텍처에 대한 자세한 내용은 "Red Hat Enterprise Linux CoreOS(RHCOS)"를 참조하세요.

보안을 유지하면서 호스트를 효과적으로 관리하려면 가능하면 직접 액세스를 피하세요. 대신 다음 방법을 사용하여 호스트를 관리할 수 있습니다.

호스트 보안을 유지 관리하는 데 통합된 다음 RHCOS 보안 메커니즘을 검토하십시오.

호스트에 대한 직접 액세스는 호스트를 수정하거나 액세스해서는 안 되는 Pod에 액세스하지 않도록 제한해야 합니다. 호스트에 직접 액세스해야 하는 사용자의 경우 LDAP에서 SSSD와 같은 외부 인증기를 사용하여 액세스를 관리하는 것이 좋습니다. 이렇게 하면 Machine Config Operator를 통해 클러스터 전체에서 일관성을 유지할 수 있습니다.

다음 방법을 사용하여 클러스터의 노드에 연결할 수 있습니다.

Linux 기능은 프로세스가 호스트 시스템에서 수행할 수 있는 작업을 정의합니다. 기본적으로 보안 조치가 적용되지 않는 한 포드에는 여러 가지 기능이 부여됩니다. 기본 기능은 다음과 같습니다.

보안 컨텍스트 제약 조건(SCC)을 구성하여 포드가 수신할 수 있는 기능을 수정할 수 있습니다.