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