Introducción
De forma predeterminada, los diferentes componentes de Edge para la nube privada, como los procesadores de mensajes, los servidores de administración y los routers, se conectan a los nodos de Cassandra a través de un canal de texto sin formato. En esos canales, los datos que se envían a Cassandra y los que se reciben de ella se comunican de forma clara. Apigee mTLS es una función basada en malla de servicios de Consul que agrega seguridad a las comunicaciones entre los componentes del clúster de Edge para la Nube Privada. Esta oferta de Apigee también agrega seguridad de TLS al 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 Private Cloud 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 de 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 de forma nativa Apache Cassandra. Cuando está habilitada, 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 varios clientes que se conectan a Cassandra (como edge-message-processor, la herramienta cqlsh, etcétera) actúan como clientes.
Para la 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 confianza que contenga los certificados y la cadena asociada de la contraparte tanto en Cassandra como en los clientes. El almacén de confianza de cada nodo de Cassandra debe contener los certificados de los clientes, y el almacén de confianza de cada cliente debe contener los certificados de todos los nodos de Cassandra. Puedes consultar el artículo sobre TLS/SSL bidireccional de Apigee para obtener más información sobre cómo funciona generalmente un handshake de 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 Cassandra y la mTLS nativa del cliente. Teniendo en cuenta cómo suelen operar las organizaciones los clústeres de Edge para la 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 proporcione un buen equilibrio entre la seguridad y la sobrecarga de mantenimiento.
Obtén un certificado raíz y un par de certificado y clave intermedios firmados por la raíz. Es posible que ya tengas esas claves y certificados. De lo contrario, puedes crear claves y certificados intermedios y raíz autofirmados siguiendo los pasos que se indican en el Apéndice 1.
- Usa la clave o el certificado intermedio común que se indicó anteriormente para firmar todas las claves y los certificados específicos de la aplicación (hoja).
Tener una clave o un certificado intermedio común en 1 clúster permite que se configure un almacén de confianza común (que contiene la misma cadena de certificados raíz e intermedios) en cada nodo de Cassandra y cliente. Cada nodo de Cassandra y aplicación cliente obtiene su propia clave de hoja y certificado únicos firmados por la clave o el 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 estas 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ás certificados raíz e intermedios comunes en diferentes clústeres de la nube privada. Puedes consultar el Apéndice 2 para conocer otras configuraciones de certificados.
En los pasos restantes de este artículo, se proporcionan detalles sobre la metodología anterior para diseñar claves y certificados.
Limitaciones y advertencias
Se aplican las siguientes limitaciones a esta función.
- Esta oferta de mTLS nativo 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á cierto 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 debería ser menor y, por lo general, no se debería notar.
- En Cassandra, se puede aplicar mTLS de forma opcional en las conexiones de clientes 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 las 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 la mTLS nativa
En términos generales, habilitar mTLS nativo es un procedimiento de 3 pasos, como se describe a continuación:
- Obtén un certificado raíz y un par de certificado/clave intermedio.
- Crea un par de clave y 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 certificado y clave 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 una por vez. Aplicaciones cliente:
- edge-management-server
- edge-message-processor
- edge-router
A continuación, se detallan estos pasos:
Adquiere certificados intermedios y raíz
Obtén un certificado raíz y un par de certificado y clave intermedios firmados por la raíz. Usa el certificado raíz y el certificado intermedio firmados por la CA de tu organización, o bien crea certificados autofirmados. Almacena la cadena de certificados raíz e intermedios en un almacén de confianza. Consulta el Apéndice 1 para ver comandos útiles. Los comandos posteriores suponen que tienes acceso a los siguientes archivos:
intermediate.key
: Es el archivo de claves del certificado intermedio para firmar certificados de hoja.intermediate-cert.pem
: Certificado intermedio
Configura los 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. Consulta el siguiente ejemplo:
# 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
Además, para los sistemas operativos habilitados para FIPS, agrega la siguiente propiedad al archivo
/opt/apigee/customer/application/cassandra.properties
:conf_cassandra_client_encryption_protocol=TLSv1.2
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 uno por vez.
Configura aplicaciones cliente
Esta sección se aplica a los siguientes componentes de 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. Consulta el siguiente ejemplo:
# 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 estés configurando
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 los siguientes parámetros de configuración 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 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 similares a los que se muestran a continuación en el registro del sistema de la aplicación correspondiente:
Se agregaron opciones de SSL a la conexión de Cassandra
- Repite los pasos anteriores en cada aplicación cliente de a una por vez.
Operaciones y configuraciones
Aplicar la mTLS
Cuando no se aplica mTLS en Cassandra, Cassandra acepta conexiones de texto simple de los clientes o de los 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 forzosa de mTLS en Cassandra, sigue estos pasos:
- 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 uno 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 un certificado de hoja (similares a la clave y el certificado de hoja para las 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 intermediosuserkey
: Es la clave del cliente que usará cqlsh. Este debe ser un par de clave y certificado de hoja que puedes generar y firmar con el certificado intermedio.usercert
: Es el certificado de cliente que usará cqlsh. Esta debe ser una clave o un certificado de hoja que puedes generar y firmar con el certificado intermedio.
- Ejecuta el comando
cqlsh
como de costumbre y proporciona 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 estos pasos:
- 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 uno por vez.
Inhabilita la mTLS nativa
Inhabilitar la mTLS nativa es un proceso de varios pasos, similar a habilitar la 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 uno:
- edge-management-server
- edge-message-processor
- edge-router
- Crea y edita el archivo de configuración según la aplicación que estés configurando:
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, una a la vez.
- Inhabilita la mTLS en todos los nodos de Cassandra uno por uno:
- 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:### 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
- Configura y reinicia el nodo de Cassandra
- Repite los pasos del a al c en cada nodo de Cassandra, uno a la vez.
apigee-service apigee-cassandra configure apigee-service apigee-cassandra restart
Rotaciones de certificados
Rotación solo para certificados de hoja (se mantienen los mismos certificados intermedios y raíz)Puedes seguir pasos similares a los de Configura aplicaciones cliente:
- Genera una nueva clave o certificado de hoja para una aplicación con la misma clave o certificado intermedio
- Configura la ruta de acceso a la nueva clave o certificado de hoja en la aplicación junto con la contraseña y el tipo de almacén de claves.
- Reinicia la aplicación
Si planeas rotar el certificado intermedio o raíz, te recomendamos que lo hagas como un proceso de varios pasos:
- Inhabilita la 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 nativo 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., asegúrate de que no se aplique mTLS en Cassandra. Si aplicaste la mTLS, inhabilita la aplicación antes de continuar con estas operaciones.
Apéndice 1
Puedes seguir los pasos de este apéndice para generar un par de clave/certificado raíz y de nivel intermedio autofirmado, y agregar esta cadena de certificados a un almacén 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 el 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 particular de encadenamiento de certificados 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 de hoja y certificados directos para cada nodo de Cassandra o aplicación cliente (sin ninguna raíz de firma ni certificados intermedios) Esto probablemente hará que la rotación de certificados sea compleja.
- Tener varios conjuntos de certificados raíz y de nivel intermedio para diferentes casos de uso Por ejemplo, los nodos de Cassandra tienen un conjunto de certificados intermedios o raíz 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 o intermedio independiente para firmar certificados de hoja de la aplicación. Estas configuraciones son viables, pero implican agregar la cadena de certificados raíz o intermedios al almacén de confianza adecuado. En este ejemplo, los almacenes de confianza de Cassandra deben contener certificados raíz o intermedios del cliente, y las aplicaciones cliente deben tener una cadena raíz o intermedia de nodos de Cassandra en su almacén de confianza.
- Al igual que en el caso 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 intermedias. Para ello, debes agregarlas todas al almacén de confianza configurado.