보안 컨텍스트 제약 조건

개요

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

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

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

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

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

Operator는 Cloud Native GitLab을 구성하는 구성 서비스를 관리합니다. Operator가 예상한 UID로 동작하지 않는 Pod는 적극적으로 종료 및 교체됩니다. 이 메커니즘은 최소한의 권한 원칙을 강제합니다.

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

Operator가 배포한 Pod는 anyuid 보안 컨텍스트 제약 조건을 사용하여 GitLab 사용자 지정 리소스를 충족합니다. 서드 파티 Operator 및 리소스의 보안 컨텍스트 제약 조건은 다음 섹션에서 다룹니다.

gitlab-app-anyuid 및 gitlab-app-nonroot ServiceAccount에는 부여된 권한이 없습니다. 이들은 GitLab 애플리케이션 Pod에 anyuid 및 nonroot 보안 컨텍스트 제약 조건을 바인딩하는 데만 사용됩니다.

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

참고: Linux 패키지 설치에서 OpenShift 및 기본 Kubernetes 엔진에서 sudo를 사용하여 수행되는 Linux 패키지 설치 작업은 관리자가 Cloud Native GitLab에 오면 각각의 Pod들이 응용프로그램별 사용자로 실행되도록 권한을 낮추게 됩니다. Operator는 예상된 UID로 동작하지 않는 모든 Pod를 종료할 것입니다.

서드 파티 리소스 정의

Ingress 컨트롤러

Cloud Native GitLab 배포 시 nginx-ingress-controller를 사용하여 배포하는 것을 권장하고 테스트했습니다. Cloud Native GitLab의 경우 자체 nginx-ingress-scc 보안 컨텍스트 제약 조건을 사용합니다.

대체 Ingress 컨트롤러를 선택하는 경우 해당 보안 컨텍스트 제약 조건에 대해 자세히 알아 보기 위해 관련 문서를 참고하세요.

SSL 암호화

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