2.10. 컨테이너 플랫폼 보안
OpenShift Container Platform 및 쿠버네티스 API는 대규모 컨테이너 관리 자동화의 핵심입니다. API는 다음을 수행하는 데 사용됩니다.
- Pod, 서비스 및 복제 컨트롤러의 데이터를 검증하고 구성합니다.
- 수신 요청에서 프로젝트의 유효성을 확인하고 다른 주요 시스템 구성요소에서 트리거를 호출합니다.
쿠버네티스를 기반으로 하는 OpenShift Container Platform의 보안 관련 기능은 다음과 같습니다.
- 역할 기반 액세스 제어 및 네트워크 정책을 결합하여 컨테이너를 여러 수준으로 격리하는 멀티 테넌시.
- API와 API에 요청하는 규칙 사이의 경계를 형성하는 승인 플러그인입니다.
OpenShift Container Platform에서는 Operator를 사용하여 쿠버네티스 수준 보안 기능 관리를 자동화하고 단순화합니다.
2.10.1. 멀티 테넌시로 컨테이너 격리
다중 테넌트를 사용하면 여러 사용자가 소유하고 여러 호스트와 네임스페이스에서 실행되는 OpenShift Container Platform 클러스터의 애플리케이션을 서로 분리하고 외부 공격으로부터 격리된 상태로 유지할 수 있습니다. 쿠버네티스 네임스페이스에 역할 기반 액세스 제어(RBAC)를 적용하여 멀티 테넌시를 확보합니다.
쿠버네티스에서 네임스페이스는 다른 애플리케이션과 분리된 방식으로 애플리케이션을 실행할 수 있는 영역입니다. OpenShift Container Platform에서는 SELinux에서 MCS 레이블링을 포함하여 주석을 추가하고 이러한 확장 네임스페이스를 프로젝트로 식별하여 네임스페이스를 사용하고 확장합니다. 프로젝트 범위 내에서 서비스 계정, 정책, 제약 조건 및 기타 다양한 오브젝트를 포함하여 자체 클러스터 리소스를 유지 관리할 수 있습니다.
선택된 사용자가 프로젝트에 액세스할 수 있도록 RBAC 오브젝트가 해당 프로젝트에 할당됩니다. 이 인증에서는 규칙, 역할 및 바인딩 양식을 사용합니다.
- 규칙을 통해서는 사용자가 프로젝트에서 생성하거나 액세스할 수 있는 대상을 정의합니다.
- 역할은 선택한 사용자 또는 그룹에 바인딩할 수 있는 규칙 컬렉션입니다.
- 바인딩을 통해서는 사용자 또는 그룹과 역할 간의 연결을 정의합니다.
로컬 RBAC 역할 및 바인딩은 사용자 또는 그룹을 특정 프로젝트에 연결합니다. 클러스터 RBAC는 클러스터 전체 역할 및 바인딩을 클러스터의 모든 프로젝트에 연결할 수 있습니다. admin, basic-user, cluster-admin 및 cluster-status 액세스를 제공하기 위해 지정할 수 있는 기본 클러스터 역할이 있습니다.
2.10.2. 승인 플러그인으로 컨트롤 플레인 보호
RBAC는 사용자와 그룹 간의 액세스 규칙을 제어하지만 승인 플러그인 은 OpenShift Container Platform 마스터 API에 대한 액세스를 정의합니다. 승인 플러그인은 다음으로 구성된 규칙 체인을 형성합니다.
- 기본 승인 플러그인: OpenShift Container Platform 컨트롤 플레인의 구성 요소에 적용되는 기본 정책 및 리소스 제한 세트를 구현합니다.
- 변경 승인 플러그인: 이 플러그인은 승인 체인을 동적으로 확장합니다. 이 플러그인은 웹 후크 서버를 호출하고 요청을 인증하며 선택된 리소스를 수정할 수 있습니다.
- 승인 플러그인 검증: 선택한 리소스에 대한 요청을 검증하고 요청을 검증하고 리소스가 다시 변경되지 않는지 확인할 수 있습니다.
API 요청은 체인의 승인 플러그인을 통과하며 실패로 인해 요청이 거부됩니다. 각 승인 플러그인은 특정 리소스와 연결되어 있으며 해당 리소스에 대한 요청에만 응답합니다.
2.10.2.1. SCC(보안 컨텍스트 제약 조건)
SCC(보안 컨텍스트 제약 조건 )를 사용하여 시스템에 적용하기 위해 Pod를 실행해야 하는 조건 집합을 정의할 수 있습니다.
SCC에서 관리할 수 있는 몇 가지 요소는 다음과 같습니다.
- 권한이 있는 컨테이너 실행
- 컨테이너가 추가하도록 요청할 수 있는 기능
- 호스트 디렉터리를 볼륨으로 사용
- 컨테이너의 SELinux 컨텍스트
- 컨테이너 사용자 ID
필수 권한이 있으면 필요한 경우 기본 SCC 정책의 허용 범위를 넓게 조정할 수 있습니다.
2.10.2.2. 서비스 계정에 역할 부여
사용자에게 역할 기반 액세스 권한이 할당된 방식과 동일하게 서비스 계정에 역할을 할당할 수 있습니다. 프로젝트마다 3개의 기본 서비스 계정이 생성됩니다. 서비스 계정:
- 특정 프로젝트로 범위가 제한됨
- 프로젝트에서 이름 파생
- OpenShift Container Registry에 액세스하기 위해 API 토큰 및 인증서가 자동으로 할당됨
플랫폼 구성요소와 관련된 서비스 계정의 키는 자동으로 순환됩니다.
2.10.3. 인증 및 권한 부여
2.10.3.1. OAuth를 사용하여 액세스 제어
컨테이너 플랫폼 보안을 위해 인증 및 권한 부여를 통해 API 액세스 제어를 사용할 수 있습니다. OpenShift Container Platform 마스터에는 내장 OAuth 서버가 포함되어 있습니다. 사용자가 API에 자신을 인증하기 위해 OAuth 액세스 토큰을 가져올 수 있습니다.
관리자는 LDAP, GitHub 또는 Google과 같은 ID 공급자를 사용하여 인증할 OAuth를 구성할 수 있습니다. ID 공급자는 기본적으로 새 OpenShift Container Platform 배포에 사용되지만 초기 설치 시 또는 설치 후 이 공급자를 구성할 수 있습니다.
2.10.3.2. API 액세스 제어 및 관리
애플리케이션에는 관리가 필요한 끝점이 서로 다른 여러 개의 독립적인 API 서비스가 있을 수 있습니다. OpenShift Container Platform에는 3scale API 게이트웨이의 컨테이너화된 버전이 포함되어 있으므로 API를 관리하고 액세스를 제어할 수 있습니다.
3scale에서는 API 인증 및 보안을 위한 다양한 표준 옵션을 제공합니다. 이 옵션은 표준 API 키, 애플리케이션 ID와 키 쌍 및 OAuth 2.0과 함께 인증서를 발행하고 액세스를 제어하기 위해 조합하여 사용하거나 단독으로 사용할 수 있습니다.
특정 끝점, 방법 및 서비스에 대한 액세스를 제한하고 사용자 그룹의 액세스 정책을 적용할 수 있습니다. 애플리케이션 계획을 통해 API 사용에 대한 속도 제한을 설정하고 개발자 그룹의 트래픽 흐름을 제어할 수 있습니다.
컨테이너화된 3scale API 게이트웨이인 APIcast v2를 사용하는 방법에 관한 자습서는 3scale 설명서의 Red Hat OpenShift에서 APIcast 실행을 참조하십시오.
2.10.3.3. Red Hat Single Sign-On
Red Hat Single Sign-On 서버를 사용하면 SAML 2.0, OpenID Connect 및 OAuth 2.0을 포함한 표준을 기반으로 웹 싱글 사인온 기능을 제공하여 애플리케이션을 보호할 수 있습니다. 서버는 SAML 또는 OpenID Connect 기반 ID 공급자(IdP)의 역할을 하며 엔터프라이즈 사용자 디렉터리 또는 타사 ID 공급자와 함께 표준 기반 토큰을 사용하여 ID 정보 및 애플리케이션을 중재할 수 있습니다. Red Hat Single Sign-On을 Microsoft Active Directory 및 Red Hat Enterprise Linux Identity Management를 포함한 LDAP 기반 디렉터리 서비스와 통합할 수 있습니다.
2.10.3.4. 보안 셀프 서비스 웹 콘솔
OpenShift Container Platform에서는 팀이 권한없이 다른 환경에 액세스하지 못하도록 셀프 서비스 웹 콘솔을 제공합니다. OpenShift Container Platform에서는 다음을 제공하여 보안 멀티 테넌트 마스터를 보장합니다.
- 마스터에 액세스하는 데 TLS(Transport Layer Security)를 사용합니다.
- API 서버에 액세스하는 데 X.509 인증서 또는 OAuth 액세스 토큰을 사용합니다.
- 프로젝트에 할당량을 지정하면 불량 토큰으로 인한 피해가 제한됩니다
- etcd 서비스는 클러스터에 직접 노출되지 않습니다
2.10.4. 플랫폼의 인증서 관리
OpenShift Container Platform의 프레임워크에는 TLS 인증서를 통한 암호화를 활용하는 REST 기반 HTTPS 통신을 사용하는 여러 구성요소가 있습니다. OpenShift Container Platform의 설치 관리자는 설치 중에 이러한 인증서를 구성합니다. 이 트래픽을 생성하는 몇 가지 기본 구성요소가 있습니다.
- 마스터(API 서버 및 컨트롤러)
- etcd
- 노드
- 레지스트리
- 라우터
2.10.4.1. 사용자 정의 인증서 구성
초기 설치 중 또는 인증서를 재배포할 때 API 서버와 웹 콘솔의 공개 호스트 이름에 맞게 사용자 정의 제공 인증서를 구성할 수 있습니다. 사용자 정의 CA도 사용할 수 있습니다.
