Configura la autenticación 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 la autenticación 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. Consulta Cambia las contraseñas predeterminadas en el archivo de anulación a fin de conocer los pasos necesarios para cambiarlas.

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

  1. Usuario de DML: lo usa el cliente para leer y escribir datos en Cassandra (KMS, KVM, Caché y Cuota).
  2. 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.
  3. Usuario admin: Se usa para cualquier actividad administrativa realizada en el clúster de Cassandra.
  4. Usuario de Cassandra predeterminado: Cassandra crea un usuario predeterminado cuando la autenticación está habilitada y el nombre de usuario es cassandra
  5. Usuario de JMX: Se usa para autenticar y comunicarse con la interfaz de Cassandra JMX.
  6. Usuario Jolokia:Se usa para autenticar y comunicarse con la API de Cassandra JMX.

Acerca del usuario predeterminado de Cassandra

Cuando se crea un clúster de Apigee Hybrid y se habilita la autenticación de Cassandra, la cuenta de usuario inicial es el usuario predeterminado de Cassandra, identificado por el nombre de usuario cassandra. El usuario cassandra predeterminado funciona como superusuario, responsable de tareas como agregar funciones de usuario y modificar el esquema de la base de datos.

El trabajo apigee-cassandra-user-setup híbrido de Apigee usa el usuario cassandra predeterminado para establecer funciones nuevas y actualizar la contraseña asociada con este usuario predeterminado. La ejecución del trabajo apigee-cassandra-user-setup se produce durante la instalación inicial de una instancia de Apigee Hybrid, las actualizaciones de instancia posteriores y el aprovisionamiento de una instancia nueva como parte de la expansión de la región.

Cuando se ejecuta el trabajo apigee-cassandra-user-setup de Apigee Hybrid, necesita la capacidad de actualizar y cambiar las configuraciones de nivel de base de datos, como parte de una instalación nueva o una actualización. El usuario cassandra predeterminado es el único usuario que se garantiza que está presente cuando el trabajo apigee-cassandra-user-setup configura los pods nuevos de Cassandra. Sin un usuario conocido con acceso de superusuario, las actualizaciones de Apigee Hybrid y las expansiones de región no funcionarían de manera correcta.

La contraseña de usuario predeterminada cassandra se cambia después del uso inicial como parte de medidas de seguridad adicionales. Esto significa que, incluso si el usuario predeterminado cassandra aún está habilitado, la nueva contraseña debe ser conocida como el usuario cassandra predeterminado. Ningún otro componente usa el usuario de cassandra predeterminado, excepto el trabajo de apigee-cassandra-user-setup como parte de la nueva instalación y la expansión de región.

Cambia las contraseñas predeterminadas en el archivo de anulación

Como práctica recomendada de seguridad, te recomendamos cambiar las contraseñas predeterminadas para Cassandra. Puedes hacerlo en el archivo overrides.yaml. Agrega la siguiente configuración, cambia las contraseñas predeterminadas como desees y aplica el cambio en tu clúster. Consulta cassandra. Puedes ver las contraseñas predeterminadas en tu archivo values.yaml.

cassandra:
   auth:
     default:  ## the password for the new default user (static username: cassandra)
       password: "NEW_PASSWORD"
     admin: ## the password for the admin user (static username: admin_user)
       password: "NEW_PASSWORD"
     ddl: ## the password for the DDL User (static username: ddl_user)
       password: "NEW_PASSWORD"
     dml: ## the password for the DML User (static username: dml_user)
       password: "NEW_PASSWORD"
     jmx:
       username: "jmxuser" ## the username for the JMX User
       password: "NEW_PASSWORD" ## the password for the JMX User
     jolokia:
       username: "jolokiauser" ## the username to access jolokia interface
       password: "NEW_PASSWORD" ## 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 YAML y edita los atributos obligatorios, por ejemplo, my-secret.yaml. 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: DEFAULT_PASSWORD   #base64-encoded string
  admin.user: ADMIN_USERNAME   #base64-encoded string
  admin.password: ADMIN_PASSWORD   #base64-encoded string
  dml.user: DML_USERNAME   #base64-encoded string
  dml.password: DML_PASSWORD   #base64-encoded string
  ddl.user: DDL_USERNAME   #base64-encoded string
  ddl.password: DDL_PASSWORD   #base64-encoded string
  jmx.user: JMX_USERNAME   #base64-encoded string
  jmx.password: JMX_PASSWORD   #base64-encoded string
  jolokia.user: JOLOKIA_USERNAME   #base64-encoded string
  jolokia.password: JOLOKIA_PASSWORD   #base64-encoded string
  

En el ejemplo anterior, SECRET_NAME es el nombre que eliges para el objeto Secret, APIGEE_NAMESPACE es el espacio de nombres en el que se implementan los pods de Apigee (el valor predeterminado es apigee), y cada _USERNAME y _PASSWORD son los nombres de usuario y 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:

helm upgrade datastore apigee-datastore/ \
--namespace apigee \
--atomic \
-f OVERRIDES_FILE.yaml

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