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:
- Usuario de DML: lo usa el 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.
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...