보안 컨텍스트 제약 조건
개요
OpenShift의 Pods는 보안 컨텍스트 제약 조건에 따라 권한을 부여받습니다. 보안 컨텍스트 제약 조건은 _SCC_로 흔히 약칭되며, 대규모 배포에 사용하기 위한 역할 기반 접근 제어 메커니즘을 단순화합니다. 관리자는 보안 컨텍스트 제약 조건의 작동 방식과 OpenShift 내에서의 위치에 대한 더 많은 통찰력을 얻기 위해 업스트림 문서를 참조할 수 있습니다.
관리자는 다음 리소스도 참조할 수 있습니다:
GitLab 배포 내의 보안 컨텍스트 제약 조건
gitlab-controller-manager
배포는 Operator 프로세스를 포함하는 pod를 생성하고 관리합니다. 이 pod와 생성 및 관리하는 다른 pod는 restricted 보안 컨텍스트 제약 조건으로 실행됩니다.
Operator는 GitLab 응용 프로그램에서 요구하는 모든 리소스를 관리할 수 있도록 강력한 권한을 가진 ServiceAccount를 사용합니다.
Operator는 Cloud Native GitLab을 구성하는 구성 요소 서비스들을 관리합니다. 이는 Operator가 지정한 UID에 부합하지 않는 pod를 적극적으로 종료하고 교체합니다. 이 메커니즘은 최소 권한 원칙을 시행합니다.
GitLab 응용 프로그램 사용자 정의 리소스 정의
Operator에 의해 배포된 pod는 GitLab 사용자 정의 리소스를 충족하기 위해 non-root-v2 보안 컨텍스트 제약 조건을 사용합니다. 제3자 운영자 및 리소스에 대한 보안 컨텍스트 제약 조건은 다음 섹션에서 다룹니다.
gitlab-app-nonroot
ServiceAccounts는 부여된 권한이 없으며, 오직 GitLab 응용 프로그램 pod에 nonroot-v2 보안 컨텍스트 제약 조건을 바인딩하기 위해 존재합니다.
보안 컨텍스트 제약 조건은 GitLab 응용 프로그램의 전체 읽기/쓰기 동작이 OpenShift 보안 모델 내에서 검증됨에 따라 향후 릴리스에서 강화될 것입니다.
sudo
로 수행된 Linux 패키지 설치 작업이 OpenShift 및 기본 Kubernetes 엔진에 의해 처리된다는 점을 유의해야 합니다. Pods는 개별 서비스로, Linux 패키지 설치에서는 애플리케이션 전용 사용자로 권한을 줄입니다. Operator는 예상 UID로 운영되지 않는 pod를 종료합니다.
제3자 리소스 정의
인그레스 컨트롤러
GitLab은 Cloud Native GitLab을 배포할 때 nginx-ingress-controller
를 사용한 배포를 권장하고 테스트합니다. 이는 자체 nginx-ingress-scc
보안 컨텍스트 제약 조건을 사용합니다.
대체 인그레스 컨트롤러를 선택하는 경우, 해당 문서를 참조하여 보안 컨텍스트 제약 조건에 대해 자세히 알아보십시오.
SSL 암호화
Operator는 GitLab 응용 프로그램 전반에 걸쳐 SSL 인증서를 관리하기 위해 cert-manager-operator from JetStack를 배포합니다.
cert-manager-operator는 직접적으로 안전한 컨텍스트 제약 조건을 설정하지 않으므로, OpenShift는 기본적으로 restricted 보안 컨텍스트 제약 조건을 적용합니다.