Configurar la API de streaming
Descripción general
En este capítulo se describe cómo configurar la API de streaming para permitir la suscripción a mensajes de métricas a través de Kafka.
A continuación repasaremos:
- Cómo habilitar la API de transmisión
- Cómo configurar Kafka para escuchar a clientes externos
- Cómo configurar Kafka para usar ACL y configurar el cifrado SSL para dichos clientes
¿Qué es Kafka?
Kafka es una plataforma de transmisión de eventos que permite la captura en tiempo real de datos enviados desde varias fuentes de eventos (sensores, bases de datos, dispositivos móviles) en forma de flujos de eventos, así como el almacenamiento duradero de estos flujos de eventos para su posterior recuperación y manipulación.
Con Kafka es posible gestionar la transmisión de eventos de extremo a extremo de forma distribuida, altamente escalable, elástica, tolerante a fallos y segura.
Kafka se puede configurar de muchas maneras diferentes y fue diseñado para escalabilidad y sistemas redundantes. Este documento se centra únicamente en cómo configurarlo para hacer uso de la función API de streaming que se encuentra en el Centro de control de Routing Active Testing. Para configuraciones más avanzadas, consulte la documentación oficial de Kafka: kafka.apache.org/26/documentation.html.
Terminología
- Kafka: Plataforma de transmisión de eventos.
- Tema de Kafka: Colección de eventos.
- Suscriptor/consumidor de Kafka: Componente responsable de la recuperación de eventos almacenados en un tema de Kafka.
- Corredor Kafka: Servidor de capa de almacenamiento de un clúster de Kafka.
- SSL/TLS: SSL es un protocolo seguro desarrollado para enviar información de forma segura a través de Internet. TLS es el sucesor de SSL, introducido en 1999.
- SASL: Marco que proporciona mecanismos para la autenticación del usuario, la comprobación de la integridad de los datos y el cifrado.
- Suscriptor de la API de streaming: Componente responsable de la recuperación de eventos almacenados en temas definidos en Routing Active Testing y destinados al acceso externo.
- Autoridad de certificación: Una entidad de confianza que emite y revoca certificados de clave pública.
- Certificado raíz de la autoridad de certificación: Certificado de clave pública que identifica a una autoridad de certificación.
Cómo funciona la API de streaming
Como se mencionó anteriormente, la API de transmisión permite a los clientes externos recuperar información sobre las métricas de Kafka.
Todas las métricas recopiladas por los agentes de prueba durante una tarea de prueba o supervisión se envían al servicio Stream. Después de una fase de procesamiento, el servicio Stream publica esas métricas en Kafka junto con metadatos adicionales.
Temas de Kafka
Kafka tiene el concepto de temas en los que se publican todos los datos. En Routing Active Testing hay muchos temas de Kafka disponibles; sin embargo, solo un subconjunto de estos está destinado al acceso externo.
Cada cuenta de Routing Active Testing en Control Center tiene dos temas dedicados. A continuación, ACCOUNT se muestra el nombre corto de la cuenta:
paa.public.accounts.{ACCOUNT}.metrics- Todos los mensajes de métricas de la cuenta dada se publican en este tema
- Grandes cantidades de datos
- Alta frecuencia de actualización
paa.public.accounts.{ACCOUNT}.metadata- Contiene metadatos relacionados con los datos de las métricas, por ejemplo, la prueba, el monitor o el agente de prueba asociados con las métricas
- Pequeñas cantidades de datos
- Baja frecuencia de actualización
- Habilitación de la API de streaming
- Verificar que la API de streaming funciona en el centro de control
Habilitación de la API de streaming
Estas instrucciones deben ejecutarse en el servidor del Centro de control utilizando sudo.
Dado que la API de streaming agrega cierta sobrecarga al Centro de control, no está habilitada de forma predeterminada. Para habilitar la API, primero debemos habilitar la publicación de métricas en Kafka en el archivo de configuración principal:
/etc/netrounds/netrounds.conf
KAFKA_METRICS_ENABLED = True KAFKA_PUBLISH_METADATA_FOR_STREAMS = True
Habilitar esta función podría afectar el rendimiento del Centro de control. Asegúrese de haber dimensionado la instancia en consecuencia.
A continuación, para habilitar el reenvío de estas métricas a los temas de Kafka correctos:
/etc/netrounds/metrics.yaml
streaming-api: true
Para habilitar e iniciar los servicios de la API de streaming, ejecute:
sudo ncc services enable timescaledb metrics sudo ncc services start timescaledb metrics
Por último, reinicie los servicios:
sudo ncc services restart
La KAFKA_PUBLISH_RESOURCES configuración ha quedado obsoleta. Debería eliminarse de su configuración. Use KAFKA_PUBLISH_METADATA_FOR_STREAMS = True en cambio.
Verificar que la API de streaming funciona en el centro de control
Estas instrucciones se ejecutarán en el servidor del Centro de control.
Ahora puede verificar que está recibiendo métricas sobre los temas de Kafka correctos. Para ello, instale la kafkacat utilidad:
sudo apt-get update sudo apt-get install kafkacat
Si tiene una prueba o un monitor en ejecución en el Centro de control, debería poder usarlo kafkacat para recibir métricas y metadatos sobre estos temas.
Reemplácelo myaccount con el nombre corto de su cuenta (esto es lo que ve en la URL de su Centro de control):
export METRICS_TOPIC=paa.public.accounts.myaccount.metrics export METADATA_TOPIC=paa.public.accounts.myaccount.metadata
Ahora debería ver las métricas si ejecuta este comando:
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
Para ver los metadatos, ejecute el siguiente comando (tenga en cuenta que esto no se actualizará con tanta frecuencia):
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
kafkacat no se decodificará de forma predeterminada. Para suscribirse correctamente a estos temas, consulte la sección
Ejemplos de clientes.
Esto verifica que tengamos una API de Streaming funcionando desde el Centro de control. Sin embargo, lo más probable es que esté interesado en acceder a los datos desde un cliente externo. La siguiente sección describe cómo abrir Kafka para acceso externo.
Apertura de Kafka para hosts externos
Estas instrucciones se ejecutarán en el servidor del Centro de control.
De forma predeterminada, Kafka que se ejecuta en el Centro de control está configurado para escuchar solo en localhost para uso interno. Es posible abrir Kafka para clientes externos modificando la configuración de Kafka.
- Conexión con Kafka: advertencias
- Cifrado SSL/TLS
- Descripción general del certificado SSL/TLS
- Creación de los certificados necesarios
- Configuración SSL/TLS de Kafka Broker en el centro de control
- Configuración de listas de control de acceso (ACL)
Conexión con Kafka: advertencias
Lea esto detenidamente, ya que es fácil encontrarse con problemas de conexión con Kafka si no ha entendido estos conceptos.
En la configuración del Centro de control descrita en este documento, solo hay un agente de Kafka.
Sin embargo, tenga en cuenta que un corredor de Kafka está destinado a ejecutarse como parte de un grupo de Kafka que puede consistir en muchos corredores de Kafka.
Cuando se conecta a un agente de Kafka, el cliente de Kafka establece una conexión inicial. A través de esta conexión, el broker de Kafka, a su vez, devolverá una lista de "oyentes anunciados", que es una lista de uno o más brokers de Kafka.
Al recibir esta lista, el cliente de Kafka se desconectará y luego se volverá a conectar con uno de estos oyentes anunciados. Los listeners anunciados deben contener nombres de host o direcciones IP a los que pueda acceder el cliente de Kafka, o el cliente no podrá conectarse.
Si se utiliza el cifrado SSL, que implica un certificado SSL que está vinculado a un nombre de host en particular, es aún más importante que el cliente Kafka reciba la dirección correcta para conectarse, ya que de lo contrario la conexión puede ser rechazada.
Lea más sobre los oyentes de Kafka aquí: www.confluent.io/blog/kafka-listeners-explained
Cifrado SSL/TLS
Para asegurarnos de que solo los clientes de confianza pueden acceder a Kafka y a la API de Streaming, debemos configurar lo siguiente:
- Autentificación: Los clientes deben proporcionar el nombre de usuario y la contraseña a través de una conexión segura SSL/TLS entre el cliente y Kafka.
- Autorización: Los clientes autenticados pueden realizar tareas reguladas por ACL.
Aquí hay una descripción general:
Para comprender completamente cómo funciona el cifrado SSL/TLS para Kafka, consulte la documentación oficial: docs.confluent.io/platform/current/kafka/encryption.html
Descripción general del certificado SSL/TLS
En esta subsección utilizaremos la siguiente terminología:
Certificado: Un certificado SSL firmado por una autoridad de certificación (AC). Cada corredor de Kafka tiene uno.
Almacén de claves: El archivo de almacén de claves que almacena el certificado. El archivo de almacén de claves contiene la clave privada del certificado; por lo tanto, debe guardarse de forma segura.
Almacén de confianza: Un archivo que contiene los certificados de AC de confianza.
Para configurar la autenticación entre un cliente externo y Kafka que se ejecuta en el Centro de control, ambos lados deben tener un almacén de claves definido con un certificado relacionado firmado por una autoridad de certificación (AC) junto con el certificado raíz de la AC.
Además de esto, el cliente también debe tener un almacén de confianza con el certificado raíz de AC.
El certificado raíz de AC es común al agente de Kafka y al cliente de Kafka.
Creación de los certificados necesarios
Esto se trata en el Apéndice.
Configuración SSL/TLS de Kafka Broker en el centro de control
Estas instrucciones se ejecutarán en el servidor del Centro de control.
Antes de continuar, debe crear el almacén de claves que contiene el certificado SSL siguiendo las instrucciones del apéndice. Las rutas que se mencionan a continuación provienen de estas instrucciones.
El almacén de claves SSL es un archivo almacenado en disco con la extensión de archivo .jks.
Una vez que tenga disponibles los certificados necesarios creados tanto para el agente de Kafka como para el cliente de Kafka, puede continuar configurando el agente de Kafka que se ejecuta en el Centro de control. Necesitas saber lo siguiente:
<public_hostname>: El nombre de host público del Centro de control; debe ser resoluble y accesible para los clientes de Kafka.<keystore_pwd>: La contraseña del almacén de claves proporcionada al crear el certificado SSL.<admin_pwd>y : Estas son las contraseñas que desea establecer para el usuario administrador y<client_pwd>cliente respectivamente. Tenga en cuenta que puede agregar más usuarios, como se indica en el ejemplo.
Edite o agregue (con sudo acceso) las propiedades a continuación en /etc/kafka/server.properties, insertando las variables anteriores como se muestra:
No lo elimine PLAINTEXT://localhost:9092; esto interrumpirá la funcionalidad del Centro de control ya que los servicios internos no podrán comunicarse.
...
# The addresses that the Kafka broker listens on.
listeners=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# These are the hosts advertised back to any client connecting.
advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL://<public_hostname>:9093
...
####### CUSTOM CONFIG
# SSL CONFIGURATION
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=<keystore_pwd>
ssl.key.password=<keystore_pwd>
ssl.client.auth=none
ssl.protocol=TLSv1.2
# SASL configuration
sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
username="admin" \
password="<admin_pwd>" \
user_admin="<admin_pwd>" \
user_client="<client_pwd>";
# NOTE more users can be added with user_<name>=
# Authorization, turn on ACLs
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=User:admin
Configuración de listas de control de acceso (ACL)
Activar las ACL en localhost
Primero debemos configurar ACL para localhost, de modo que el propio Centro de control pueda seguir accediendo a Kafka. Si esto no se hace, las cosas se romperán.
######### ACLs entries for anonymous users /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:ANONYMOUS --allow-host 127.0.0.1 --cluster /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:ANONYMOUS --allow-host 127.0.0.1 --topic '*' /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:ANONYMOUS --allow-host 127.0.0.1 --group '*'
A continuación, debemos habilitar las ACL para el acceso externo de solo lectura, de modo que los usuarios externos puedan leer los paa.public.* temas.
Para un control más detallado, consulte la documentación oficial de Kafka.
######### ACLs entries for external users /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:* --operation read --operation describe \ --group 'NCC' /usr/lib/kafka/bin/kafka-acls.sh \ --authorizer kafka.security.authorizer.AclAuthorizer \ --authorizer-properties zookeeper.connect=localhost:2181 \ --add --allow-principal User:* --operation read --operation describe \ --topic paa.public. --resource-pattern-type prefixed
Una vez hecho esto, debe reiniciar los servicios:
sudo ncc services restart
Para comprobar que un cliente puede establecer una conexión segura, ejecute el siguiente comando en un equipo cliente externo (no en el servidor del Centro de control). A continuación, PUBLIC_HOSTNAME se muestra el nombre de host del Centro de control:
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "Secure Renegotiation IS supported"
Secure Renegotiation IS supported
Para asegurarse de que los servicios internos tienen acceso al servidor de Kafka, compruebe los siguientes archivos de registro:
/var/log/kafka/server.log/var/log/kafka/kafka-authorizer.log
Validación de la conectividad de clientes externos
kafkacat
Estas instrucciones deben ejecutarse en un equipo cliente (no en el servidor del Centro de control).
Para mostrar información de métricas, asegúrese de que al menos un monitor se esté ejecutando en el Centro de control.
Para verificar y validar la conectividad como cliente externo, es posible utilizar la kafkacat utilidad que se instaló en la sección Verificar que la API de transmisión funcione en el Centro de controlVerificar que la API de transmisión funciona en el Centro de control.
Realice los siguientes pasos:
A continuación, CLIENT_USER se muestra el usuario especificado previamente en el archivo /etc/kafka/server.properties en el Centro de control: es decir, user_client y la contraseña establecida allí.
El certificado raíz de AC utilizado para firmar el certificado SSL del lado del servidor debe estar presente en el cliente.
-
Cree un archivo
client.propertiescon el siguiente contenido:security.protocol=SASL_SSL ssl.ca.location={PATH_TO_CA_CERT} sasl.mechanisms=PLAIN sasl.username={CLIENT_USER} sasl.password={CLIENT_PASSWORD}donde
{PATH_TO_CA_CERT}es la ubicación del certificado raíz de AC utilizado por el broker de Kafka{CLIENT_USER}y{CLIENT_PASSWORD}son las credenciales de usuario del cliente.
-
Ejecute el comando siguiente para ver el mensaje consumido por
kafkacat:export KAFKA_FQDN=<Control Center hostname> export METRICS_TOPIC=paa.public.accounts.<account short name>.metrics kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -edonde
{METRICS_TOPIC}es el nombre del tema de Kafka con el prefijo"paa.public.".
Las versiones anteriores de kafkacat no proporcionan la opción de leer la -F configuración del cliente desde un archivo. Si está utilizando una versión de este tipo, debe proporcionar la misma configuración desde la línea de comandos que se muestra a continuación.
kafkacat -b ${KAFKA_FQDN}:9093 \
-X security.protocol=SASL_SSL \
-X ssl.ca.location={PATH_TO_CA_CERT} \
-X sasl.mechanisms=PLAIN \
-X sasl.username={CLIENT_USER} \
-X sasl.password={CLIENT_PASSWORD} \
-t ${METRICS_TOPIC} -C -e
Para depurar la conectividad, puede usar la -d opción:
Debug consumer communications
kafkacat -d consumer -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# Debug broker communications
kafkacat -d broker -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
Asegúrese de consultar la documentación de la biblioteca cliente de Kafka en uso, ya que las propiedades pueden diferir de las de client.properties.
Formato del mensaje
Los mensajes utilizados para los temas de métricas y metadatos se serializan en el formato de búferes de protocolo (protobuf) (consulte developers.google.com/protocol-buffers). Los esquemas de estos mensajes se ajustan al formato siguiente:
Métricas Esquema Protobuf
syntax = "proto3";
import "google/protobuf/timestamp.proto";
package paa.streamingapi;
option go_package = ".;paa_streamingapi";
message Metrics {
google.protobuf.Timestamp timestamp = 1;
map<string, MetricValue> values = 2;
int32 stream_id = 3;
}
/**
* A metric value can be either an integer or a float.
*/
message MetricValue {
oneof type {
int64 int_val = 1;
float float_val = 2;
}
}
Esquema Protobuf de metadatos
syntax = "proto3";
package paa.streamingapi;
option go_package = ".;paa_streamingapi";
message Metadata {
int32 stream_id = 1;
string stream_name = 2;
map <string, string> tags = 13;
}
Ejemplos de clientes
Estos comandos están diseñados para ejecutarse en un cliente externo, por ejemplo, su computadora portátil o similar, y no en el Centro de control.
Para que se muestre la información de las métricas, asegúrese de que al menos un monitor se esté ejecutando en el Centro de control.
El tarball del Centro de control incluye el archivo paa-streaming-api-client-examples.tar.gz (client-examples), que contiene un script de Python de ejemplo que muestra cómo usar la API de transmisión.
- Ejemplos de instalación y configuración de clientes
- Uso de ejemplos de clientes
- Validación de la autenticación de cliente externo
Ejemplos de instalación y configuración de clientes
Encontrará client-examples en la carpeta Centro de control de pruebas activas de enrutamiento:
export CC_VERSION=4.6.3.31
cd ./paa-control-center_${CC_VERSION}
ls paa-streaming-api-client-examples*
Para instalar client-examples en su computadora cliente externa, proceda de la siguiente manera:
# Create directory for extracting the content of the client examples tarball mkdir paa-streaming-api-client-examples # Extract the content of the client examples tarball tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples # Go to the newly created directory cd paa-streaming-api-client-examples
client-examples requiere Docker para ejecutarse. Las descargas y las instrucciones de instalación para Docker se pueden encontrar en https://docs.docker.com/engine/install.
Uso de ejemplos de clientes
Las client-examples herramientas pueden ejecutarse en modo básico o avanzado para crear ejemplos de complejidad variable. En ambos casos, también es posible ejecutar los ejemplos con un archivo de configuración que contiene propiedades adicionales para una mayor personalización del lado del cliente.
Modo básico
En el modo básico, las métricas y sus metadatos se transmiten por separado. Con este fin, el cliente escucha cada tema de Kafka disponible para acceso externo y simplemente imprime los mensajes recibidos en la consola.
Para iniciar la ejecución de los ejemplos básicos, ejecute:
./build.sh run-basic --kafka-brokers localhost:9092 --account ACCOUNT_SHORTNAME
donde ACCOUNT_SHORTNAME es el nombre corto de la cuenta de la que desea obtener las métricas.
Para finalizar la ejecución del ejemplo, presione Ctrl + C. (Puede haber un ligero retraso antes de que se detenga la ejecución porque el cliente espera un evento de tiempo de espera).
Modo avanzado
Las métricas solo se muestran para los monitores HTTP que se ejecutan en el Centro de control.
La ejecución en modo avanzado muestra la correlación entre las métricas y los mensajes de metadatos. Esto es posible gracias a la presencia en cada mensaje de métricas de un stream id campo que hace referencia al mensaje de metadatos correspondiente.
Para ejecutar los ejemplos avanzados, ejecute:
./build.sh run-advanced --kafka-brokers localhost:9092 --account ACCOUNT_SHORTNAME
donde ACCOUNT_SHORTNAME es el nombre corto de la cuenta de la que desea obtener las métricas.
Para finalizar la ejecución del ejemplo, presione Ctrl + C. (Puede haber un ligero retraso antes de que se detenga la ejecución porque el cliente espera un evento de tiempo de espera).
Configuraciones adicionales
Es posible ejecutar los ejemplos con una configuración adicional del cliente utilizando la --config-file opción seguida de un nombre de archivo que contiene propiedades en el formato key=value.
./build.sh run-advanced \ --kafka-brokers localhost:9092 \ --account ACCOUNT_SHORTNAME \ --config-file client_config.properties
Todos los archivos a los que se hace referencia en el comando anterior deben encontrarse en el directorio actual y hacer referencia a ellos utilizando solo rutas relativas. Esto se aplica tanto al argumento como a --config-file todas las entradas del archivo de configuración que describen las ubicaciones de los archivos.
Validación de la autenticación de cliente externo
Para validar la autenticación del cliente desde fuera del centro de control mediante client-examples, realice los siguientes pasos:
-
En la carpeta Centro de control de pruebas activas de enrutamiento, cambie a la
paa-streaming-api-client-examplescarpeta:cd paa-streaming-api-client-examples
- Copie el certificado
ca-certraíz de AC en el directorio actual. -
Cree un
client.propertiesarchivo con el siguiente contenido:security.protocol=SASL_SSL ssl.ca.location=ca-cert sasl.mechanism=PLAIN sasl.username={CLIENT_USER} sasl.password={CLIENT_PASSWORD}donde
{CLIENT_USER}y{CLIENT_PASSWORD}son las credenciales de usuario del cliente. -
Ejecute ejemplos básicos:
export KAFKA_FQDN=<Control Center hostname> ./build.sh run-basic --kafka-brokers ${KAFKA_FQDN}:9093 \ --account ACCOUNT_SHORTNAME --config-file client.propertiesdonde
ACCOUNT_SHORTNAMEes el nombre corto de la cuenta de la que desea obtener las métricas. -
Ejecute ejemplos avanzados:
export KAFKA_FQDN=<Control Center hostname> ./build.sh run-advanced --kafka-brokers ${KAFKA_FQDN}:9093 \ --account ACCOUNT_SHORTNAME --config-file client.properties
Apéndice
En este apéndice describimos cómo crear:
- un archivo de almacén de claves para almacenar el certificado SSL del agente Kafka
- un archivo de almacén de confianza para almacenar el certificado raíz de la autoridad de certificación (AC) utilizado para firmar el certificado de agente de Kafka.
- Creación de un certificado de Kafka Broker
- Creación del almacén de confianza del cliente
- Creación del almacén de claves para Kafka Broker
Creación de un certificado de Kafka Broker
Creación de un certificado mediante una autoridad de certificación real (recomendado)
Se recomienda obtener un certificado SSL real de una AC de confianza.
Una vez que se haya decidido por una AC, copie su archivo de certificado ca-cert raíz de AC en su propia ruta como se muestra a continuación:
export CA_PATH=~/my-ca
mkdir ${CA_PATH}
cp ca-cert ${CA_PATH}
Cree su propia autoridad de certificación
Normalmente, debe tener su certificado firmado por una autoridad de certificación real; consulte la subsección anterior. Lo que sigue es solo un ejemplo.
Aquí creamos nuestro propio archivo de certificado raíz de autoridad de certificación (AC) válido por 999 días (no recomendado en producción):
# Create a directory for storing the CA
export CA_PATH=~/my-ca
mkdir ${CA_PATH}
# Generate the CA certificate
openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999
Creación del almacén de confianza del cliente
Ahora puede crear un archivo de almacén de confianza que contenga lo ca-cert generado anteriormente. Este archivo será necesario para el cliente Kafka que accederá a la API de Streaming:
keytool -keystore kafka.client.truststore.jks \
-alias CARoot \
-importcert -file ${CA_PATH}/ca-cert
Ahora que el certificado de AC está en el almacén de confianza, el cliente confiará en cualquier certificado firmado con él.
Debe copiar el archivo kafka.client.truststore.jks en una ubicación conocida del equipo cliente y apuntar a él en la configuración.
Creación del almacén de claves para Kafka Broker
Para generar el certificado SSL del agente de Kafka y, a continuación, el almacén kafka.server.keystore.jksde claves, proceda de la siguiente manera:
Generación del certificado SSL
Utilice estos comandos para generar el certificado SSL. A continuación, 999 es el número de días de validez del almacén de claves.
sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/private
cd /var/ssl/private
export CC_IP=<Control Center IP>
keytool -keystore kafka.server.keystore.jks \
-alias server \
-validity 999 \
-genkey -keyalg RSA -ext SAN=ip:${CC_IP}
Para comprobar el certificado SSL, puede utilizar el siguiente comando:
keytool -v -list -keystore kafka.server.keystore.jks -alias server
Debe asegurarse de que los clientes externos puedan acceder al puerto 9093 .
Cree una solicitud de firma de certificado y guárdela en el archivo denominado cert-server-request:
keytool -keystore kafka.server.keystore.jks \
-alias server \
-certreq \
-file cert-server-request
Ahora debe enviar el archivo cert-server-request a su autoridad de certificación (AC) si está utilizando una real. A continuación, devolverán el certificado firmado. Nos referiremos a esto a cert-server-signed continuación.
Firmar el certificado SSL con un certificado de AC de creación propia
Nuevamente, no se recomienda usar su propia AC en un sistema de producción.
Firme el certificado mediante la AC mediante el archivo cert-server-request, que produce el certificado cert-server-signedfirmado . Ver más abajo; ca-password es la contraseña establecida al crear el certificado de AC.
cd /var/ssl/private
openssl x509 -req \
-CA ${CA_PATH}/ca-cert \
-CAkey ${CA_PATH}/ca-key \
-in cert-server-request \
-out cert-server-signed \
-days 999 -CAcreateserial \
-passin pass:{ca-password}
Importación del certificado firmado al almacén de claves
Importe el ca-cert certificado raíz en el almacén de claves:
keytool -keystore kafka.server.keystore.jks \
-alias ca-cert \
-import \
-file ${CA_PATH}/ca-cert
Importe el certificado firmado denominado cert-server-signed:
keytool -keystore kafka.server.keystore.jks \
-alias server \
-import \
-file cert-server-signed
El archivo kafka.server.keystore.jks debe copiarse en una ubicación conocida en el servidor del Centro de control y, a continuación, se debe hacer referencia a él en /etc/kafka/server.properties.