- v1.15 (última)
- v1.14
- v1.13
- Lista de versiones admitidas
- v1.12
- v1.11
- v1.10
- v1.9
- v1.8
- v1.7
- Versión 1.6
- v1.5
- Versión 1.4
- Versión 1.3
- v1.2
- v1.1
Versiones compatibles:
Versiones no compatibles:
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 de 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. Consulta Cambiar las contraseñas predeterminadas en el archivo de anulaciones para ver los pasos que debes seguir para cambiar las contraseñas predeterminadas.
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: 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.
Acerca del usuario predeterminado de Cassandra
Cuando se crea un clúster híbrido de Apigee 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 y se encarga de tareas como añadir roles de usuario y modificar el esquema de la base de datos.
El trabajo de Apigee hybrid apigee-cassandra-user-setup utiliza el usuario cassandra predeterminado para establecer nuevos roles y actualizar la contraseña asociada a este usuario predeterminado. El trabajo apigee-cassandra-user-setup se ejecuta durante la instalación inicial de una instancia de Apigee Hybrid, las actualizaciones posteriores de la instancia y el aprovisionamiento de una nueva instancia como parte de la expansión de la región.
Cuando se ejecuta el trabajo de Apigee hybrid apigee-cassandra-user-setup, este necesita poder actualizar y modificar las configuraciones a nivel de base de datos, ya sea como parte de una instalación nueva o de una actualización. El usuario cassandra predeterminado es el único que tiene garantizada su presencia cuando el trabajo apigee-cassandra-user-setup está configurando los nuevos pods de Cassandra. Si no hay ningún usuario conocido con acceso de superusuario, las actualizaciones y las ampliaciones de regiones de Apigee hybrid no funcionarán correctamente.
La contraseña de usuario predeterminada cassandra se cambia después del uso inicial como parte de las medidas de seguridad adicionales. Esto significa que, aunque el usuario cassandra predeterminado siga habilitado, se debe conocer la nueva contraseña para usarlo.cassandra Ningún otro componente utiliza el usuario cassandra predeterminado, excepto el trabajo apigee-cassandra-user-setup como parte de la nueva instalación y la expansión de la región.
Cambiar las contraseñas predeterminadas en el archivo de anulaciones
Como medida de seguridad recomendada, te aconsejamos que cambies las contraseñas predeterminadas de Cassandra. Puedes hacerlo en el archivo overrides.yaml. Añade la siguiente configuración, cambia las contraseñas predeterminadas como quieras y aplica el cambio a 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 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 YAML y edita los atributos necesarios, como my-secret.yaml.
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: 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
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 cada _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:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
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_NAMESPACE -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...