gdsgate¶

gdsgate — шлюз доступа в виде одного бинаря. Он ставит доступ к SSH-хостам, базам данных PostgreSQL и MySQL, кластерам Kubernetes, MCP-серверам и обычным TCP-сервисам за один прокси: с идентификацией пользователя, журналом аудита и принципом минимальных привилегий. Пользователи продолжают пользоваться знакомыми нативными инструментами — ssh, psql, mysql, kubectl, redis-cli — а каждая сессия проверяется политикой и записывается.

Зачем gdsgate¶

Один бинарь, все роли. Один и тот же исполняемый файл запускает control-plane, публичный прокси, агента возле ресурсов или клиентскую команду. Отдельный CLI устанавливать не нужно, отдельных сборок по ролям нет.
Идентификация по identity provider. Пользователи входят через ваш OIDC-провайдер. gdsgate проверяет identity token и авторизует каждое обращение политикой Cedar по группам пользователя и меткам ресурса.
Всё через прокси. Защищаемые ресурсы живут в изолированной зоне, достижимой только через исходящий reverse-туннель агента. Прокси — единственная входная дверь; внутрь защищаемой зоны никто не подключается.
Короткоживущие удостоверения. Доступ выдаётся как короткие сертификаты — истечение и есть механизм отзыва. Транспортные удостоверения узлов выдаются по одноразовой регистрации поверх взаимного TLS.
Защищённый от подделки журнал. Каждое решение об авторизации и каждая сессия добавляются в журнал аудита, в котором записи связаны между собой хешами — любая подделка или пропуск становятся заметны. Если запись в журнал не получилось зафиксировать на диске — доступ отказан.
Знакомый клиентский опыт. После одного gdsgate login ваши обычные ssh, psql, mysql, kubectl, redis-cli прозрачно идут через gdsgate.

Как это устроено¶

flowchart LR
  user([Пользователь + нативный клиент]) -- "публичный TLS / gRPC" --> proxy[Proxy]
  proxy -- "mTLS" --> auth["Auth\n(CA · политика · аудит)"]
  agent[Agent] -- "reverse-туннель\n(mTLS, исходящий)" --> proxy
  agent -- "локально" --> db[(PostgreSQL / MySQL)]
  agent -- "завершает / пробрасывает" --> ssh["SSH-хост /\nTCP / MCP / K8s"]
  idp([OIDC IdP]) -. "id_token / JWKS" .- user
  idp -. JWKS .- auth

Пользователь входит в identity provider, предъявляет identity token Proxy, тот спрашивает Auth авторизовать запрос и выдать короткий, ограниченный областью применения сертификат. Agent стоит возле защищаемых ресурсов и сам устанавливает исходящее соединение с Proxy — внутрь защищаемой зоны не нужно открывать вообще ничего.

Куда дальше¶

Концепции — архитектура, путь запроса, PKI и модель идентификации, принципы безопасности.
Руководство пользователя — вход, потом SSH, базы данных, Kubernetes, MCP, TCP — через нативные инструменты.
Руководство администратора — формы развёртывания, жизненный цикл регистрации и PKI, разделение сети на зоны, резервное копирование хранилища, чек-лист усиления защиты.
Конфигурация — каждая секция TOML, каждое поле, значения по умолчанию и примеры, готовые рецепты под роли.
CLI — полный набор команд, флаг за флагом.
Политика — Cedar-схема gdsgate (типы сущностей, действия, контекст) и готовые шаблоны политик.

Статус

gdsgate сейчас v0.1. Описанная здесь архитектура, конфигурация и потоки end-to-end проверены против настоящего OIDC-провайдера (Keycloak), с доступом, ограниченным по группам, по каждому поддерживаемому протоколу.