웹 터미널 (사용 중단됨)

Tier: Free, Premium, Ultimate
Offering: Self-Managed
  • GitLab 15.0에서 Self-Managed에서 비활성화됨.
caution
이 기능은 GitLab 14.5에서 사용 중단 되었습니다.
Self-Managed GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 관리자가 certificate_based_clusters라는 피처 플래그를 활성화하여 사용할 수 있습니다.

쿠버네티스 통합의 도입으로, GitLab은 쿠버네티스 클러스터의 자격 증명을 저장하고 사용할 수 있습니다. GitLab은 이러한 자격 증명을 사용하여 환경에 대한 웹 터미널에 액세스를 제공합니다.

note
프로젝트에 대한 Maintainer 역할을 적어도 가진 사용자만 웹 터미널에 액세스할 수 있습니다.

작동 방식

웹 터미널의 아키텍처 및 작동 방식에 대한 자세한 개요는 이 문서에서 찾을 수 있습니다. 간단히 말하면:

  • GitLab은 사용자가 자체 쿠버네티스 자격 증명을 제공하고 배포할 때 생성하는 pod에 적절한 라벨을 지정하는 데 의존합니다.
  • 사용자가 환경의 터미널 페이지로 이동하면, GitLab으로 WebSocket 연결을 열어주는 JavaScript 애플리케이션을 제공받습니다.
  • WebSocket은 Rails 애플리케이션 서버가 아닌 Workhorse에서 처리됩니다.
  • Workhorse는 Rails에 연결 세부 정보 및 사용자 권한에 대한 쿼리를 수행합니다. Rails는 Sidekiq을 사용하여 백그라운드에서 쿠버네티스에 대한 쿼리를 수행합니다.
  • Workhorse는 사용자 브라우저와 쿠버네티스 API 간의 프록시 서버로 작동하여 WebSocket 프레임을 둘 사이에서 전달합니다.
  • Workhorse는 정기적으로 Rails를 폴링하여, 사용자가 터미널에 더 이상 액세스할 수 없는 경우 또는 연결 세부 정보가 변경된 경우 WebSocket 연결을 종료합니다.

보안

GitLab 및 GitLab Runner는 상호작용하는 웹 터미널 데이터를 암호화하고 모든 것을 인가 가드로 보호하기 위해 몇 가지 조치를 취합니다. 이에 대한 자세한 내용은 아래에 설명되어 있습니다.

  • 인터랙티브 웹 터미널은 기본적으로 [session_server]가 구성되어 있지 않으면 완전히 비활성화됩니다.
  • Runner가 시작될 때마다 x509 인증서가 생성되어 wss(웹 소켓 보안) 연결에 사용됩니다.
  • 생성된 job마다 작업의 끝에서 폐기되는 랜덤 URL이 생성됩니다. 이 URL은 웹 소켓 연결을 설정하는 데 사용됩니다. 세션의 URL은 (IP|HOST):PORT/session/$SOME_HASH 형식입니다. 여기서 IP/HOST 및 PORT는 구성된 listen_address입니다.
  • 생성된 모든 세션 URL에는 wss 연결을 설정하기 위해 전송해야 하는 인가 헤더가 있습니다.
  • 세션 URL은 사용자에게 노출되지 않습니다. GitLab이 모든 상태를 내부적으로 보관하고 그에 따라 프록시합니다.

터미널 지원 활성화 및 비활성화

note
AWS Classic Load Balancer는 웹 소켓을 지원하지 않습니다. 웹 터미널을 사용하려면 AWS Network Load Balancer를 사용하세요. 자세한 내용은 AWS Elastic Load Balancing 제품 비교를 참조하세요.

웹 터미널은 웹 소켓을 사용하기 때문에, Workhorse 앞의 모든 HTTP/HTTPS 역방향 프록시는 Connection 및 Upgrade 헤더를 다음 체인으로 전달하도록 구성되어야 합니다. GitLab은 기본적으로 이를 수행하도록 구성되어 있습니다.

그러나 GitLab 앞에 로드 밸런서를 실행 중이라면 구성을 몇 가지 변경해야 할 수 있습니다. 다음 가이드는 인기있는 역방향 프록시들을 위한 필요한 단계에 대해 문서화하고 있습니다:

Workhorse는 웹 소켓 요청을 WebSocket 엔드포인트로 통과시키지 않으므로, 이러한 헤더 지원을 전역적으로 활성화하는 것이 안전합니다. 더 좁은 규칙 집합을 선호하는 경우, URL이 /terminal.ws로 끝나도록 제한할 수 있습니다. 이 접근 방식은 여전히 몇 가지 거짓 긍정을 유발할 수 있습니다.

직접 컴파일한 경우 구성을 변경해야 할 수 있습니다. 자세한 내용은 소스에서 Community Edition 및 Enterprise Edition 업그레이드를 참조하세요.

GitLab에서 웹 터미널 지원을 비활성화하려면, 체인의 첫 번째 HTTP 역방향 프록시에서 Connection 및 Upgrade를 전달하지 않도록 설정하세요. 대부분의 사용자의 경우, 이는 Linux 패키지 설치와 함께 제공되는 NGINX 서버입니다. 이 경우에는 다음을 수행해야 합니다:

  • gitlab.rb 파일의 nginx['proxy_set_headers'] 섹션을 찾습니다.
  • 전체 블록이 주석 처리되어 있는지 확인한 후, Connection 및 Upgrade 행을 주석 처리하거나 제거합니다.

자체 로드 밸런서의 경우, 위의 가이드에서 권장하는 구성 변경을 역으로 적용하세요.

이러한 헤더가 전달되지 않을 경우, Workhorse는 웹 터미널을 사용하려는 사용자에게 400 Bad Request 응답을 반환합니다. 결국, 사용자는 Connection failed 메시지를 받게 됩니다.

웹 소켓 연결 시간 제한

기본적으로, 터미널 세션은 만료되지 않습니다. GitLab 인스턴스에서 터미널 세션 수명을 제한하려면:

  1. 왼쪽 사이드바에서 가장 아래에서 관리 영역을 선택합니다.
  2. 설정 > 웹 터미널을 선택합니다.
  3. max session time을 설정합니다.