Настройка безопасности в Kafka задача не простая! Мы попробуем разобраться!

Важно, чтобы читатель был достаточно хорошо осведомлен и, как минимум, успел пощупать вот эти вещи:

1. Linux
2. Kafka

В этой статьей я постараюсь максимально просто описать:

• Основные термины
• Механизм безопасности в общем
• Механизмы безопасности Kafka

Следующая статья.

Основные термины

Основных термина у нас два

• аутентификация — проверка что клиент тот за кого он себя выдает
• авторизация — проверка имеет ли этот клиент право на выполнение конкретного действия над конкретным ресурсом

Грубо говоря, если к Вам придет незнакомая личность, и скажет — «Я почтальон Печкин, принес Вам письмо», то Вы:

1. Аутентифицируете Печкина! Проверите его паспорт, убедившись что это действительно Печкин, а не дерзкий негодяй, выдающий себя за другого, с целью сделать Вам больно!
2. Авторизуете Печкина! Попросите удостоверение почтальона. Т.е. проверите что именно Печкин имеет право доставлять Вам письма!

В авторизации часто используются очевидные понятия:

• право — возможность что-то делать
• пользователь или принципал — тот, кому дают право
• группа — группа пользователей. Сделана для удобства. Чтобы не давать право каждому пользователю по отдельности, можно назначить это право группе. А в группу можно потом добавлять или исключать из нее пользователей.

Есть еще одна важная деталь! Когда Вы проверяете паспорт Печкина, кто-нибудь может подсмотреть паспорт Печкина и подделать! Дабы этого не произошло, производить передачу данных для авторизации или аутентификации можно по защищенному каналу.

Защищенный канал — это способ скрывать передаваемые данные от посторонних глаз! Частный случай — это шифрование данных. Самый известный протокол  — SSL.

Для понимания статьи важно помнить, что с помощь SSL можно еще проводить аутентификацию. Подробнее об этом тут (пока не готово) !

Все очень просто! Но крайне важно не путать понятие аутентификации и авторизации!

Механизмы безопасности

Мы определили понятия, но теперь нам важно понимать где, когда и в какой последовательности их использовать.

Логично что проводить авторизацию без предварительной аутентификации нет смысла!

Т.е. проверять удостоверение, разрешающее доставлять почту у Печинка нет смысла, если Вы не проверили его паспорт.  А вдруг он украл удостоверение почтальона!

В зависимости от потребностей можно выбрать одну из схем построения безопасности:

1. Отсутствие всякой проверки — например чтение большинства страничек в интернете не требует какой-либо проверки
2. Только аутентификация — например, когда доступ к информации нужно ограничить зарегистрированными пользователями
3. Аутентификация с  последующей авторизацией — когда требуется разделять доступ к ресурсам. Например, логично что зарегистрированный клиент должен иметь право редактировать настройки только своего профиля, а администратор платформы право редактировать настройки всех пользователей.

Все эти схемы могут быть использованы как с защитой канала, так и без защиты канала.

На изображении показаны все варианты:

Примерно так во многих программах функционирует система безопасности. Отличаются только детали реализации блоков: защищенный канал, авторизация и аутентификация! Иногда бывает и так что есть несколько реализаций на выбор каждого компонента! Именно в Kafka как раз и есть выбор.

Реализация механизма безопасности в Kafka

Общую схему в предыдущем пункте мы уже узнали. Kafka имеет все варианты схемы безопасности. Более того, Kafka имеет по несколько реализаций блока аутентификации и авторизации! Давайте разберем их.

Защищенный канал

Защищенный канал у Kafka реализуется одним, широко известным всем способом — с помощью SSL. Соответственно  можно работать как с SSL.

Блок аутентификации

Какие протоколы аутентификации есть?

1. Без аутентификации — тут все понятно
2. С аутентификацией по протоколу SSL — как мы знаем SSL сам по себе позволяет идентифицировать того, кто создает соединение, а значит может может быть использован для аутентификации — подробнее тут (не готово пока).
3. С аутентификации по протоколу SASL — простыми словами SASL — это инструмент, который позволяет поддерживать разные механизмы аутентификации.
   

   Чтобы в дальнейшем не путаться условимся называть SASL и SSL (только когда используется именно для аутентификации а не для защиты канала) — протоколами аутентификации, а все что поддерживает SASL — механизмами аутентификации.

   Ниже список поддерживаемых SASL механизмов аутентификации на сегодня:

   1. PLAIN — самая простая реализация, когда списки пользователей и пароли описываются в конфиге сервера Kafka
   2. GSSAPI — стандарт для поддержки протоколов безопасности. Но тут он используется для поддержки Kerberos.
   3. SCRAM —
   4. OAUTHBEARER

Конфигурация пользователей в Kafka, в случае SASL, описывается с помощью JAAS. Это такая библиотека, которая позволяет гибко настраивать и описывать в конфиге выбранный механизм  аутентификации. В следующих статьях мы рассмотрим, как описывать кто и как имеет право пройти аутентификацию.

Важно отличать — просто защищенный канал SSL и аутентификацию с помощью SSL. SASL как мы уже знаем может работать с защитой SSL. И помимо этого есть аутентификация через SSL — это разные вещи!

Блок авторизации

В Kafka можно использовать как встроенную авторизацию, так и внешнюю. Но мы сосредоточимся на встроенной. Которая представлена так называемыми ACL — списками управления доступом. Проще говоря, это список записей, которые содержат:

КТО какие ДЕЙСТВИЯ над каким РЕСУРСОМ имеет право выполнять

Итого

Итак, Kafka предоставляет возможность выбрать защищать ли канал SSL. Широкий выбор средств аутентификации и гибкость в выборе способа авторизации!

Резюме

В этой статье мы научились отличать авторизацию от аутентификации. Узнали как устроены механизмы разделения доступа к ресурсам и познакомились с некоторыми деталями реализации в Kafka.

В следующей статье мы узнаем как сказать Kafka какой способ аутентификации мы выбрали. Запустим Kafka с самым простым механизмом аутентификации.

Следующая статья.