• 더 이상 사용되지 않는 기능이 아닌 Web IDE를 통해 접근하는 웹 터미널에 대한 자세한 내용을 참고합니다.
• 더 이상 사용되지 않는 기능이 아닌 실행 중인 CI job에서 접근하는 웹 터미널에 대한 자세한 내용을 참고합니다.

Kubernetes 통합이 도입되면서 GitLab은 Kubernetes 클러스터의 자격 증명을 저장하고 사용할 수 있습니다. GitLab은 이 자격 증명을 사용해 환경의 웹 터미널에 대한 접근을 제공합니다.

웹 터미널 동작 방식#

웹 터미널의 아키텍처와 동작 방식에 대한 자세한 개요는 이 문서에서 확인할 수 있습니다. 요약하면 다음과 같습니다.

• GitLab은 사용자가 직접 Kubernetes 자격 증명을 제공하고, 배포 시 생성하는 Pod에 적절한 레이블을 지정하는 것에 의존합니다.
• 사용자가 환경의 터미널 페이지로 이동하면 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 인증서를 생성합니다.
• 생성되는 job 마다 무작위 URL 이 생성되며 job 이 끝나면 폐기됩니다. 이 URL은 웹 소켓 연결을 맺는 데 사용됩니다. 세션 URL의 형식은 (IP|HOST):PORT/session/$SOME_HASH 이며, IP/HOST와 PORT는 구성된 listen_address 입니다.
• 생성된 모든 세션 URL에는 wss 연결을 맺기 위해 전송해야 하는 인가 헤더가 있습니다.
• 세션 URL은 어떤 방식으로도 사용자에게 노출되지 않습니다. GitLab 이 모든 상태를 내부에서 관리하며 그에 맞게 프록시합니다.

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

웹 터미널은 WebSocket을 사용하므로, Workhorse 앞단의 모든 HTTP/HTTPS 리버스 프록시는 Connection 및 Upgrade 헤더를 체인의 다음 단계로 전달하도록 구성해야 합니다. GitLab은 기본적으로 그렇게 구성되어 있습니다.

다만 GitLab 앞단에 로드 밸런서를 두고 있다면 구성을 일부 변경해야 할 수 있습니다. 다음 가이드는 널리 쓰이는 몇 가지 리버스 프록시에 필요한 단계를 설명합니다.

• Apache
• NGINX
• HAProxy
• Varnish

Workhorse는 WebSocket 이 아닌 엔드포인트로는 WebSocket 요청을 통과시키지 않으므로, 이 헤더에 대한 지원을 전역으로 활성화해도 안전합니다. 더 좁은 규칙을 선호한다면 /terminal.ws로 끝나는 URL로 제한할 수 있습니다. 이 방식에서도 약간의 오탐이 발생할 수 있습니다.

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

GitLab에서 웹 터미널 지원을 비활성화하려면 체인의 첫 번째 HTTP 리버스 프록시에서 Connection 및 Upgrade 홉 바이 홉 헤더 전달을 중지합니다. 대부분의 사용자에게는 Linux 패키지 설치에 번들로 포함된 NGINX 서버가 이에 해당합니다. 이 경우 다음을 수행합니다.

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

자체 로드 밸런서를 사용한다면 앞서 나열한 가이드가 권장한 구성 변경을 반대로 적용하면 됩니다.

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

WebSocket 연결 시간 제한#

기본적으로 터미널 세션은 만료되지 않습니다.

사전 요구 사항:

• 관리자 액세스 권한.

GitLab 인스턴스에서 터미널 세션 수명을 제한하려면 다음을 수행합니다.

1. 오른쪽 위 모서리에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Web terminal을 확장합니다.
4. max session time을 설정합니다.