En este tema, se explica cómo configurar la autenticación para la comunicación entre nodos de Cassandra, y entre clientes y nodos de Cassandra.
Cómo configurar TLS para Cassandra en el plano del entorno de ejecución
Cassandra proporciona comunicación segura entre una máquina cliente y un clúster de base de datos, y entre nodos dentro de un clúster. Habilitar la encriptación garantiza que los datos en tránsito no se vean comprometidos y se transfiera de forma segura. En Apigee Hybrid, TLS está habilitado de forma predeterminada para cualquier comunicación entre los nodos de Cassandra y entre los clientes y los nodos de Cassandra.
Puedes configurar la autenticación con combinaciones de nombre de usuario y contraseña que se colocan directamente en el archivo de anulación o que se agregan a un Secret de Kubernetes, como se explica en este tema.
Acerca de la autenticación de usuarios de Cassandra
La plataforma híbrida usa Cassandra como el almacén de datos de backend para los datos del plano de entorno de ejecución. De forma predeterminada, cualquiera de las comunicaciones del cliente con Cassandra requiere autenticación. Hay varios usuarios cliente que se comunican con Cassandra. Se proporcionan las contraseñas predeterminadas para estos usuarios, y no es necesario que las modifiques.
Estos usuarios, incluido un usuario predeterminado, se describen a continuación:
- Usuario de DML: Lo usa la comunicación del cliente para leer y escribir datos en Cassandra (KMS, KVM, Caché y Cuota).
- Usuario de DDL: Lo usa MART para cualquiera de las tareas de definición de datos, como la creación, actualización y eliminación de espacios de claves.
- Usuario admin: Se usa para cualquier actividad administrativa realizada en el clúster de Cassandra.
- Usuario de Cassandra predeterminado: Cassandra crea un usuario predeterminado cuando la autenticación está habilitada y el nombre de usuario es
cassandra - Usuario de JMX: Se usa para autenticar y comunicarse con la interfaz de Cassandra JMX.
- Usuario Jolokia:Se usa para autenticar y comunicarse con la API de Cassandra JMX.
Cambia las contraseñas predeterminadas en el archivo de anulación
Apigee Hybrid proporciona contraseñas predeterminadas para los usuarios de Cassandra. Si deseas cambiar las contraseñas de usuario predeterminadas, puedes hacerlo en el archivo overrides.yaml. Agrega la siguiente configuración, cambia las contraseñas predeterminadas ("iloveapis123") como desees y aplica el cambio en tu clúster.
cassandra: auth: default: ## the password for the new default user (static username: cassandra) password: "iloveapis123" admin: ## the password for the admin user (static username: admin_user) password: "iloveapis123" ddl: ## the password for the DDL User (static username: ddl_user) password: "iloveapis123" dml: ## the password for the DML User (static username: dml_user) password: "iloveapis123" jmx: username: "jmxuser" ## the username for the JMX User password: "iloveapis123" ## the password for the JMX User jolokia: username: "jolokiauser" ## the username to access jolokia interface password: "iloveapis123" ## the password for jolokia user
Ten en cuenta lo siguiente:
- No se admite la rotación de autoridad certificada (CA).
- No se admite un certificado de servidor que se genere con una frase de contraseña.
Configura nombres de usuario y contraseñas en un Secret de Kubernetes
En esta sección, se explica cómo configurar Cassandra a fin de usar Secrets de Kubernetes para la autenticación.
Crea el Secret
Usa la siguiente plantilla para configurar Secret de Kubernetes. Guarda la plantilla en un archivo y edita los atributos obligatorios. Ten en cuenta que si usas esta opción, debes proporcionar los nombres de usuario con cada contraseña.
apiVersion: v1 kind: Secret metadata: name: $SECRET_NAME namespace: $APIGEE_NAMESPACE type: Opaque data: default.password: $PASSWORD #base64-encoded string admin.user: $USERNAME #base64-encoded string admin.password: $PASSWORD #base64-encoded string dml.user: $USERNAME #base64-encoded string dml.password: $PASSWORD #base64-encoded string ddl.user: $USERNAME #base64-encoded string ddl.password: $PASSWORD #base64-encoded string jmx.user: $USERNAME #base64-encoded string jmx.password: $PASSWORD #base64-encoded string jolokia.user: $USERNAME #base64-encoded string jolokia.password: $PASSWORD #base64-encoded string
En el ejemplo anterior, $SECRET_NAME es el nombre que eliges para Secret, $APIGEE_NAMESPACE
es el espacio de nombres en el que se implementan los pods de Apigee (el valor predeterminado es apigee), y $USERNAME
y $PASSWORD son los nombres de usuario y las contraseñas para cada usuario. Ten en cuenta que el
nombre de usuario y la contraseña deben estar codificados en Base64.
Aplica el Secret al clúster. Por ejemplo:
kubectl apply -f $SECRET_FILE
Agrega el Secret a tu archivo de anulaciones:
cassandra: auth: secret: $SECRET_NAME
Aplica la anulación actualizada de Cassandra al clúster:
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --datastore
Verifica los registros de Cassandra
Revisa los registros en cuanto se inicie Cassandra. En el siguiente registro, se muestra que las conexiones de cliente de Cassandra están encriptadas.
kubectl logs apigee-cassandra-2 -n apigee -f INFO 00:44:36 Starting listening for CQL clients on /10.0.2.12:9042 (encrypted)... INFO 00:44:36 Binding thrift service to /10.0.2.12:9160 INFO 00:44:36 enabling encrypted thrift connections between client and server INFO 00:44:36 Listening for thrift clients...