웹 터미널 (사양 완료)
certificate_based_clusters
라는 기능 플래그를 활성화하여 사용할 수 있습니다.- Web IDE를 통해 접근 가능한 더 이상 사용되지 않는 웹 터미널에 대해 자세히 알아보기.
- 실행 중인 CI 작업에서 접근 가능한 더 이상 사용되지 않는 웹 터미널에 대해 자세히 알아보기.
쿠버네티스 통합의 도입으로 GitLab은 쿠버네티스 클러스터의 자격 증명을 저장하고 사용할 수 있습니다. GitLab은 이러한 자격 증명을 사용하여 환경에 대한 웹 터미널에 액세스할 수 있습니다.
노트: 프로젝트에 대한 Maintainer 역할을 최소한으로 가진 사용자만 웹 터미널에 액세스할 수 있습니다.
작동 방식
웹 터미널의 아키텍처 및 작동 방식에 대한 자세한 개요는 이 문서에서 찾을 수 있습니다. 간략히 설명하면:
- GitLab은 사용자로부터 자체 쿠버네티스 자격 증명을 제공하고 배포할 때 생성하는 pod에 적절한 라벨을 지정하는 것을 의존합니다.
- 사용자가 환경의 터미널 페이지로 이동하면 GitLab으로의 WebSocket 연결을 열어주는 JavaScript 응용 프로그램이 제공됩니다.
- WebSocket은 Rails 애플리케이션 서버가 아닌 Workhorse에서 처리됩니다.
- Workhorse는 연결 세부 정보와 사용자 권한을 가져오기 위해 정기적으로 Rails에 쿼리합니다. Rails는 이를 백그라운드에서 Sidekiq을 사용하여 Kubernetes에 쿼리합니다.
- Workhorse는 사용자의 브라우저와 Kubernetes API 간을 프록시하는 프록시 서버로써 동작하며, 두 곳 간에 WebSocket 프레임을 전달합니다.
- Workhorse는 정기적으로 Rails를 폴링하여 사용자가 터미널에 더 이상 액세스할 권한이 없는 경우 또는 연결 세부 정보가 변경된 경우 WebSocket 연결을 종료합니다.
보안
GitLab 및 GitLab Runner는 상호 작용형 웹 터미널 데이터를 암호화하고 모든 것을 인가 가드로 보호하기 위해 몇 가지 주의를 취합니다. 이에 대한 자세한 내용은 아래에서 설명합니다.
-
[session_server]
가 구성되지 않은 경우 상호 작용형 웹 터미널은 완전히 비활성화됩니다. - 러너가 시작될 때마다
x509
인증서를 생성하며, 이는wss
(웹 소켓 보안) 연결에 사용됩니다. - 생성된 작업마다 작업이 종료될 때 폐기되는 랜덤 URL이 생성됩니다. 이 URL은 웹 소켓 연결을 설정하는 데 사용됩니다. 세션 URL은
(IP|HOST):PORT/session/$SOME_HASH
형식으로,IP/HOST
및PORT
는 구성된listen_address
입니다. - 작성된 각 세션 URL은 전송해야 하는 인가 헤더가 있습니다.
wss
연결을 설정하기 위해 전송되어야 합니다. - 세션 URL은 사용자에게 노출되지 않습니다. GitLab이 모든 상태를 내부적으로 보유하고 이에 따라 프록시합니다.
터미널 지원 활성화 및 비활성화
노트: AWS 클래식 로드 밸런서는 웹 소켓을 지원하지 않습니다. 웹 터미널을 작동시키려면 AWS 네트워크 로드 밸런서를 사용하세요. 자세한 정보는 AWS Elastic Load Balancing 제품 비교를 참조하세요.
웹 터미널이 WebSocket을 사용하기 때문에 Workhorse 앞의 모든 HTTP/HTTPS 역방향 프록시는 Connection
및 Upgrade
헤더를 다음 체인으로 전달하도록 구성되어야 합니다. GitLab은 기본적으로 이 작업을 수행하도록 구성됩니다.
그러나 GitLab 앞에서 로드 밸런서를 실행하는 경우 구성 변경이 필요할 수 있습니다. 다음은 일부 인기있는 역방향 프록시에 대한 필요한 단계를 문서화하는 가이드입니다.
Workhorse는 WebSocket 요청을 WebSocket 엔드포인트로 통과시키지 않으므로 전역적으로 이러한 헤더를 지원 활성화해도 안전합니다. 더 좁은 규칙 세트를 선호하는 경우 URL이 /terminal.ws
로 끝나는 URL로 제한할 수 있습니다. 이 접근 방식은 여전히 일부 오남용 사례를 낳을 수 있습니다.
자체 컴파일한 설치를 실행하는 경우 구성을 일부 변경해야 할 수 있습니다. 자세한 내용은 소스에서 커뮤니티 에디션 및 엔터프라이즈 에디션 업그레이드를 참조하세요.
GitLab에서 웹 터미널 지원을 비활성화하려면 체인에서 첫 번째 HTTP 역방향 프록시를 통해 Connection
및 Upgrade
hop-by-hop 헤더를 전달하도록하지 마세요. 대부분의 사용자에게는 리눅스 패키지 설치에 번들로 제공되는 NGINX 서버가 이 작업을 수행합니다. 이 경우 다음과 같이해야 합니다.
-
gitlab.rb
파일의nginx['proxy_set_headers']
섹션을 찾습니다. - 전체 블록이 주석 처리되어 있고
Connection
및Upgrade
라인이 주석 처리되었거나 제거되도록 확인하세요.
자체 로드 밸런서의 경우 위의 가이드에서 권장된 구성 변경을 반대로 하면 됩니다.
이러한 헤더가 전달되지 않으면 Workhorse는 웹 터미널을 사용하려는 사용자에게 400 Bad Request
응답을 반환합니다. 결과적으로 사용자는 Connection failed
메시지를 받습니다.
WebSocket 연결 시간 제한
기본적으로 터미널 세션이 만료되지 않습니다. GitLab 인스턴스에서 터미널 세션 수명을 제한하려면:
- 왼쪽 사이드바에서 아래쪽으로 이동하여 관리자 영역을 선택합니다.
- 설정 > 웹 터미널을 선택합니다.
-
최대 세션 시간
을 설정합니다.