Esta página se ha traducido con Cloud Translation API.

Configurar TLS para Cassandra

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 de ejecución

Cassandra proporciona una comunicación segura entre un equipo cliente y un clúster de bases de datos, así como entre los nodos de un clúster. Al habilitar el cifrado, se asegura de que los datos en tránsito no se vean comprometidos y se transfieran de forma segura. En Apigee hybrid, TLS está habilitado de forma predeterminada para cualquier comunicación entre nodos de Cassandra y entre clientes y nodos de Cassandra.

Puedes configurar la autenticación con combinaciones de nombre de usuario y contraseña directamente en el archivo de anulaciones o añadiéndolas a un secreto de Kubernetes, como se explica en este tema.

Acerca de la autenticación de usuarios de Cassandra

La plataforma híbrida usa Cassandra como almacén de datos backend para los datos del plano de tiempo de ejecución. De forma predeterminada, todas las comunicaciones del cliente con Cassandra requieren autenticación. Hay varios usuarios de cliente que se comunican con Cassandra. Se proporcionan contraseñas predeterminadas para estos usuarios, pero no es obligatorio cambiarlas.

Estos usuarios, incluido un usuario predeterminado, se describen a continuación:

Usuario de DML: se usa en la comunicación del cliente para leer y escribir datos en Cassandra (KMS, KVM, caché y cuota).
Usuario de DDL: MART lo usa para cualquier tarea de definición de datos, como la creación, la actualización y la eliminación de espacios de claves.
Usuario administrador: se usa para cualquier actividad administrativa realizada en el clúster de Cassandra.
Usuario predeterminado de Cassandra: Cassandra crea un usuario predeterminado cuando se habilita la autenticación y el nombre de usuario es cassandra.
Usuario de JMX: se usa para autenticar y comunicarse con la interfaz JMX de Cassandra.
Usuario de Jolokia: se usa para autenticar y comunicarse con la API JMX de Cassandra.

Cambiar las contraseñas predeterminadas en el archivo de anulaciones

Apigee hybrid proporciona contraseñas predeterminadas para los usuarios de Cassandra. Si quieres cambiar las contraseñas de usuario predeterminadas, puedes hacerlo en el archivo overrides.yaml. Añade la siguiente configuración, cambia las contraseñas predeterminadas ("iloveapis123") como quieras y aplica el cambio a 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 la autoridad de certificación (CA).
No se admite un certificado de servidor generado con una contraseña.

Configurar nombres de usuario y contraseñas en un secreto de Kubernetes

En esta sección se explica cómo configurar Cassandra para que use secretos de Kubernetes en la autenticación.

Crear el secreto

Usa la siguiente plantilla para configurar el secreto de Kubernetes. Guarda la plantilla en un archivo y edita los atributos necesarios. Ten en cuenta que, si utilizas 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

Donde $SECRET_NAME es el nombre que elijas para el secreto, $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 de cada usuario. Ten en cuenta que el nombre de usuario y la contraseña deben estar codificados en Base64.

Aplica el secreto al clúster. Por ejemplo:

kubectl apply -f $SECRET_FILE

Añade el secreto a tu archivo de anulaciones:

cassandra:
  auth:
    secret: $SECRET_NAME

Aplica la sustitución de Cassandra actualizada al clúster:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --datastore

Consultar los registros de Cassandra

Consulta los registros en cuanto se inicie Cassandra. En el registro que se muestra a continuación se indica que las conexiones de cliente de Cassandra están cifradas.

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...