보안 컨텍스트 제약 조건

개요

OpenShift의 팟들은 보안 컨텍스트 제약 조건에 기반한 권한을 받습니다. 보안 컨텍스트 제약 조건(SCC)은 대규모 배포에서 롤 기반 액세스 제어 메커니즘을 간소화합니다. 관리자는 OpenShift에서 보안 컨텍스트 제약 조건이 작동하는 방식과 OpenShift 내에서의 위치에 대해 더 알아볼 수 있습니다

관리자는 아래 자원들을 참고할 수도 있습니다:

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

gitlab-controller-manager 배포는 Operator 프로세스를 포함하는 팟을 생성하고 관리합니다. 이 및 그 밖의 팟들은 restricted 보안 컨텍스트 제약 조건으로 실행됩니다.

Operator는 GitLab 어플리케이션에서 필요로 하는 모든 리소스를 관리할 수 있도록 강력한 권한이 있는 ServiceAccount를 사용합니다.

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

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

Operator에 의해 배포된 팟들은 GitLab 사용자 정의 리소스를 충족시키기 위해 non-root-v2 보안 컨텍스트 제약 조건을 사용합니다. 제3자 오퍼레이터와 리소스들을 위한 보안 컨텍스트 제약 조건은 다음 섹션에서 다루고 있습니다.

gitlab-app-nonroot ServiceAccount에는 부여된 권한이 없으며, GitLab 어플리케이션 팟들에 nonroot-v2 보안 컨텍스트 제약 조건을 바인딩하는 것만을 목적으로 합니다.

앞으로의 릴리즈에서 GitLab 어플리케이션의 전체 읽기/쓰기 동작이 OpenShift 보안 모델 내에서 유효성이 검증됨에 따라 보안 컨텍스트 제약 조건이 강화될 것입니다.

주의: 리눅스 패키지 설치에서 OpenShift 및 기본 Kubernetes 엔진에서 sudo로 수행되는 작업은 개별 서비스인 팟으로 처리됩니다. 팟은 특정 어플리케이션 사용자로 실행하기 위해 권한을 낮추는 것입니다. Operator는 예상된 UID로 작동하지 않는 모든 팟을 종료합니다.

제3자 리소스 정의

인그레스 컨트롤러

Cloud Native GitLab을 배포할 때 nginx-ingress-controller를 사용하고 테스트하는 것이 권장됩니다. 이는 자체 nginx-ingress-scc 보안 컨텍스트 제약 조건을 사용합니다.

대체 인그레스 컨트롤러를 선택하는 경우 해당 문서를 참고하여 그 보안 컨텍스트 제약 조건에 대해 자세히 알아보세요.

SSL 암호화

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