Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura mTLS nativo de Cassandra

Introducción

De forma predeterminada, los diferentes componentes de Edge para nube privada, como los Message Processor, los servidores de administración y los routers, se conectan a través de un canal de texto simple a los nodos de Cassandra. En esos canales, los datos hacia y desde Cassandra se comunican en texto simple. Apigee mTLS es una función basada en la malla de servicios de Consul que agrega seguridad a las comunicaciones entre los componentes del clúster de Edge para nube privada. Esta oferta de Apigee también agrega seguridad de TLS sobre el canal de comunicación entre los componentes del cliente y Cassandra.

En este artículo, se aborda una nueva oferta alternativa de Apigee en la que la comunicación entre los componentes del cliente y Cassandra en Edge para nube privada se protege a través de TLS mutua (también conocida como TLS bidireccional) con funciones disponibles de forma nativa en Cassandra sin usar una malla de servicios externa.

Función mTLS nativa

Habilitar mTLS entre Cassandra y los componentes del cliente que se describen en este artículo se basa en las funciones de TLS que proporciona Apache Cassandra de forma nativa. Cuando está habilitado, las conexiones de cliente a Cassandra (en el puerto de transporte nativo de CQL 9042) realizan un protocolo de enlace TLS bidireccional con los clientes antes de permitir que se establezcan las conexiones. Para los fines de esta conexión TLS bidireccional, Cassandra actúa como el servidor y los distintos clientes que se conectan a Cassandra (como edge-message-processor, la herramienta cqlsh, etcétera) actúan como clientes.

Para TLS bidireccional (o TLS mutua o mTLS), tanto Cassandra como los clientes deben configurarse con su propio almacén de claves. El almacén de claves de cada nodo de Cassandra debe contener su propia clave y certificado. El almacén de claves de cada aplicación cliente debe contener la clave y el certificado de ese cliente específico. Se debe agregar un almacén de certificados de confianza que contenga los certificados y la cadena asociada de la contraparte tanto en Cassandra como en los clientes. El almacén de certificados de confianza de cada nodo de Cassandra debe contener certificados de clientes, y el almacén de certificados de confianza de cada cliente debe contener certificados de todos los nodos de Cassandra. Puedes consultar el artículo TLS/SSL bidireccional de Apigee para obtener más información sobre cómo funciona, en general, un protocolo de enlace TLS bidireccional.

Encadenamiento de certificados

En general, en TLS bidireccional, los certificados de servidor, los certificados de cliente, las cadenas de certificados, los almacenes de claves y los almacenes de confianza se pueden crear de varias maneras. Lo mismo sucede con mTLS nativa de Cassandra y del cliente. Teniendo en cuenta cómo las organizaciones suelen operar clústeres de Edge para nube privada y la cantidad de pares únicos de conexión de cliente a Cassandra que se pueden establecer, Apigee recomienda adoptar el siguiente enfoque general para configurar claves y certificados para esta función. Existen otros métodos viables, pero es probable que el siguiente método proporcione un buen equilibrio entre la seguridad y la sobrecarga de mantenimiento.

Obtén un certificado raíz y un par de clave/certificado intermedio firmado por la raíz. Es posible que ya tengas esas claves y certificados en tu poder. De lo contrario, puedes crear claves y certificados raíz e intermedios autofirmados con los pasos que se indican en el Apéndice 1.
Usa la clave/certificado intermedio común de arriba para firmar todas las claves y los certificados específicos de la aplicación (hoja).

Tener una clave/certificado intermedio común en 1 clúster hace que se configure un almacén de certificados de confianza común (que contiene la misma cadena de certificados raíz e intermedios) en cada nodo de Cassandra y del cliente. Cada nodo de Cassandra y aplicación cliente obtiene su propia clave y certificado de hoja únicos firmados por la clave/certificado intermedio común.

Rotar un certificado de hoja de un nodo de Cassandra o una aplicación cliente es trivial.
Rotar un certificado intermedio o raíz sigue siendo una operación bastante compleja, pero la frecuencia de esas rotaciones será mucho menor que la de los certificados de hoja.

Usa las prácticas de seguridad de tu organización para decidir si usar certificados raíz e intermedios comunes en diferentes clústeres de nube privada. Puedes consultar el Apéndice 2 para obtener configuraciones de certificados alternativas.

Los pasos restantes de este artículo proporcionan detalles para la metodología anterior de diseño de claves y certificados.

Limitaciones y advertencias

Se aplican las siguientes limitaciones a esta función.

Esta oferta de mTLS nativa entre los componentes del cliente y Cassandra NO es compatible con apigee-mtls. Si usas esta función, no puedes usar apigee-mtls y viceversa.
Habilitar mTLS entre los componentes del cliente y Cassandra tendrá un impacto en el rendimiento de las conexiones que se establezcan entre los clientes y Cassandra. Las operaciones como el inicio de los clientes o el ajuste de escala de las conexiones de Cassandra pueden ser más lentas, ya que Cassandra y los clientes deben negociar TLS primero antes de iniciar la comunicación. El impacto debe ser menor y, por lo general, no se nota.
En Cassandra, mTLS se puede aplicar de forma opcional en las conexiones de cliente entrantes. Si bien se puede habilitar la aplicación, se debe inhabilitar durante las tareas operativas, como las actualizaciones del software de Apigee, la habilitación o inhabilitación de funciones de TLS y ciertos tipos de rotaciones de certificados. Consulta la sección Operaciones y configuraciones para obtener más detalles.
La administración y el mantenimiento de los certificados son responsabilidad del cliente.
La rotación de certificados tiene varios matices. Consulta la sección Rotaciones de certificados para obtener más detalles.

Habilita mTLS nativa

En un nivel superior, habilitar mTLS nativa es un procedimiento de 3 pasos, como se describe a continuación:

Obtén un certificado raíz y un par de clave/certificado intermedio.
Crea un par de clave/certificado de hoja de 1 nodo de Cassandra, fírmalo, almacénalo en un almacén de claves y configura Cassandra para mTLS opcional. Repite los pasos para cada nodo de Cassandra de a 1 por vez.
Crea un par de clave/certificado de hoja de 1 aplicación cliente, fírmalo, almacénalo en un almacén de claves y configura la aplicación cliente para mTLS. Repite los pasos en cada aplicación cliente de a 1 por vez. Aplicaciones cliente:
1. edge-management-server
2. edge-message-processor
3. edge-router

Estos pasos se detallan a continuación:

Obtén certificados raíz e intermedios

Obtén un certificado raíz y un par de clave/certificado intermedio firmado por la raíz. Usa el certificado raíz e intermedio firmado por la AC de tu organización o crea certificados autofirmados. Almacena la cadena de certificados raíz e intermedios en un almacén de confianza. Consulta el Apéndice 1 para obtener comandos útiles. Los comandos posteriores suponen que tienes acceso a los siguientes archivos:

intermediate.key : Archivo de claves para el certificado intermedio para firmar certificados de hoja
intermediate-cert.pem : Certificado intermedio

Configura nodos de Cassandra

Elige un nodo de Cassandra.

Genera un par de clave y certificado de hoja, y fírmalo con el certificado intermedio. Almacena la clave y el certificado firmado en un almacén de claves. Ejemplo a continuación:


# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout cass-node1.key -out cass-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=cassnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in cass-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out cass-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in cass-node1-cert.pem -inkey cass-node1.key -out cass-node1-keystore.pfx -name nativemtls -password pass:keystorepass

Coloca los archivos de almacén de claves y almacén de confianza en una ubicación específica del nodo y asegúrate de que el usuario de Apigee pueda acceder a ellos.

cp cass-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/cass-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties. Agrega el siguiente contenido a este archivo:

### Enable Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=true

### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

### Keystore details
conf_cassandra_client_encryption_keystore=/opt/apigee/customer/application/cass-node1-keystore.pfx
conf_cassandra_client_encryption_keystore_password=keystorepass
conf_cassandra_server_encryption_store_type=PKCS12

### Whether to enable 2-way TLS (or mTLS) - true or false
conf_cassandra_client_encryption_require_client_auth=true

### When 2-way TLS is enabled, client certificate details need to be provided via a truststore
conf_cassandra_client_encryption_truststore=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_client_encryption_truststore_password=trustpass
conf_cassandra_client_encryption_store_type=PKCS12

Asegúrate de que el usuario de Apigee sea el propietario del archivo y pueda leerlo:

chown apigee:apigee /opt/apigee/customer/application/cassandra.properties

Configura y reinicia el nodo de Cassandra.

apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart

Repite los pasos anteriores en cada nodo de Cassandra de a 1 por vez.

Configura aplicaciones cliente

Esta sección se aplica a los siguientes componentes del cliente que se conectan a Cassandra:

edge-management-server
edge-message-processor
edge-router

Elige un componente del cliente.

Genera un par de clave y certificado de hoja, y fírmalo con el certificado intermedio. Almacena la clave y el certificado firmado en un almacén de claves. Ejemplo a continuación:


# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout mgmt-node1.key -out mgmt-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=mgmtnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in mgmt-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out mgmt-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in mgmt-node1-cert.pem -inkey mgmt-node1.key -out mgmt-node1-keystore.pfx -name nativemtls -password pass:keystorepass

Coloca los archivos de almacén de claves y almacén de confianza en una ubicación específica del nodo y asegúrate de que el usuario de Apigee pueda acceder a ellos.

cp mgmt-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/mgmt-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

Crea y edita el archivo de configuración según la aplicación que configures.

Aplicación	Archivo de configuración
Servidor de administración	`/opt/apigee/customer/application/management-server.properties`
Procesador de administración	`/opt/apigee/customer/application/message-processor.properties`
Router	`/opt/apigee/customer/application/router.properties`

Agrega las siguientes configuraciones al archivo:

### Enable TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=true
conf_cassandra_sslconfig.enable.mtls=true

### Keystore Details
conf_cassandra_sslconfig.keystore.path=/opt/apigee/customer/application/mgmt-node1-keystore.pfx
conf_cassandra_sslconfig.keystore.password=keystorepass
conf_cassandra_sslconfig.keystore.type=PKCS12

### Truststore Details
conf_cassandra_sslconfig.truststore.path=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_sslconfig.truststore.password=trustpass
conf_cassandra_sslconfig.truststore.type=PKCS12

Asegúrate de que el usuario de Apigee sea el propietario del archivo de configuración y pueda leerlo.

chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties

Reinicia la aplicación cliente.

# Configure and restart service:
apigee-service component configure
apigee-service component restart
# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart

Para validar que SSL se configuró correctamente en la aplicación cliente, busca registros en las siguientes líneas en el registro del sistema de la aplicación correspondiente:
Opciones de SSL agregadas a la conexión de Cassandra
Repite los pasos anteriores en cada aplicación cliente de a 1 por vez.

Operaciones y configuraciones

Aplicar la mTLS

Cuando no se aplica mTLS en Cassandra, Cassandra acepta conexiones de texto simple de clientes o clientes con los que puede realizar correctamente un protocolo de enlace TLS bidireccional. Para que la aplicación de mTLS funcione, primero se debe configurar mTLS en Cassandra. Para configurar la aplicación de mTLS en Cassandra, sigue los pasos que se indican a continuación:

Elige un nodo de Cassandra.
Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties. Agrega o edita la siguiente propiedad en este archivo:
```
### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false
```
Asegúrate de que el usuario de Apigee sea el propietario del archivo y pueda leerlo.
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```

Configura y reinicia el nodo de Cassandra.

apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart

Repite los pasos anteriores en cada nodo de Cassandra de a 1 por vez.

Una vez que se aplica mTLS en Cassandra, la herramienta de consulta estándar de Cassandra, cqlsh, no puede conectarse a Cassandra directamente. Para configurar cqlsh para SSL, genera una nueva clave y certificado de hoja (similar a la clave y el certificado de hoja para aplicaciones cliente) y haz lo siguiente:

Crea o edita el archivo $HOME/.cassandra/cqlshrc.
Agrega el siguiente contenido al archivo:
```
[ssl]
certfile = /home/admin-user/certs/inter-root.pem
validate = false
userkey = /home/admin-user/certs/cqlsh1.key
usercert = /home/admin-user/certs/cqlsh1-cert.pem
```
- certfile : Archivo de certificado que contiene la cadena de certificados raíz e intermedios
- userkey : Clave de cliente que usará cqlsh. Debe ser un par de clave/certificado de hoja que puedas generar y firmar con el certificado intermedio.
- usercert : Certificado de cliente que usará cqlsh. Debe ser un par de clave/certificado de hoja que puedas generar y firmar con el certificado intermedio.

Ejecuta el comando cqlsh como de costumbre mientras proporcionas el argumento --ssl. Por ejemplo:

$  /opt/apigee/apigee-cassandra/bin/cqlsh --ssl X.X.X.X
Connected to Apigee at X.X.X.X:9042
[cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>

Inhabilita la aplicación de mTLS en Cassandra

Para inhabilitar la aplicación de mTLS en Cassandra, sigue los pasos que se indican a continuación:

Elige un nodo de Cassandra.
Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties. Agrega o edita la siguiente propiedad en este archivo:
```
### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true
```
Asegúrate de que el usuario de Apigee sea el propietario del archivo y pueda leerlo.
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```

Configura y reinicia el nodo de Cassandra.

apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart

Repite los pasos anteriores en cada nodo de Cassandra de a 1 por vez.

Inhabilita mTLS nativa

Inhabilitar mTLS nativa es un proceso de varios pasos, similar a habilitar mTLS nativa. Los pasos de alto nivel son los siguientes:

Inhabilita la aplicación de mTLS en Cassandra (si se aplica).

Inhabilita mTLS en todos los nodos de las siguientes aplicaciones cliente de a 1 por vez:

edge-management-server
edge-message-processor
edge-router

Crea y edita el archivo de configuración según la aplicación que configures:

Aplicación	Archivo de configuración
Servidor de administración	`/opt/apigee/customer/application/management-server.properties`
Procesador de administración	`/opt/apigee/customer/application/message-processor.properties`
Router	`/opt/apigee/customer/application/router.properties`

Agrega o edita las siguientes propiedades en el archivo de configuración:

### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false

Asegúrate de que el usuario de Apigee sea el propietario del archivo de configuración y pueda leerlo:

chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties

Reinicia la aplicación cliente:


# Configure and restart service:
apigee-service component configure
apigee-service component restart

# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart

Repite los pasos del a al d en cada aplicación cliente, de a 1 por vez.

Inhabilita mTLS en todos los nodos de Cassandra de a 1 por vez:
1. Elige un nodo de Cassandra.
2. Crea o edita el archivo /opt/apigee/customer/application/cassandra.properties. Agrega o edita la siguiente propiedad en este archivo:
```
### Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=false
```
  Asegúrate de que el usuario de Apigee sea el propietario del archivo y pueda leerlo.
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```
3. Configura y reinicia el nodo de Cassandra.
4. Repite los pasos del a al c en cada nodo de Cassandra, de a 1 por vez.

Rotaciones de certificados

Rotación solo para certificados de hoja (manteniendo los mismos certificados intermedios y raíz)

Se pueden seguir pasos similares a los de Configura aplicaciones cliente:

Genera una nueva clave/certificado de hoja para una aplicación con la misma clave/certificado intermedio.
Configura la ruta de acceso a la nueva clave/certificado de hoja en la aplicación junto con la contraseña y el tipo de almacén de claves.
Reinicia la aplicación.

Rotación para certificados raíz o intermedios

Si planeas rotar el certificado intermedio o raíz, te recomendamos que lo hagas como un proceso de varios pasos:

Inhabilita mTLS nativa de Cassandra en todo el clúster.
Usa los nuevos certificados raíz e intermedios para generar certificados de hoja o de aplicación nuevos.
Sigue los pasos para habilitar mTLS nativa de Cassandra con el nuevo conjunto de claves y certificados.

Operaciones generales de Apigee

Para realizar operaciones generales de Apigee, como actualizar el software de Apigee, agregar o quitar nodos de Cassandra, agregar o quitar centros de datos, habilitar o inhabilitar la autenticación de Cassandra, etcétera, asegúrate de que no se aplique mTLS en Cassandra. Si aplicaste mTLS, inhabilita la aplicación antes de continuar con estas operaciones.

Apéndice 1

Se pueden seguir los pasos de este apéndice para generar un par de clave/certificado raíz e intermedio autofirmado y agregar esta cadena de certificados a un almacén de certificados de confianza.

Genera certificados raíz e intermedios autofirmados

# Create self-signed root key and cert
openssl req -x509 -newkey rsa:2048 -keyout root.key -out root-cert.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=root.yourorg.com/emailAddress=apigeeroot@yourorg.com"

# Create intermediate key and cert (signed by root)
openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate-req.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=inter.yourorg.com/emailAddress=apigeeinter@yourorg.com"

openssl x509 -req -in intermediate-req.pem -CAkey root.key -CA root-cert.pem -days 3650 -CAcreateserial -out intermediate-cert.pem

Genera un almacén de confianza

# Merge root and intermediate cert into 1 file
cat intermediate-cert.pem > inter-root.pem
cat root-cert.pem >> inter-root.pem

# Create truststore to be used everywhere
keytool -keystore truststore.pfx -storetype PKCS12 -importcert -file inter-root.pem -keypass trustpass -storepass trustpass -alias nativemtls -noprompt

Apéndice 2: Configuraciones alternativas de encadenamiento de certificados

Si bien este artículo recomienda una configuración de encadenamiento de certificados en particular que equilibra la seguridad y la facilidad de las operaciones, existen alternativas que se describen a continuación. La mayoría de los principios generales también se aplican a otras metodologías, como las siguientes:

Tener claves y certificados de hoja directos para cada nodo de Cassandra o aplicación cliente (sin certificados raíz o intermedios de firma). Es probable que esto haga que la rotación de certificados sea compleja.
Tener varios conjuntos raíz e intermedios para diferentes casos de uso. Por ejemplo, los nodos de Cassandra tienen 1 conjunto de certificados raíz/intermedios con el que se firman todos los certificados de hoja de Cassandra. Del mismo modo, todas las aplicaciones cliente pueden tener un conjunto raíz/intermedio separado para firmar certificados de hoja de la aplicación. Esas configuraciones son viables, pero implican agregar la cadena de certificados raíz/intermedios al almacén de confianza adecuado. En este ejemplo, los almacenes de confianza de Cassandra deben contener certificados raíz/intermedios del cliente, y las aplicaciones cliente deben tener la cadena raíz/intermedia de los nodos de Cassandra en su almacén de confianza.
De manera similar a lo anterior, puedes tener varios conjuntos de certificados raíz e intermedios para diferentes regiones , pero todos los clientes y servidores de todas las regiones deben conocer todas las cadenas raíz e intermedios agregándolos todos al almacén de confianza configurado.