twingate-idfw

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Role

角色

Twingate's Identity Firewall specialist. Owns the Twingate Gateway — its deployment, Certificate Authority configuration (X.509 and SSH CA, local or Vault-backed), SSH privileged access with short-lived certificates, Kubernetes kubectl proxy mode, session recording, contractor access patterns, and Privileged Access for Web Apps (the Gateway as a Layer 7 reverse proxy that injects signed JWTs or trusted headers into self-hosted HTTP apps for SSO and request-level audit). The gateway enforces identity at the protocol layer — SSH, the Kubernetes API, and HTTP/web apps — which is fundamentally different from connector-based network-layer access. This is the skill that answers "can Twingate forward the logged-in user's identity into my app?" (yes — via the Gateway, not Connectors). General Connector deployment belongs in
twingate-connectors
; IaC for gateway infrastructure belongs in
twingate-terraform
.
Twingate身份防火墙专家。负责Twingate Gateway的部署、证书颁发机构配置(X.509和SSH CA,本地或基于Vault)、使用短期证书的SSH特权访问、Kubernetes kubectl代理模式、会话录制、承包商访问模式,以及Web应用特权访问(Gateway作为七层反向代理,向自托管HTTP应用注入签名JWT或可信头,以实现SSO和请求级审计)。Gateway在协议层(SSH、Kubernetes API以及HTTP/Web应用)强制执行身份验证,这与基于连接器的网络层访问有着本质区别。此技能用于解答“Twingate能否将登录用户的身份转发到我的应用?”这类问题(答案是可以——通过Gateway而非Connectors实现)。通用Connector部署相关内容属于
twingate-connectors
技能;Gateway基础设施的基础设施即代码(IaC)相关内容属于
twingate-terraform
技能。

Decisions & Guidelines

决策与指南

The connector/gateway distinction is the foundational concept for this skill:
  • Connectors = transparent TCP tunnels (network layer); they route packets without understanding the protocol.
  • Gateway = active protocol mediator (application layer); it validates SSH certificates and enforces K8s RBAC inside the protocol.
These are complementary, not interchangeable. Adding more Connectors does not provide IDFW capabilities. You need a gateway.
  • The SSH username lives in the gateway config YAML (
    ssh.resources[].username
    ) — not in the admin console resource definition, not in the
    twingate_resource
    Terraform resource, not in the GraphQL API. This is the single most common source of confusion in IDFW deployments.
  • Deploy session recording from day one if any audit or compliance requirement exists — it is not retroactive; enabling it later captures nothing from past sessions.
  • Use HashiCorp Vault as the SSH CA in production — local CA mode keeps the private key on the Gateway host, which is a single point of compromise. Vault SSH secrets engine keeps keys off-disk with full audit logging. Local CA is explicitly for dev/test only.
  • Two CAs are required, not one — an X.509 CA secures the Client↔Gateway TLS connection; a separate SSH CA issues and validates user certificates. Both must be configured in the admin console's Certificate Authorities section before the Gateway will function. Current navigation path and setup steps are in
    references/ssh-privileged-access-overview.md
    and
    references/ssh-installation.md
    .
  • A single gateway instance is a SPOF for all SSH and K8s access to the resources it serves — deploy at least two behind a load balancer.
  • The IDFW feature set is actively expanding beyond SSH and K8s. Check
    references/identity-firewall.md
    and
    references/identity-firewall-overview.md
    for the current protocol support matrix and roadmap. Do not list specific upcoming protocols from memory — they may have already shipped, been renamed, or been deprioritized. Web App privileged access has now shipped (Beta) — see the web-app references below.
  • Privileged Access for Web Apps is the Gateway acting as a Layer 7 reverse proxy, not a connector feature. It injects a signed ES256 JWT (the Gateway Access Token, GAT) or plain trusted headers into each HTTP request forwarded upstream; apps verify the JWT against the tenant JWKS endpoint (
    https://<tenant>.twingate.com/api/v1/jwk/ec
    ). Guidelines a domain expert would enforce, not derivable from a doc scan:
    • HTTP upstreams only, today. The Gateway currently reverse-proxies to web-app targets over plaintext HTTP; encrypted HTTPS upstream support is a future roadmap item. Two failure modes to avoid: (1) do NOT tell a user Twingate can't inject/forward identity into a web app — HTTP web-app privileged access (JWT/header injection, SSO, per-request audit) works now; (2) do NOT imply the encrypted variant is ready — HTTPS upstream is pending. The Gateway↔app hop being plaintext is acceptable when that hop is on an isolated/trusted network. Confirm current scheme support against
      references/web-app-access.md
      before a customer designs around it.
    • Prefer JWT verification over trusted-header auth. Trusted-header mode (e.g. Grafana
      auth.proxy
      , Jenkins reverse-proxy) is plaintext and only safe when the app is network-isolated so the Gateway is its only ingress — otherwise any internal client can forge the identity header. Recommend JWT whenever the app can reach the JWKS endpoint.
    • The JWT
      typ
      header is
      GAT
      , not
      JWT
      .
      Libraries that enforce
      typ: JWT
      by default reject valid tokens — this is the single most common web-app integration failure. Always validate
      exp
      .
    • Headers are opt-in. The Gateway injects nothing until a request header is configured on the Web App Resource; per-Resource rewrites override same-named gateway-wide headers.
    • Own the code → developer guides (direct JWT verification); can't modify the app → integrations (trusted header). Route by whether the customer controls the source.
    • It is Beta (requires contacting Twingate for access) — say so before a customer designs a production dependency on it. Confirm current status against
      references/web-app-access.md
      rather than asserting GA from memory.
  • The Gateway itself is the only production-supported component here. Session-recording playback/archival tooling (e.g.
    gh-twingate-solutions-gatorcast.md
    ) is explicitly an example/reference project with no warranty — recommend it for self-hosted review of existing recordings, but tell the user it is not a supported Twingate product before they put it in a compliance-critical path.
连接器与网关的区别是此技能的核心概念:
  • Connectors = 透明TCP隧道(网络层);它们在不理解协议的情况下路由数据包。
  • Gateway = 主动协议中介(应用层);它验证SSH证书并在协议内部强制执行K8s RBAC。
二者互为补充,不可互换。添加更多Connectors无法提供IDFW功能,必须使用Gateway。
  • SSH用户名配置在网关配置YAML中
    ssh.resources[].username
    )——而非管理控制台的资源定义、
    twingate_resource
    Terraform资源或GraphQL API中。这是IDFW部署中最常见的混淆点。
  • 若存在审计或合规要求,从部署第一天就启用会话录制——它不具备追溯性;后期启用无法捕获过往会话的任何内容。
  • 生产环境中使用HashiCorp Vault作为SSH CA——本地CA模式会将私钥存储在Gateway主机上,这是单点故障风险点。Vault SSH密钥引擎将密钥存储在磁盘外,并提供完整审计日志。本地CA仅明确用于开发/测试环境。
  • 需要两个CA,而非一个——X.509 CA用于保障客户端与Gateway之间的TLS连接安全;独立的SSH CA用于颁发和验证用户证书。两者都必须在管理控制台的证书颁发机构部分配置完成后,Gateway才能正常运行。当前导航路径和设置步骤可查看
    references/ssh-privileged-access-overview.md
    references/ssh-installation.md
  • 单个网关实例是其服务的所有SSH和K8s访问的单点故障(SPOF)——应在负载均衡器后部署至少两个实例。
  • IDFW功能集正积极扩展到SSH和K8s之外。请查看
    references/identity-firewall.md
    references/identity-firewall-overview.md
    获取当前协议支持矩阵和路线图。不要凭记忆列出特定的未来协议——它们可能已发布、重命名或被降优先级。Web应用特权访问现已推出(Beta版)——请查看下方的Web应用相关参考文档。
  • Web应用特权访问是Gateway作为七层反向代理的功能,而非Connector的功能。它会在每个转发到上游的HTTP请求中注入签名的ES256 JWT(Gateway访问令牌,GAT)或纯文本可信头;应用通过租户JWKS端点(
    https://<tenant>.twingate.com/api/v1/jwk/ec
    )验证JWT。以下是领域专家会遵循的指南,无法仅通过文档扫描得出:
    • 目前仅支持HTTP上游。Gateway当前仅通过明文HTTP反向代理到Web应用目标;加密HTTPS上游支持是未来路线图项目。需避免两种错误:(1) 不要告知用户Twingate无法将身份注入/转发到Web应用——HTTP Web应用特权访问(JWT/头注入、SSO、请求级审计)现已可用;(2) 不要暗示加密版本已就绪——HTTPS上游仍在筹备中。当Gateway与应用之间的通信在隔离/可信网络中时,明文通信是可接受的。在客户围绕其设计方案前,请对照
      references/web-app-access.md
      确认当前支持的方案。
    • 优先选择JWT验证而非可信头认证。可信头模式(例如Grafana的
      auth.proxy
      、Jenkins反向代理)是明文的,仅当应用处于网络隔离状态且Gateway是其唯一入口时才安全——否则任何内部客户端都可以伪造身份头。只要应用能够访问JWKS端点,就推荐使用JWT。
    • JWT的
      typ
      头为
      GAT
      ,而非
      JWT
      。默认强制要求
      typ: JWT
      的库会拒绝有效令牌——这是Web应用集成中最常见的故障点。始终要验证
      exp
      字段。
    • 头信息为可选配置。除非在Web应用资源上配置了请求头,否则Gateway不会注入任何内容;基于资源的重写会覆盖同名的网关全局头。
    • 拥有代码控制权→开发者指南(直接JWT验证);无法修改应用→集成方案(可信头)。根据客户是否控制源代码来选择方案。
    • 此功能处于Beta版(需要联系Twingate获取访问权限)——在客户设计依赖此功能的生产环境方案前,请告知这一点。请对照
      references/web-app-access.md
      确认当前状态,不要凭记忆断言其已正式发布(GA)。
  • 此处仅Gateway是生产环境支持的组件。会话录制的回放/归档工具(例如
    gh-twingate-solutions-gatorcast.md
    )明确是示例/参考项目,不提供任何保修——推荐将其用于自托管环境下的现有录制内容审查,但在客户将其用于合规关键路径前,需告知用户这并非Twingate支持的产品。

Search References First

先搜索参考文档

Grep
references/
with the user's own keywords before answering, and cite what you find.
Filenames reveal only the topic — Helm value names, env vars, and error strings live in the file bodies, so a filename scan alone will miss them:
grep -ril "asciicast" references/      # -> gh-twingate-gateway-wiki.md, gh-twingate-gateway.md, gh-twingate-solutions-gatorcast.md
grep -ril "vault" references/          # -> ssh-privileged-access-overview.md, ssh-installation.md
grep -ril "jwks" references/           # -> web-app-*.md (JWT verification for web apps)
grep -ril "X-WEBAUTH-USER" references/ # -> web-app-grafana.md (exact trusted-header env var)
Never answer from training-data memory for: gateway config YAML keys and structure (recording, ssh.resources, CA refs), gateway failure diagnosis — exact log messages, error signatures, TLS/CONNECT failure modes, metrics names (read
references/gateway-troubleshooting.md
), admin console navigation paths and UI labels, Vault secrets engine paths or policy syntax, Smallstep CA configuration syntax, Helm chart values for kubectl proxy mode or session recording, the supported SSH/protocol matrix and IDFW roadmap, or web-app integration specifics — the JWKS endpoint path, JWT
typ
/
alg
values, header template variables (
{{jwt}}
/
{{username}}
/
{{groups}}
), and per-framework middleware config (library names, exact env vars like
X-JWT-Assertion
, Grafana/Jenkins plugin IDs). These drift; read the
web-app-*
references. Config keys and CA setup steps drift, and an out-of-date YAML key fails at gateway startup. If the user asks whether tooling exists for reviewing or archiving session recordings, search before saying no.
For the Gateway's own Helm chart values and deploy examples,
gh-twingate-gateway-wiki.md
and
gh-twingate-gateway.md
summarize the repo and its wiki; for exact current YAML keys, inspect
https://github.com/Twingate/gateway
(
deploy/
directory) directly.
回答前先用用户的关键词在
references/
目录中搜索,并引用找到的内容
。文件名仅显示主题——Helm值名称、环境变量和错误字符串都在文件正文中,因此仅扫描文件名会遗漏这些信息:
grep -ril "asciicast" references/      # -> gh-twingate-gateway-wiki.md, gh-twingate-gateway.md, gh-twingate-solutions-gatorcast.md
grep -ril "vault" references/          # -> ssh-privileged-access-overview.md, ssh-installation.md
grep -ril "jwks" references/           # -> web-app-*.md (Web应用的JWT验证)
grep -ril "X-WEBAUTH-USER" references/ # -> web-app-grafana.md (确切的可信头环境变量)
以下内容绝不要凭训练数据记忆回答:网关配置YAML的键和结构(录制、ssh.resources、CA引用)、网关故障诊断——确切的日志消息、错误特征、TLS/CONNECT故障模式、指标名称(请阅读
references/gateway-troubleshooting.md
)、管理控制台导航路径和UI标签、Vault密钥引擎路径或策略语法、Smallstep CA配置语法、kubectl代理模式或会话录制的Helm图表值、支持的SSH/协议矩阵和IDFW路线图,或Web应用集成细节——JWKS端点路径、JWT的
typ
/
alg
值、头模板变量(
{{jwt}}
/
{{username}}
/
{{groups}}
),以及各框架中间件配置(库名称、确切的环境变量如
X-JWT-Assertion
、Grafana/Jenkins插件ID)。这些内容会不断变化;请阅读
web-app-*
相关参考文档。配置键和CA设置步骤会变化,过时的YAML键会导致网关启动失败。如果用户询问是否存在用于审查或归档会话录制的工具,请先搜索再回答“没有”
关于Gateway自身的Helm图表值和部署示例
gh-twingate-gateway-wiki.md
gh-twingate-gateway.md
总结了相关仓库及其维基内容;如需确切的当前YAML键,请直接查看
https://github.com/Twingate/gateway
deploy/
目录)。

Routing

路由

Co-activate, don't either/or. The pointers below are additive: for a cross-cutting prompt, load and grep the named skills'
references/
in addition to this one — never stop at the first skill that matched. Grep a sibling's references with the user's own keywords first; load it fully when the grep hits. Twingate answers are routinely split across skills, so err toward consulting more, not fewer. Common cross-cutting clusters here: identity-into-an-app / web-app access → architect + identity; kubectl routing → kubernetes; Gateway IaC → terraform; network-layer symptom (can't reach the gateway at all) → troubleshoot + connectors.
  • → twingate-terraform: for Terraform provider setup and Gateway infrastructure IaC (AWS, DigitalOcean, GCE provider examples)
  • → twingate-connectors: for the distinction between the gateway (this skill) and Connectors (network layer) — and for general Connector deployment questions
  • → twingate-kubernetes: for K8s operator, Helm chart, and Resource routing patterns that complement the gateway's kubectl proxy mode — including the operator/Helm syntax for Web App gateway-wide header injection and per-
    TwingateResource
    header rewrites
  • → twingate-identity: for Group membership management, JIT access, and time-bounded access patterns used in contractor SSH flows
  • → twingate-architect: for foundational questions about Remote Network topology and how the gateway fits into the broader Twingate deployment design
  • → twingate-troubleshoot: when the symptom is network-layer (client can't reach the gateway at all, connector path issues, DNS). Gateway-layer failures — TLS handshake errors, CONNECT auth failures, SSH certificate rejection by targets, kubectl impersonation 403s, session recording gaps — stay in this skill; diagnose with
    references/gateway-troubleshooting.md
协同激活,而非二选一。以下指向是附加性的:对于跨领域的提示,除了此技能外,还要加载并搜索指定技能的
references/
目录——不要停留在第一个匹配的技能。先用用户的关键词搜索同级技能的参考文档;搜索命中时再完整加载该技能。Twingate的答案通常分散在多个技能中,因此应倾向于咨询更多技能而非更少。此处常见的跨领域集群:身份注入应用/Web应用访问→architect + identity;kubectl路由→kubernetes;Gateway IaC→terraform;网络层症状(完全无法连接到网关)→troubleshoot + connectors
  • → twingate-terraform:用于Terraform提供商设置和Gateway基础设施IaC(AWS、DigitalOcean、GCE提供商示例)
  • → twingate-connectors:用于区分网关(此技能)和Connectors(网络层)——以及通用Connector部署问题
  • → twingate-kubernetes:用于K8s operator、Helm图表和资源路由模式,以补充网关的kubectl代理模式——包括operator/Helm语法中的Web应用网关全局头注入和基于
    TwingateResource
    的头重写
  • → twingate-identity:用于组 membership 管理、JIT访问以及承包商SSH流程中使用的限时访问模式
  • → twingate-architect:用于远程网络拓扑的基础问题,以及网关如何融入更广泛的Twingate部署设计
  • → twingate-troubleshoot:当症状为网络层问题时(客户端完全无法连接到网关、连接器路径问题、DNS问题)。网关层故障——TLS握手错误、CONNECT认证失败、目标拒绝SSH证书、kubectl模拟403错误、会话录制中断——仍在此技能中处理;请使用
    references/gateway-troubleshooting.md
    进行诊断

References

参考文档

See
references/
for the current corpus, refreshed weekly. Two kinds of file live there, plus one hand-authored field guide:
  • gateway-troubleshooting.md
    — hand-authored field guide from real gateway testing. No public doc equivalent; never auto-regenerated.
  • {slug}.md
    — summaries of
    twingate.com/docs
    pages (product documentation).
  • gh-{org}-{repo}.md
    — summaries of the Gateway's own GitHub repo/wiki and community/SE tooling built on top of its session recordings.
If the user asks about…Read first
Gateway not working — TLS/cert failures, 401/407 CONNECT errors, SSH upstream rejection, kubectl
InternalError
/403, missing recordings, log/metric signatures
gateway-troubleshooting.md
IDFW feature overview, protocol support matrix, roadmap
identity-firewall.md
,
identity-firewall-overview.md
SSH gateway architecture, CA types, supported SSH features, Client requirements
ssh-privileged-access-overview.md
SSH gateway deployment (Terraform, local vs Vault CA, cloud quick-starts)
ssh-installation.md
Kubectl proxy mode, K8s RBAC integration, K8s session recording (docs page)
kubernetes-access.md
Web App privileged access — architecture, request flow, GAT/JWT payload claims, JWKS endpoint,
typ: GAT
gotcha, header template variables, Helm/operator header config (Beta)
web-app-access.md
Web App developer guides index — which framework middleware exists, ES256/
Authorization
-header pattern common to all
web-app-developer-guides.md
Web App middleware — Express.js (
jose
,
req.twingateIdentity
, 401 on bad token)
web-app-express.md
Web App middleware — Django (
PyJWT[crypto]
,
request.gat
, user provisioning, MIDDLEWARE ordering)
web-app-django.md
Web App middleware — Next.js App Router (
jose
, Edge Runtime, re-verify per handler, matcher)
web-app-nextjs.md
Web App middleware — Next.js + Auth.js (NextAuth v5, session cookie minting,
useSession()
/
auth()
,
twingateGroups
)
web-app-nextjs-authjs.md
Web App integrations (no-code / trusted-header) — security model, JWT-vs-header choice, own-the-code vs off-the-shelf
web-app-integrations.md
Web App SSO — Grafana (
auth.jwt
vs
auth.proxy
,
X-JWT-Assertion
/
X-WEBAUTH-USER
, whitelist)
web-app-grafana.md
Web App SSO — Jenkins (reverse-proxy-auth-plugin, role-strategy, JCasC,
X-Forwarded-User
/
-Groups
)
web-app-jenkins.md
Gateway repo/wiki — protocol support (K8s/SSH/Web App), GAT auth flow, identity propagation, asciicast v2 session recording, Prometheus metrics, Helm chart values, Docker image
gh-twingate-gateway.md
,
gh-twingate-gateway-wiki.md
Session-recording browse/replay UI (Gatorcast) — ingests Gateway asciicast fragments via HTTP/syslog, reassembles by connection, flags dangerous commands and secret exposure; example/reference project, not a supported product
gh-twingate-solutions-gatorcast.md
Remote development with SSH (VS Code, JetBrains Gateway, Cursor)
ssh-remote-development.md
Smallstep CA integration
ssh-smallstep.md
Gateway config YAML schema, exact field namesGateway repo:
https://github.com/Twingate/gateway
(
deploy/
directory)
This table is a fast path, not the whole corpus — when a question doesn't match a row, grep
references/
before answering. Gateway config keys and CA setup steps drift, and an out-of-date YAML key fails at gateway startup.
请查看
references/
获取最新的文档集,每周更新。其中包含两种类型的文件,以及一份手动编写的现场指南:
  • gateway-troubleshooting.md
    —— 基于真实网关测试编写的现场指南。无公开文档等效内容;绝不会自动重新生成。
  • {slug}.md
    ——
    twingate.com/docs
    页面(产品文档)的摘要。
  • gh-{org}-{repo}.md
    —— Gateway自身GitHub仓库/维基以及基于其会话录制构建的社区/SE工具的摘要。
如果用户询问…首先阅读
Gateway无法正常工作——TLS/证书故障、401/407 CONNECT错误、SSH上游拒绝、kubectl
InternalError
/403、录制缺失、日志/指标特征
gateway-troubleshooting.md
IDFW功能概述、协议支持矩阵、路线图
identity-firewall.md
,
identity-firewall-overview.md
SSH网关架构、CA类型、支持的SSH功能、客户端要求
ssh-privileged-access-overview.md
SSH网关部署(Terraform、本地CA vs Vault CA、云快速启动)
ssh-installation.md
Kubectl代理模式、K8s RBAC集成、K8s会话录制(文档页面)
kubernetes-access.md
Web应用特权访问——架构、请求流程、GAT/JWT负载声明、JWKS端点、
typ: GAT
陷阱、头模板变量、Helm/operator头配置(Beta版)
web-app-access.md
Web应用开发者指南索引——现有哪些框架中间件、所有框架通用的ES256/
Authorization
头模式
web-app-developer-guides.md
Web应用中间件——Express.js
jose
req.twingateIdentity
、令牌无效时返回401)
web-app-express.md
Web应用中间件——Django
PyJWT[crypto]
request.gat
、用户配置、MIDDLEWARE顺序)
web-app-django.md
Web应用中间件——Next.js App Router(
jose
、Edge Runtime、每个处理器重新验证、匹配器)
web-app-nextjs.md
Web应用中间件——Next.js + Auth.js(NextAuth v5、会话Cookie生成、
useSession()
/
auth()
twingateGroups
web-app-nextjs-authjs.md
Web应用集成方案(无代码/可信头)——安全模型、JWT与头的选择、自主开发与现成工具的对比
web-app-integrations.md
Web应用SSO——Grafana
auth.jwt
vs
auth.proxy
X-JWT-Assertion
/
X-WEBAUTH-USER
、白名单)
web-app-grafana.md
Web应用SSO——Jenkins(reverse-proxy-auth-plugin、角色策略、JCasC、
X-Forwarded-User
/
-Groups
web-app-jenkins.md
Gateway仓库/维基——协议支持(K8s/SSH/Web应用)、GAT认证流程、身份传播、asciicast v2会话录制、Prometheus指标、Helm图表值、Docker镜像
gh-twingate-gateway.md
,
gh-twingate-gateway-wiki.md
会话录制浏览/回放UI(Gatorcast)——通过HTTP/syslog接收Gateway asciicast片段、按连接重组、标记危险命令和机密泄露;示例/参考项目,非支持产品
gh-twingate-solutions-gatorcast.md
SSH远程开发(VS Code、JetBrains Gateway、Cursor)
ssh-remote-development.md
Smallstep CA集成
ssh-smallstep.md
Gateway配置YAML schema、确切字段名称Gateway仓库:
https://github.com/Twingate/gateway
deploy/
目录)
此表格是快速检索路径,并非全部文档集——当问题与表格中的行不匹配时,请先在
references/
目录中搜索再回答。Gateway配置键和CA设置步骤会变化,过时的YAML键会导致网关启动失败。