Cassandra Autenticación y autorización JMX: crear usuario

Por: David Carter David Carter
Hours Actualizado

⚡ Resumen inteligente

Cassandra La seguridad se basa en la autenticación interna, los permisos de rol, las reglas del firewall y el control de acceso JMX. Esta página muestra cómo habilitar cada capa, crear usuarios, otorgar permisos y proteger el acceso remoto a nodetool.

  • 🔐 Dos capas: La autenticación demuestra quién es un usuario; la autorización decide qué puede hacer ese usuario.
  • ⚙️ Habilítalo: Ambas opciones están desactivadas por defecto y se activan a través de la configuración del autenticador y del autorizador.
  • 👤 Cuenta predeterminada: El superusuario integrado de Cassandra crea todas las demás cuentas, así que cambie su contraseña inmediatamente.
  • 🔑 Modelo de subvención: Los permisos como SELECT, MODIFY y ALTER se otorgan por recurso con GRANT.
  • 📡 Control de puerto: Abra los puertos 7000, 7001, 7199 y 9042 entre los nodos y mantenga la autenticación JMX.
Descubre más

Cassandra Autenticación y autorización JMX

Hay dos tipos de seguridad en Apache Cassandra y DataStax Enterprise.

  • Autenticación interna
  • Autorización

¿Qué es la autenticación y autorización internas?

La autenticación interna consiste básicamente en validar la conexión de un usuario. El usuario se autentica con nombre de usuario y contraseña. Todas las cuentas de usuario se gestionan en Cassandra internamente.

La autorización interna se refiere a los permisos de un usuario. Define las acciones que un usuario puede realizar. Por ejemplo, podemos otorgar permisos como qué usuario tiene permiso solo para leer datos, qué usuario tiene permiso para escribir datos y qué usuario tiene permiso para eliminar datos.

Sin embargo, la autenticación también se puede controlar externamente con Kerberos (Kerberos se utiliza para gestionar las credenciales de forma segura) y LDAP (LDAP se utiliza para almacenar información autorizada sobre las cuentas, como a qué tienen permiso para acceder).

La autenticación externa es la autenticación compatible con Kerberos y LDAP. Apache Cassandra no admite autenticación externa.

Solo DataStax Enterprise admite la autenticación externa con Kerberos y LDAP, mientras que la autenticación interna es compatible con ambas. Apache Cassandra así como DataStax Enterprise.

Configurar autenticación y autorización

In CassandraPor defecto, las opciones de autenticación y autorización están deshabilitadas. Debes configurar el archivo cassandra.yaml para habilitarlas.

Abra el archivo cassandra.yaml y descomente las líneas que se refieren a la autenticación y autorización internas, como se muestra a continuación.

Líneas de autenticación y autorización de cassandra.yaml sin comentar

  • En cassandra.yaml, por defecto, el valor del autenticador es 'AllowAllAuthenticator'. Cambie este valor de 'AllowAllAuthenticator' a 'com.datastax.bdp.cassandra.auth.PasswordAuthenticator'.
  • De manera similar, en cassandra.yaml, por defecto, el valor del autorizador será 'AllowAllAuthorizer'. Cambie este valor del autorizador de 'AllowAllAuthorizer' a 'com.datastax.bdp.cassandra.auth.CassandraAutorizador'.

Esos dos nombres de clase son los valores de DataStax Enterprise. En código abierto Apache Cassandra Los mismos ajustes toman PasswordAuthenticator y CassandraAuthorizery las credenciales luego residen en el system_auth espacio de claves, cuyo factor de replicación debe elevarse por encima de uno.

Iniciar sesión

Ahora la autenticación está habilitada, si intenta acceder a cualquier espacio de claves, Cassandra devolverá un error.

Por defecto, Cassandra Proporciona la cuenta principal con el nombre de usuario 'cassandra' y la contraseña 'cassandra'. Al iniciar sesión en la cuenta 'cassandra', puedes hacer lo que quieras.

Veamos la siguiente captura de pantalla para esto, donde no le permitirá iniciar sesión si no está utilizando la configuración predeterminada. Cassandra "nombre de usuario y contraseña".

Se rechaza el inicio de sesión en cqlsh cuando no se utilizan las credenciales predeterminadas.

Ahora, en la segunda captura de pantalla, puede ver después de usar el Cassandra credencial de inicio de sesión predeterminada, podrá iniciar sesión.

Inicio de sesión exitoso mediante cqlsh con las credenciales predeterminadas de Cassandra.

También puede crear otro usuario con esta cuenta. Se recomienda cambiar la contraseña predeterminada. Aquí hay un ejemplo de cómo iniciar sesión como el usuario. Cassandra usuario y cambiando la contraseña predeterminada.

alter user cassandra with password 'newpassword';

Crear nuevo usuario

Se pueden crear nuevas cuentas con la cuenta 'cassandra'.

Para crear un nuevo usuario, se especifican el nombre de usuario y la contraseña, así como si el usuario es un superusuario o no. Solo un superusuario puede crear nuevos usuarios.

create user robin with password 'manager' superuser;
create user robin with password 'newhire';

Puede obtener una lista de todos los usuarios mediante la siguiente sintaxis.

list users;

El resultado muestra todas las cuentas junto con su indicador de superusuario.

Salida del comando list users que muestra las cuentas y los indicadores de superusuario.

Los usuarios pueden eliminarse mediante la siguiente sintaxis.

drop user laura;

ARTÍCULOS RELACIONADOS

Autorización

La autorización consiste en asignar permisos a los usuarios y decidir qué acciones puede realizar un usuario en particular.

Aquí está la sintaxis genérica para asignar permisos a los usuarios.

GRANT permission ON resource TO user

Existen los siguientes tipos de permisos que se pueden otorgar al usuario.

  1. TODO
  2. ALTER
  3. AUTORIZAR
  4. CREAR
  5. DROP
  6. MODIFICAR
  7. SELECT

A continuación se muestran ejemplos de asignación de permisos al usuario.

Create user laura with password 'newhire'; 
grant all on dev.emp to laura;
revoke all on dev.emp to laura;
grant select on dev.emp to laura;

Se crea un nuevo usuario 'laura' con la contraseña 'newhire'.

Aquí se muestra un ejemplo donde la usuaria 'laura' intenta acceder a la tabla emp_bonus. Laura solo tiene permiso para acceder a dev.emp y no tiene permiso para acceder a la tabla dev.emp_bonus, por lo que se devolvió un error.

Se produjo un error cuando Laura consultó la tabla emp_bonus sin permiso.

select* form emp_bonus;

Puedes obtener una lista de todos los permisos asignados al usuario. Aquí tienes un ejemplo de cómo obtener información sobre permisos.

Salida de listar todos los permisos de Laura

list all permissions of laura;

También puedes listar todos los permisos de un recurso. Aquí tienes un ejemplo de cómo obtener permisos de una tabla.

Salida de listar todos los permisos en dev.emp

list all permissions on dev.emp;

Configurar el cortafuegos

Si el firewall está en ejecución, se deben abrir los siguientes puertos para la comunicación entre nodos, incluidos algunos Cassandra puertos. Si Cassandra los puertos no se abrirán, Cassandra Los nodos actuarán como servidores de bases de datos independientes en lugar de unirse al clúster de bases de datos.

Cassandra Puertos de cliente

Número de puerto Mareas Ideales para Lecciones
9042 Cassandra Puerto del cliente
9160 Cassandra Ahorro del puerto del cliente

Cassandra Puertos entre nodos

Número de puerto Mareas Ideales para Lecciones
7000 Cassandra comunicación del grupo de entrenudos
7001 Cassandra Comunicación de clúster de entrenodos SSL
7199 Cassandra Puerto de monitoreo JMX

Puertos públicos

Número de puerto Mareas Ideales para Lecciones
22 puerto SSH
8888 Sitio web del Centro de operaciones. Solicitud http del navegador.

Cassandra Puertos del centro de operaciones

Número de puerto Mareas Ideales para Lecciones
61620 Puerto de monitoreo de OpsCenter.
61621 Puerto del agente de Opscenter

Los controladores actuales solo utilizan el puerto 9042; el puerto 9160 sirve para la interfaz Thrift heredada y puede permanecer cerrado en los nuevos clústeres.

Habilitación de la autenticación JMX

Con la configuración predeterminada de CassandraJMX solo se puede acceder desde el localhost. Si desea acceder a JMX de forma remota, cambie la configuración LOCAL_JMX en cassandra-env.sh y habilite la autenticación o SSL.

Después de habilitar la autenticación JMX, asegúrese Centro de operaciones y nodetool están configurados para usar autenticación.

Procedimiento

A continuación se indican los pasos para habilitar la autenticación JMX.

  1. En el archivo cassandra-env.sh, agregue o actualice las siguientes líneas. 
    JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

    Además, cambie la configuración LOCAL_JMX en cassandra-env.sh.

    LOCAL_JMX=no
  2. Copie el archivo jmxremote.password.template de /jdk_install_location/lib/management/ a /etc/cassandra/ y cámbiele el nombre a jmxremote.password. 
    cp /jdk_install_dir/lib/management/jmxremote.password.template /etc/cassandra/jmxremote.password
  3. Cambie la propiedad de jmxremote.password al usuario que ejecuta Cassandra con y cambiar el permiso a solo lectura. 
    chown cassandra:cassandra /etc/cassandra/jmxremote.password 
chmod 400 /etc/cassandra/jmxremote.password
  4. Edite jmxremote.password y agregue el usuario y la contraseña para las utilidades compatibles con JMX: 
    monitorRole QED 
controlRole R&D 
cassandra cassandrapassword
  5. Agregar el formulario Cassandra usuario con permiso de lectura y escritura en /jdk_install_location/lib/management/jmxremote.access 
    monitorRole readonly
cassandra readwrite
controlRole readwrite \
create javax.management.monitor.,javax.management.timer. \ 
unregister
  6. Reanudación Cassandra.
  7. Ejecute nodetool con el Cassandra usuario y contraseña. 
    $ nodetool status -u cassandra -pw cassandra

Preguntas Frecuentes

Ambas residen en el espacio de claves system_auth, en las tablas roles y role_permissions. Dado que una réplica perdida de system_auth puede bloquear el acceso a todos los usuarios, aumente su factor de replicación antes de habilitar la autenticación en producción.

Los roles de CQL reemplazaron la sintaxis de usuario anterior. Un rol contiene permisos y puede otorgarse a otros roles, por lo que CREATE ROLE reemplaza a CREATE USER en las versiones actuales, que mantienen los comandos de usuario como alias.

No. La autenticación solo verifica la identidad; las contraseñas siguen transmitiéndose en texto plano a menos que se habilite la opción client_encryption_options. Active TLS por separado para el tráfico de cliente a nodo y de nodo a nodo.

Crea un superusuario dedicado y luego cambia la contraseña integrada de cassandra o elimina la cuenta. Dejar activo el par cassandra/cassandra documentado es la opción más común. Cassandra mala configuración.

Los permisos se almacenan en caché. Un cambio solo surte efecto después de que expire el período de validez de los permisos, así que reduzca ese valor en cassandra.yaml o reinicie el nodo al probar una concesión o revocación de permisos.

El acceso JMX sin autenticación en el puerto 7199 permite el control total del nodo, incluida su desactivación. Cassandra Por lo tanto, se vincula localmente y el acceso remoto solo debe abrirse con un archivo de contraseña o SSL habilitado.

Los modelos de aprendizaje automático analizan las estructuras de consulta habituales, los tiempos de inicio de sesión y las direcciones de origen por rol, y luego detectan desviaciones, como que una cuenta de aplicación acceda a un espacio de claves no relacionado. Esto pone de manifiesto el uso indebido de credenciales que las reglas estáticas no contemplan.

Copilot redacta rápidamente las declaraciones CREATE ROLE y GRANT a partir de un comentario, pero tiende a sugerir permisos amplios. RevRevisa cada subvención generada contra el privilegio menor antes de ejecutarla en vivo. grupo.

Resumir este post con: