웹 터미널 (사용 중단)

Tier: Free, Premium, Ultimate Offering: Self-managed
caution
이 기능은 GitLab 14.5에서 사용 중단되었습니다.

자체 관리 GitLab에서는 기본적으로 이 기능이 제공되지 않습니다. 사용 가능하게 하려면 관리자가 certificate_based_clusters라는 기능 플래그를 활성화해야 합니다.

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

note
프로젝트에 대한 Maintainer 역할을 가진 사용자만 웹 터미널에 접근할 수 있습니다.

작동 방식

웹 터미널의 아키텍처와 작동 방식에 대한 자세한 개요는
이 문서에서 확인할 수 있습니다.
간략히 설명하자면:

  • GitLab은 사용자가 자신의 Kubernetes 자격 증명을 제공하고,
    배포할 때 생성하는 파드에 적절한 레이블을 붙이도록 의존합니다.
  • 사용자가 환경의 터미널 페이지로 이동하면, 그들은
    GitLab으로 다시 WebSocket 연결을 여는 JavaScript 애플리케이션을 제공합니다.
  • WebSocket은 Rails 애플리케이션 서버가 아닌
    Workhorse에서 처리됩니다.
  • Workhorse는 연결 세부정보와 사용자 권한을 위해 Rails에 요청합니다.
    Rails는 백그라운드에서 Sidekiq를 사용하여 Kubernetes에 요청합니다.
  • Workhorse는 사용자의 브라우저와 Kubernetes API 간의 프록시 서버 역할을 하며,
    두 개체 간에 WebSocket 프레임을 전달합니다.
  • Workhorse는 Rails에 정기적으로 요청하여, 사용자가 더 이상
    터미널에 접근할 수 있는 권한이 없거나 연결 세부정보가 변경된 경우
    WebSocket 연결을 종료합니다.

보안

GitLab과 GitLab Runner는
인터랙티브 웹 터미널 데이터를 암호화하여 안전하게 유지하기 위해 몇 가지
예방 조치를 취하고 있으며, 모든 것이 인증 가드로 보호됩니다.
자세한 내용은 아래에 설명되어 있습니다.

  • 인터랙티브 웹 터미널은 [session_server]가 구성되지 않으면 완전히 비활성화됩니다.
  • 러너가 시작될 때마다 wss (Web Socket Secure) 연결에 사용되는
    x509 인증서가 생성됩니다.
  • 생성된 각 작업에 대해 무작위 URL가 생성되며, 이 URL는 작업이 끝날 때
    폐기됩니다. 이 URL는 웹 소켓 연결을 설정하는 데 사용됩니다.
    세션의 URL 형식은 (IP|HOST):PORT/session/$SOME_HASH로, IP/HOST 및
    PORT는 구성된 listen_address입니다.
  • 생성된 모든 세션 URL에는 wss 연결을 설정하기 위해
    전송해야 하는 인증 헤더가 포함되어 있습니다.
  • 세션 URL은 어떠한 방식으로도 사용자에게 노출되지 않습니다.
    GitLab은 내부적으로 모든 상태를 유지하고 적절히 프록시합니다.

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

주의:

AWS Classic Load Balancers는 웹 소켓을 지원하지 않습니다.

웹 터미널이 작동하기를 원한다면 AWS Network Load Balancers를 사용하세요.

자세한 내용은 AWS Elastic Load Balancing 제품 비교를 읽어보세요.

웹 터미널이 WebSockets를 사용하기 때문에 Workhorse 앞에 있는 모든 HTTP/HTTPS 리버스 프록시는 Connection 및 Upgrade 헤더를 체인에서 다음으로 전달하도록 구성되어야 합니다. GitLab은 기본적으로 그렇게 구성되어 있습니다.

그러나 GitLab 앞에 로드 밸런서를 실행하는 경우, 구성에 몇 가지 변경이 필요할 수 있습니다. 이러한 가이드는 인기 있는 리버스 프록시의 필수 단계를 문서화하고 있습니다:

Workhorse는 WebSocket 요청을 비-WebSocket 엔드포인트로 전달하지 않으므로 이러한 헤더에 대한 지원을 전역적으로 활성화하는 것은 안전합니다. 보다 좁은 규칙 세트를 선호하는 경우 /terminal.ws로 끝나는 URL로 제한할 수 있습니다. 이 접근 방식은 여전히 몇 가지 허위 긍정을 초래할 수 있습니다.

설치를 자체 컴파일한 경우 구성에 몇 가지 변경이 필요할 수 있습니다. 자세한 내용은 출처에서 커뮤니티 에디션 및 엔터프라이즈 에디션 업그레이드를 읽어보세요.

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

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

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

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

WebSocket 연결 시간 제한

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

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > Web terminal을 선택합니다.
  3. max session time을 설정합니다.