Skip to content

gdsgate

gdsgate is an access gateway delivered as a single binary. It puts identity-aware, audited, least-privilege access to SSH hosts, PostgreSQL and MySQL databases, Kubernetes clusters, MCP servers, and raw TCP services behind one proxy. Users keep using the native tools they already know — ssh, psql, mysql, kubectl, redis-cli — while every session is policy-checked and recorded.

Why gdsgate

  • One binary, every role. The same executable runs the control plane, the public proxy, the agent sitting next to your resources, or a client command. There is no separate CLI to install and no per-role build.
  • Identity-aware access. Users sign in through your OIDC identity provider. gdsgate verifies the identity token and authorises each request with a Cedar policy over the user's groups and the resource's labels.
  • Everything through the proxy. Protected resources live in a segregated zone reachable only through an agent's outbound reverse tunnel. The proxy is the only front door; nothing connects into the protected zone.
  • Short-lived credentials. Access is granted as short-lived certificates; expiry is the revocation mechanism. Internal node identities are issued by a one-time registration over mutual TLS.
  • Tamper-evident audit. Every authorisation decision and every session is appended to a hash-chained, durable audit log. A grant is refused if its audit record cannot first be made durable.
  • Native client experience. After one gdsgate login, your everyday ssh, psql, mysql, kubectl, and redis-cli workflows are routed through gdsgate transparently.

How it fits together

flowchart LR
  user([User + native client]) -- "public TLS / gRPC" --> proxy[Proxy]
  proxy -- "mTLS" --> auth["Auth\n(CA · policy · audit)"]
  agent[Agent] -- "reverse tunnel\n(mTLS, outbound)" --> proxy
  agent -- "local" --> db[(PostgreSQL / MySQL)]
  agent -- "terminates / forwards" --> ssh["SSH host /\nTCP service / MCP / K8s"]
  idp([OIDC IdP]) -. "id_token / JWKS" .- user
  idp -. JWKS .- auth

The user signs in to the identity provider, presents the identity token to the Proxy, which asks Auth to authorise the request and issue a scoped, short-lived certificate. The Agent sits next to the protected resources and dials out to the Proxy, so the protected zone needs no inbound rules at all.

Where to go next

  • Concepts — the architecture, how a request flows, the PKI and identity model, the security principles.
  • User guide — log in, then SSH, databases, Kubernetes, MCP, raw TCP — through native tools.
  • Admin guide — deployment shapes, registration and PKI lifecycle, network zoning, state-store backup, the hardening checklist.
  • Configuration — every TOML section, every field, defaults and examples, with per-role recipes.
  • CLI — the full command surface, flag by flag.
  • Policy — the Cedar schema gdsgate exposes (entity types, actions, contexts) and ready-made policy patterns.

Status

gdsgate is at v0.1. The architecture, configuration, and flows described here are exercised end-to-end against a real OIDC provider (Keycloak), with group-scoped authorisation across every supported protocol.