보안 컨텍스트 제약 조건

개요

OpenShift의 Pod는 보안 컨텍스트 제약 조건에 기반한 권한을 받습니다. 보안 컨텍스트 제약 조건은 자주 _SCC_로 약칭되며 대규모 배포에서 역할 기반 액세스 제어 메커니즘을 간소화합니다. 관리자는 OpenShift에서 보안 컨텍스트 제약 조건이 작동하는 방식과 OpenShift 내에서의 위치를 더 잘 이해하기 위해 상위 문서를 참고할 수 있습니다

관리자는 다음 리소스도 참고할 수 있습니다:

  1. OpenShift에서 보안 컨텍스트 제약 조건 관리
  2. OpenShift 및 UIDs 안내서

GitLab 배포 내 보안 컨텍스트 제약 조건

gitlab-controller-manager 배포는 Operator 프로세스가 포함된 Pod를 생성하고 관리합니다. 이 Pod 및 다른 모든 Pod는 restricted 보안 컨텍스트 제약 조건으로 실행됩니다.

Operator는 GitLab 애플리케이션이 필요로 하는 모든 리소스를 관리할 수 있는 강력한 권한을 가진 ServiceAccount를 사용합니다.

Operator는 Cloud Native GitLab을 구성하는 구성 서비스를 관리합니다. Operator이 지정한 UID와 일치하지 않는 Pod는 적극적으로 종료되고 대체됩니다. 이 메커니즘은 최소 권한 원칙을 강제합니다.

GitLab 애플리케이션 사용자 정의 리소스 정의

Operator가 배포하는 GitLab 사용자 정의 리소스를 충족하기 위해 사용되는 Pod는 anyuid 보안 컨텍스트 제약 조건을 사용합니다. 타사 Operator 및 리소스의 보안 컨텍스트 제약 조건은 다음 섹션에서 다룹니다.

gitlab-app-anyuidgitlab-app-nonroot ServiceAccount는 특정 권한이 부여되지 않습니다. 이들은 오로지 anyuidnonroot 보안 컨텍스트 제약 조건을 GitLab 애플리케이션 Pod에 바인딩하기 위해 존재합니다.

보안 컨텍스트 제약 조건은 향후 릴리스에서 OpenShift 보안 모델 내에서 GitLab 애플리케이션의 전체 읽기/쓰기 동작이 확인됨에 따라 강화될 것입니다.

note
Linux 패키지 설치에서 Cloud Native GitLab으로 이동하는 관리자는 Linux 패키지 설치 작업이 OpenShift 및 기반이 되는 Kubernetes 엔진에서 처리됨에 유의해야 합니다. Pod는 Linux 패키지 설치에서 특정 애플리케이션 사용자로 실행하도록 특권을 내려놓습니다. Operator예상한 UID로 작동하지 않는 모든 Pod를 종료할 것입니다.

타사 리소스 정의

인그레스 컨트롤러

Cloud Native GitLab을 배포할 때 nginx-ingress-controller를 사용하여 테스트하는 것을 권장합니다. 이는 고유의 nginx-ingress-scc security context constraint을 사용합니다.

대체 인그레스 컨트롤러를 선택하는 경우, 관련 문서를 참고하여 해당 인그레스 컨트롤러의 보안 컨텍스트 제약 조건을 더 자세히 알아보시기 바랍니다.

SSL 암호화

Operator는 GitLab 애플리케이션 내에서 SSL 인증서를 관리하기 위해 JetStack의 cert-manager-operator를 배포합니다. cert-manager-operator은 직접적으로 안전한 컨텍스트 제약 조건을 설정하지 않으므로 OpenShift는 기본적으로 restricted 보안 컨텍스트 제약 조건을 적용할 것입니다.