Что-то в последнее время я стал часто сталкиваться с Kerberos. Все эти мутные слова в конфигурации - SASL/GSSAPI. Что за фигня? Никогда такого не было и вот опять! Но я признаюсь, что во время своей молодости я честно продолбал этот момент и в керберос глубоко не углублялся, хотя конечно приходилось настраивать домен контроллеры, где это все активно используется.
Но не страшно! Давайте вместе восполним мой пробел. Это будет вводная заметка, поскольку после теории мы будем настраивать интеграции различного софта с kerberos (первым пойдет настройка ssh, но доберемся и до кафки!).
Итак, kerberos - это network authentication protocol. Он используется для безопасной аутентификации клиента и сервера в открытых сетях. Он был разработан в далекие 80-ые. Это важный момент, который откладывает отпечаток на схему его работы.
Но хватит пустой информации, давайте посмотрим схему аутентификации с помощью kerberos (картинка отсюда -
https://medium.com/identity-beyond-borders/kerberos-explained-3bc2ddb7b0eb).
Итак, какие основные участники процесса у нас имеются:
1.
Client - наш клиентский компьютер, который хочет пройти аутентификацию на сервере (Server).
2.
Server - сервер, который предоставляет какой-то сервис клиенту - например gitlab, nginx, kafka - что угодно.
3.
KDC - Key Distribution Center - центральный узел Kerberos, который состоит из двух компонентов:
1.
Authentication Server - сервер аутентификации.
2.
Ticket Granting Server (TGT) - сервер выдачи тикетов пользователю.
Теперь давайте разберем как же клиент может пройти аутентификацию на Server с помощью kerberos:
1. Клиент обращается к Server и согласует с ним метод аутентификации. На самом деле этот шаг очень важен, поскольку раскрывает для нас два новых термина -
SASL и GSSAPI. Что такое SASL?
SASL - Simple Authentication and Security Layer - это Framework, который позволяет разработчикам быстро внедрять различные механизмы аутентификации в свое приложение. Он описывает как клиент и сервер согласуют механизм аутентификации.
GSSAPI - Generic Security Services Application Program Interface - так же framework, который позволяет производить аутентификацию клиентов различными методами.
Итак, как бы мог выглядеть диалог нашего клиента с сервером, если оба используют SASL и GSSAPI? Примерно вот так:
1. Клиент → Серверу: Привет! Я использую SASL, как я могу пройти аутентификацию?
2. Сервер → Клиенту: Привет! Я тоже использую SASL, ты можешь пройти аутентификацию через
GSSAPI,
CRAM-MD5,
PLAIN.
3. Клиент → Серверу: Ок, я выбираю
GSSAPI.
4. Сервер → Клиенту: Отлично! Через GSSAPI я поддерживаю
Kerberos и
NTLM и SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). 5. Клиент → Серверу: Отлично! Я выбираю
Kerberos.
6. Клиент → Серверу: Данные по Kerberos аутентификации (**тикет Kerberos**).
То есть резюмируя - sasl и gssapi - просто фреймворки, которые позволяют клиенту и серверу договориться об используемом методе аутентификации. В нашем примере клиент выбрал аутентификацию через Kerberos.
2. После согласования механизма аутентификации клиент должен получить тикет Kerberos, который отправит серверу на шаге “**f”** из предыдущего пункта. Для этого он должен обратиться к
AS (Authentication Server), который является одним из компонентов
KDC (Key Distribution Center). Клиент не отправляет свой логин и пароль на
AS, а всего лишь запрашивает специальный
TGT тикет и отправляет свое имя на
AS.
AS проверяет что такой пользователь существует в базе, генерирует
TGT тикет и шифрует его паролем клиента и отправляет обратно.
Клиент с помощью своего пароля расшифровывает сообщение от AS. Если пароль был введен не верно, то расшифровать сообщение не получится. После расшифровки клиент получает тикет для тикетов -
TGT. Это специалный тикет, который можно обменивать на тикеты для сервисов.
