网页终端（已弃用）

• 了解更多关于未弃用的通过 Web IDE 访问的网页终端的信息。
• 了解更多关于未弃用的从正在运行的 CI 作业访问的网页终端的信息。

随着 Kubernetes 集成 的引入，GitLab 可以存储并使用 Kubernetes 集群的凭据。 GitLab 使用这些凭据为环境提供对网页终端的访问权限。

网页终端的工作原理

关于网页终端的架构及其工作原理的详细概述，可以在此文档中找到。简而言之：

• GitLab 依赖用户提供自己的 Kubernetes 凭据，并在部署时为其创建的 pod 添加适当的标签。
• 当用户进入环境的终端页面时，系统会为他们提供一个 JavaScript 应用程序，该应用程序会打开一个返回到 GitLab 的 WebSocket 连接。
• WebSocket 由 Workhorse 处理，而不是由 Rails 应用服务器处理。
• Workhorse 向 Rails 查询连接详细信息和用户权限。Rails 则在后台使用 Sidekiq 向 Kubernetes 查询这些信息。
• Workhorse 充当用户浏览器和 Kubernetes API 之间的代理服务器，在两者之间传递 WebSocket 帧。
• Workhorse 会定期轮询 Rails，如果用户不再拥有访问终端的权限，或连接详细信息已更改，则终止 WebSocket 连接。

安全

GitLab 和 GitLab Runner 采取了一些预防措施，以确保它们之间的交互式网页终端数据是加密的，并且所有内容都受到授权保护。下面将对此进行更详细的描述。

• 除非配置了 [session_server]，否则交互式网页终端将被完全禁用。
• 每次 runner 启动时，它都会生成一个 x509 证书，该证书用于 wss（Web Socket Secure）连接。
• 对于每个创建的作业，都会生成一个随机 URL，该 URL 在作业结束时被丢弃。此 URL 用于建立 web socket 连接。会话的 URL 格式为 (IP|HOST):PORT/session/$SOME_HASH，其中 IP/HOST 和 PORT 是配置的 listen_address。
• 每个创建的会话 URL 都有一个需要发送的授权标头，以建立 wss 连接。
• 会话 URL 不会以任何方式暴露给用户。GitLab 在内部保存所有状态并进行相应的代理。

启用和禁用终端支持

由于网页终端使用 WebSockets，Workhorse 前的每个 HTTP/HTTPS 反向代理都必须配置为将 Connection 和 Upgrade 标头传递给链中的下一个代理。GitLab 默认已配置为这样做。

但是，如果您在 GitLab 前运行了负载均衡器，您可能需要对配置进行一些更改。这些指南记录了一些流行反向代理的必要步骤：

• Apache
• NGINX
• HAProxy
• Varnish

Workhorse 不会将 WebSocket 请求传递到非 WebSocket 端点，因此全局启用对这些标头的支持是安全的。如果您希望使用更严格的规则集，可以将其限制为以 /terminal.ws 结尾的 URL。这种方法仍可能导致少量误判。

如果您是自己编译安装的，您可能需要对配置进行一些更改。阅读从源码升级社区版和企业版了解更多详情。

要在 GitLab 中禁用网页终端支持，请停止在链中的第一个 HTTP 反向代理中传递逐跳 Connection 和 Upgrade 标头。对于大多数用户，这是 Linux 包安装中捆绑的 NGINX 服务器。在这种情况下，您需要：

• 在您的 gitlab.rb 文件中找到 nginx['proxy_set_headers'] 部分。
• 确保整个代码块未被注释，然后注释掉或删除 Connection 和 Upgrade 行。

对于您自己的负载均衡器，只需撤销前面指南中推荐的配置更改即可。

当这些标头未被传递时，Workhorse 会向尝试使用网页终端的用户返回 400 Bad Request 响应。相应地，他们会收到一条“连接失败”的消息。

限制 WebSocket 连接时间

默认情况下，终端会话不会过期。要限制您的 GitLab 实例中的终端会话生命周期：

1. 在左侧边栏的底部，选择 管理员。
2. 选择 设置 > 网页终端。
3. 设置一个 max session time（最大会话时间）。