#kafka #ssl #translation
Have translated into Russian basics of Kafka SSL connectivity
Master article https://docs.confluent.io/current/kafka/authentication_ssl.html
\\\\\
Перевел на русский язык основные тезисы SSL подключения к Kafka:
Обзор SSL
С помощью SSL-аутентификации сервер аутентифицирует клиента (что также называется «двухсторонняя аутентификация»). Поскольку SSL-аутентификация требует SSL шифрования, то здесь показано, как настроить и то, и другое одновременно, а также представлен суперсет конфигураций, необходимых только для SSL шифрования (https://docs.confluent.io/current/kafka/encryption.html#kafka-ssl-encryption).
По умолчанию Apache Kafka® осуществляет взаимодействие в формате PLAINTEXT, что означает, что все данные передаются в открытом виде. Для шифрования взаимодействия необходимо настроить в вашем развертывании все компоненты платформы Confluent на использование шифрования SSL.
Secure Sockets Layer (SSL) является предшественником Transport Layer Security (TLS) и является устаревшим с июня 2015 года. Однако по историческим причинам Kafka (как и Java) использует в конфигурации и в коде термин/аббревиатуру «SSL» вместо «TLS». В этом разделе используется только аббревиатура «SSL».
Вы можете настроить SSL для шифрования или аутентификации. Можно настроить только SSL-шифрование (по умолчанию SSL-шифрование включает аутентификацию сертификата сервера) и независимо выбрать отдельный механизм аутентификации клиента (например, SSL (https://docs.confluent.io/current/kafka/authentication_ssl.html#kafka-ssl-authentication), SASL (https://docs.confluent.io/current/kafka/authentication_sasl/index.html#kafka-sasl-auth)). Технически, SSL шифрование уже включает однонаправленную аутентификацию, при которой клиент аутентифицирует сертификат сервера. Таким образом, в этом разделе «SSL аутентификация» действительно относится к двухсторонней аутентификации, где брокер также аутентифицирует сертификат клиента.
Включение SSL может повлиять на производительность из-за накладных расходов на шифрование.
SSL использует пары закрытый ключ/сертификат, применяемые во время SSL-рукопожатия.
• Каждому брокеру требуется собственная пара секретный ключ/сертификат и клиент использует сертификат для аутентификации брокера.
• Если включена аутентификация клиента, то каждому логическому клиенту требуется пара закрытый ключ/сертификат и брокер использует сертификат для аутентификации клиента.
Вы можете настроить для каждого брокера и логического клиента truststore, который используется для определения того, каким сертификатам (идентификаторам брокера или логического клиента) следует доверять (аутентифицировать их). Truststore можно настроить несколькими способами. Рассмотрим следующие два примера:
• Truststore содержит один или несколько сертификатов: тогда брокер или логический клиент будет доверять любому сертификату, имеющемуся в truststore.
• Truststore содержит Центр Сертификации (Удостоверяющий Центр, Certificate Authority (CA)): тогда брокер или логический клиент будет доверять любому сертификату, подписанному by CA в truststore.
Использование метода CA более удобно, поскольку добавление нового брокера или клиента не требует изменений в truststore. Метод CA описан в этой диаграмме (https://github.com/confluentinc/confluent-platform-security-tools/blob/master/single-trust-store-diagram.pdf).
Однако с помощью метода CA Kafka не поддерживает блокировку аутентификации для отдельных брокеров или клиентов, которым ранее доверяли с помощью этого механизма (отзыв сертификата обычно выполняется с помощью списков отзыва сертификатов (Certificate Revocation Lists) или онлайн-протокола состояния сертификатов (Online Certificate Status Protocol)), поэтому для блокировки доступа необходимо полагаться на авторизацию.
С другой стороны, если используется один или несколько сертификатов, блокировка аутентификации достигается удалением сертификата брокера или клиента из truststore.
t.me/middle_java
Have translated into Russian basics of Kafka SSL connectivity
Master article https://docs.confluent.io/current/kafka/authentication_ssl.html
\\\\\
Перевел на русский язык основные тезисы SSL подключения к Kafka:
Обзор SSL
С помощью SSL-аутентификации сервер аутентифицирует клиента (что также называется «двухсторонняя аутентификация»). Поскольку SSL-аутентификация требует SSL шифрования, то здесь показано, как настроить и то, и другое одновременно, а также представлен суперсет конфигураций, необходимых только для SSL шифрования (https://docs.confluent.io/current/kafka/encryption.html#kafka-ssl-encryption).
По умолчанию Apache Kafka® осуществляет взаимодействие в формате PLAINTEXT, что означает, что все данные передаются в открытом виде. Для шифрования взаимодействия необходимо настроить в вашем развертывании все компоненты платформы Confluent на использование шифрования SSL.
Secure Sockets Layer (SSL) является предшественником Transport Layer Security (TLS) и является устаревшим с июня 2015 года. Однако по историческим причинам Kafka (как и Java) использует в конфигурации и в коде термин/аббревиатуру «SSL» вместо «TLS». В этом разделе используется только аббревиатура «SSL».
Вы можете настроить SSL для шифрования или аутентификации. Можно настроить только SSL-шифрование (по умолчанию SSL-шифрование включает аутентификацию сертификата сервера) и независимо выбрать отдельный механизм аутентификации клиента (например, SSL (https://docs.confluent.io/current/kafka/authentication_ssl.html#kafka-ssl-authentication), SASL (https://docs.confluent.io/current/kafka/authentication_sasl/index.html#kafka-sasl-auth)). Технически, SSL шифрование уже включает однонаправленную аутентификацию, при которой клиент аутентифицирует сертификат сервера. Таким образом, в этом разделе «SSL аутентификация» действительно относится к двухсторонней аутентификации, где брокер также аутентифицирует сертификат клиента.
Включение SSL может повлиять на производительность из-за накладных расходов на шифрование.
SSL использует пары закрытый ключ/сертификат, применяемые во время SSL-рукопожатия.
• Каждому брокеру требуется собственная пара секретный ключ/сертификат и клиент использует сертификат для аутентификации брокера.
• Если включена аутентификация клиента, то каждому логическому клиенту требуется пара закрытый ключ/сертификат и брокер использует сертификат для аутентификации клиента.
Вы можете настроить для каждого брокера и логического клиента truststore, который используется для определения того, каким сертификатам (идентификаторам брокера или логического клиента) следует доверять (аутентифицировать их). Truststore можно настроить несколькими способами. Рассмотрим следующие два примера:
• Truststore содержит один или несколько сертификатов: тогда брокер или логический клиент будет доверять любому сертификату, имеющемуся в truststore.
• Truststore содержит Центр Сертификации (Удостоверяющий Центр, Certificate Authority (CA)): тогда брокер или логический клиент будет доверять любому сертификату, подписанному by CA в truststore.
Использование метода CA более удобно, поскольку добавление нового брокера или клиента не требует изменений в truststore. Метод CA описан в этой диаграмме (https://github.com/confluentinc/confluent-platform-security-tools/blob/master/single-trust-store-diagram.pdf).
Однако с помощью метода CA Kafka не поддерживает блокировку аутентификации для отдельных брокеров или клиентов, которым ранее доверяли с помощью этого механизма (отзыв сертификата обычно выполняется с помощью списков отзыва сертификатов (Certificate Revocation Lists) или онлайн-протокола состояния сертификатов (Online Certificate Status Protocol)), поэтому для блокировки доступа необходимо полагаться на авторизацию.
С другой стороны, если используется один или несколько сертификатов, блокировка аутентификации достигается удалением сертификата брокера или клиента из truststore.
t.me/middle_java
