Безопасность: аутентификация

Посчитай ущерб на конкретике. stringsvc слушает :8080 в сети компании: любой, кто узнал адрес, вызывает Uppercase, ставит задачи в очередь из урока 21, читает факты из шины урока 22. Он не злодей — просто коллега с curl'ом; но лимит из урока 09 делится между честными и случайными, метрики врут, а инцидент не расследуется: в логах из урока 06 нет имени виновника. Два вопроса путать нельзя: аутентификация — «кто ты», проверка токена; авторизация — «что тебе можно», проверка прав. Первая — это endpoint middleware из урока 14: одна обёртка закрывает сразу HTTP из урока 04 и gRPC из урока 13, потому что оба транспорта зовут один и тот же endpoint, — поэтому аутентификация go kit живёт на endpoint, а не в поле фреймворка. Вторая — доменная логика: сервис смотрит на identity и решает. Разнесение мест критично: токен парсится один раз на границе, вниз по стеку едет готовая личность, а не сырой заголовок.

Канон stringsvc не ломается: Uppercase и Count остаются мгновенными, очередь и события работают. Рядом появляется привратник, и у него строгая грамматика. HTTP-декодер из урока 04 вытаскивает заголовок Authorization и кладёт токен в поле структуры запроса — транспорт знает про заголовки, endpoint знает про домен. Endpoint middleware проверяет подпись и срок, после чего кладёт в context.Identity: subject (кто), scopes (что можно). Дальше по стеку ходит личность, а не токен: сервис из урока 03 читает контекст, если ему нужен автор; payload события из урока 22 получает поле actor; лог из урока 06 пишет subject в каждое сообщение. Контекст — единственный канал: тащить токен аргументами через слои — значит заставлять каждый слой знать про аутентификацию, и при смене схемы токенов переписывать весь сервис. Ключ контекста — приватный тип: две библиотеки, случайно взявшие строковый ключ «identity», затрут друг друга; свой тип-ключ делает коллизию невозможной.

JWT — три части через точку: header с алгоритмом, payload с claims и подпись. Claims — стандартные iss (кто издал), sub (о ком), exp (до когда), aud (для кого), плюс свои: scopes. Токен подписан, но не шифрован: payload читает любой, кто перехватил, — в нём нельзя класть секреты, только факты о личности. Сервис токен не издаёт, а проверяет: подпись говорит «этот паспорт выдал наш auth-сервис», exp — «он ещё не просрочен». Проверка обязательна целиком: подпись без exp пропустит мёртвый паспорт, exp без подписи — подделку. Запрос «jwt микросервисы» в поиске приводит к библиотекам, и это правильно: бери проверенную (golang-jwt), самописный разбор подписи — как собственный криптопрак: можно, если знаешь, что делаешь, и нельзя, если не знаешь. TTL держи коротким: минуты для пользовательских токенов, часы для сервисных — просроченный токен безопаснее отозванного с опозданием, потому что не требует инфраструктуры отзыва.

Отказы аутентификации — тоже контракт API, и клиент различает их по коду. 401 Unauthorized: «не знаю, кто ты» — заголовка нет, подпись битая, токен просрочен; ответ уходит с WWW-Authenticate: Bearer, и клиент понимает: иди за новым токеном. 403 Forbidden: «знаю, кто ты, но нельзя» — подпись валидна, scope не тот: токен сервисного аккаунта, который умеет Count, стучится в админ-endpoint. В go-kit оба случая раскладываются канонно: ErrUnauthorized из middleware мапится в 401, доменные ошибки авторизации — через codeFrom из урока 05 в 403. Логи из урока 06 пишут причину отказа и subject, если он известен, — но никогда не пишут сам токен: утёкший в лог токен — это действующий ключ. Метрика auth_failures_total из урока 07 с меткой причины (no_token, expired, bad_signature, forbidden) превращает перебор в всплеск на графике, который заметит алерт, а не пользователь.

HS256 — HMAC: издатель и проверяющий держат один и тот же секрет. Быстро, просто, для одного сервиса — идеально. Цена: каждый, кто умеет проверять, умеет и издавать; секрет приходится раздавать всем сервисам, и один скомпрометированный узел подделывает паспорта всей системы. RS256 — RSA: приватный ключ только у издателя, публичный раздаётся всем проверяющим. Проверить может каждый, подделать — никто: сервисы проверяют, издаёт один auth-сервис. Плата — скорость (RSA дороже HMAC на порядок при проверке) и инфраструктура: ключи, ротация, JWKS — публичный endpoint издателя с текущими ключами, который проверяющие кэшируют. Правило выбора: один сервис или пара доверенных — HS256; федерация микросервисов, где токены ездят между командами, — RS256. И в обоих случаях секреты не в репозитории: тема «go-kit безопасность» заканчивается не кодом, а дисциплиной — env из урока 18, secrets оркестратора из урока 24, ротация по плану, а не по инциденту.

Токен в заголовке перехватывается так же, как пароль, если канал открыт: транспорт шифруем. Вопрос один: где терминировать TLS. Вариант первый — сам сервис: http.Server с TLSConfig, сертификаты из файлов, Let's Encrypt через autocert; сквозное шифрование, но и сложность в коде: продление, cipher suites, прокладка ключей. Вариант второй — канон микросервисов: на границе стоит reverse-proxy, nginx или ingress, он терминирует TLS и внутрь приватной сети передаёт открытый HTTP; pod слушает :8080, а прокси добавляет X-Forwarded-Proto: https — по нему сервис видит, что снаружи канал был шифрованным, и может отказывать запросам, пришедшим мимо прокси. gRPC из урока 13 живёт по тем же правилам: credentials на клиенте и сервере, а внутри кластера — mTLS, когда обе стороны предъявляют сертификаты и проверяют друг друга взаимно. Сертификаты хранятся секретами оркестратора, а не в образе — об этом урок 24.

Секрет — то, что открывает дверь целиком, и у него три заповеди. Первая: не в репозитории — git помнит всё, даже удалённое; ключ из коммита трёхлетней давности жив, пока не ротирован. Вторая: не в образе и не в коде — ENV в Dockerfile виден docker inspect'ом (урок 24), константа в исходнике видна всем, у кого есть бинарник. Третья: не в логе — маскируй секрет и токен в логгере из урока 06. Живут секреты в env на старте (двенадцать факторов из урока 18) или в secrets-хранилище оркестратора; fail fast обязательна: пустой STRINGSVC_JWT_SECRET — не дефолт, а отказ стартовать. Ротация — часть жизни: смена секрета инвалидирует все HS256-токены разом — это фича, кнопка «разлогинить всех». Кто издаёт токены — отдельный вопрос: в проде auth-сервис, в демо хватит утилиты, подписывающей токен тем же секретом; главное — издатель и проверяющий не живут в одном бинарнике случайно.

Микросервис вызывает микросервис: заказ едет в биллинг, биллинг — в нотификацию. Кто там, с другой стороны? Тот же запрос, и он обязан ехать с тем же паспортом: service.ProxyingMiddleware из урока 17 при пересылке копирует заголовок Authorization вперёд — identity сохраняется на всём пути, и каждый сервис в цепочке видит исходного subject, а не соседа. Лог из урока 06 в каждом сервисе пишет один и тот же subject — инцидент собирается в цепочку. Глубже — mTLS: сосед предъявляет сертификат, подписанный тем же CA, и ты знаешь, кто стучится, ещё до токена; это защита от имитации адреса в сети. Для событий из урока 22 правило то же: payload несёт actor — кто заказал работу, — и аудит через месяц отвечает на вопрос «кто запустил этот конвейер», не опрашивая свидетелей. Аутентификация — не одна дверь на входе, а паспорт, который признают на каждом рубеже.

Сервис получил привратника: токен проверяется один раз на endpoint, identity едет в контексте, отказы различаются честно, а секреты живут по правилам. Но stringsvc всё ещё запускается go run на ноутбуке: ни образа, ни окружения, ни ответа оркестратору «я жив и готов». Урок 24-deploy упакует его в Docker: multi-stage образ без сборочного мусора, exec-форма ENTRYPOINT ради сигналов, health-чеки для проб, env вместо настроек в коде — и чек-лист прод-деплоя, где каждая строка отсылает к уроку курса. Карта курса — на странице курса; обёртки endpoint — в уроке 14-endpoint-middleware; кодеки и честный 401 — в уроке 05-codeki; секреты в env — в уроке 18-konfiguraciya; метрики отказов — в уроке 07-metriki; proxy, пересылающий Authorization, — в уроке 17-struktura.