正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Webターミナル(非推奨)

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

この機能は、GitLab 14.5で非推奨になりました。

GitLab Self-Managedでは、デフォルトでこの機能は使用できません。管理者がcertificate_based_clustersという名前の機能フラグを有効にすると、この機能を使用できるようになります。


Kubernetesインテグレーションの導入により、GitLabはKubernetesクラスターの認証情報を保存して使用できます。GitLabは、これらの認証情報を使用して、環境のweb terminalsへのアクセスを提供します。

プロジェクトのメンテナー以上のユーザー権限を持つユーザーのみがWebターミナルにアクセスできます。

Webターミナルの仕組み

Webターミナルのアーキテクチャと動作方法の詳細な概要は、このドキュメントに記載されています。概要:

  • GitLabは、ユーザーが独自のKubernetes認証情報を提供し、デプロイ時に作成するポッドに適切なラベルを付けることを前提としています。
  • ユーザーが環境のターミナルページにアクセスすると、GitLabへのWebSocket接続を開くJavaScriptアプリケーションが提供されます。
  • WebSocketは、Railsアプリケーションサーバーではなく、Workhorseで処理されます。
  • Workhorseは、接続の詳細とユーザー権限についてRailsにクエリを送信します。Railsは、Sidekiqを使用してバックグラウンドでそれらについてKubernetesにクエリを送信します。
  • Workhorseは、ユーザーのブラウザとKubernetes API間のプロキシサーバーとして機能し、2つの間でWebSocketフレームを渡します。
  • Workhorseは定期的にRailsをポーリングし、ユーザーがターミナルにアクセスするユーザー権限を持たなくなった場合、または接続の詳細が変更された場合に、WebSocket接続を終了します。

セキュリティ

GitLabとGitLab Runnerは、インタラクティブなWebターミナルデータを暗号化された状態で保持し、すべてを認可ガードで保護するために、いくつかの予防措置を講じています。詳細については、以下をご覧ください。

  • [session_server]が設定されていない限り、インタラクティブなWebターミナルは完全に無効になります。
  • ランナーが起動するたびに、x509証明書が生成され、wss(Web Socket Secure)接続に使用されます。
  • 作成されたジョブごとに、ランダムなURLが生成され、ジョブの最後に破棄されます。このURLは、Webソケット接続を確立するために使用されます。セッションのURLの形式は(IP|HOST):PORT/session/$SOME_HASHです。ここで、IP/HOSTPORTlisten_addressに設定されています。
  • 作成されたすべてのセッションURLには、wss接続を確立するために送信する必要がある認可ヘッダーがあります。
  • セッションURLは、どのような方法でもユーザーに公開されません。GitLabは、すべての状態を内部的に保持し、それに応じてプロキシします。

ターミナルサポートの有効化と無効化

AWS Classicロードバランサーは、Webソケットをサポートしていません。Webターミナルを機能させるには、AWS Networkロードバランサーを使用します。詳細については、AWS Elasticロードバランシング製品の比較をお読みください。

WebターミナルはWebSocketを使用するため、Workhorseの前面にあるすべてのHTTP/HTTPSリバースプロキシは、チェーン内の次のプロキシにConnectionおよびUpgradeヘッダーを渡すように設定する必要があります。GitLabは、デフォルトでそうするように設定されています。

ただし、GitLabの前面でロードバランサーを実行する場合は、設定にいくつかの変更を加える必要がある場合があります。これらのガイドでは、一般的なリバースプロキシの選択に必要な手順について説明します:

Workhorseは、WebSocketリクエストを非WebSocketエンドポイントに渡さないため、これらのヘッダーのサポートをグローバルに有効にしても安全です。より狭いルールのセットが必要な場合は、/terminal.wsで終わるURLに制限できます。このアプローチでは、いくつかの誤検出が発生する可能性があります。

インストールを自分でコンパイルした場合は、設定にいくつかの変更を加える必要がある場合があります。詳細については、ソースからのCommunity EditionおよびEnterprise Editionのアップグレードをお読みください。

GitLabでWebターミナルのサポートを無効にするには、チェーン内の最初のHTTPリバースプロキシでConnectionおよびUpgradeホップバイホップヘッダーの通過を停止します。ほとんどのユーザーにとって、これはLinuxパッケージインストールにバンドルされているNGINXサーバーです。この場合、次の操作が必要です:

  • nginx['proxy_set_headers']``gitlab.rbファイルのセクションを見つけます
  • ブロック全体がコメント化されていないことを確認し、Connection行とUpgrade行をコメントアウトするか削除します。

独自のロードバランサーについては、前にリストしたガイドで推奨されている設定の変更を元に戻すだけです。

これらのヘッダーが通過しない場合、WorkhorseはWebターミナルを使用しようとしているユーザーに400 Bad Request応答を返します。次に、Connection failedメッセージを受信します。

WebSocket接続時間の制限

デフォルトでは、ターミナルセッションは期限切れになりません。GitLabインスタンスのターミナルセッションライフタイムを制限するには:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. 左側のサイドバーの下部にある設定 > Webターミナルを選択します。
  3. max session timeを設定します。