Establecer atributos de ACL para el cuidador del zoológico
Establecer atributos de ACL para zookeeper
Tomemos zkCli como ejemplo para ilustrar la configuración de ACL de zookeeper.
Cuando se utiliza zkCli, el formato ACL consta de tres secciones:
Nota: Zookeeper controla los permisos a nivel de znode y no tiene herencia, es decir, los nodos secundarios no heredan los permisos de sus nodos principales. Este diseño todavía tiene fallas en el uso, porque en muchos escenarios, aún organizaremos recursos relacionados y los colocaremos bajo la misma ruta, por lo que será necesaria una autorización unificada de una ruta.
Este es el modo predeterminado, lo que significa que no hay autenticación. Cuando se crea un nuevo nodo (znode) sin establecer ningún permiso, es este valor. Por ejemplo:
Puede ver que la ACL de /noacl pertenece al esquema mundial, porque no establece el. Atributo ACL. De esta manera cualquiera puede acceder a este nodo.
Si desea configurar este atributo manualmente, entonces el campo id solo permite un valor en este momento, es decir, cualquiera, con el siguiente formato:
Esta autorización no está dirigida a cualquier ID característico, pero todos los usuarios que se han agregado para la autenticación, en otras palabras, están autorizados para todos los usuarios que han pasado la autenticación.
El uso es el siguiente:
Nota:
Ejemplo:
En este ejemplo, primero agregamos tres usuarios autenticados tom1 y tom2. , tom3 y luego configure la ACL a través de setAcl. La identificación es tom2 especificada en el comando. Según la declaración anterior, este valor de identificación se ignora. Vemos que el resultado final de la consulta getAcl incluye los tres usuarios autenticados agregados anteriormente.
Explicación adicional: El comando zkCli addauth digest user:pwd se usa para agregar el usuario autenticado en el contexto actual:
De hecho, no entiendo muy bien esta función. ¿Es posible en una sesión (se pueden agregar varios usuarios autenticados a la sesión) y cuál cuenta durante la verificación? Si diferentes usuarios tienen diferentes autorizaciones, ¿causará conflictos de autorización? ¿Por quién?
Algunos puntos resumidos:
Por lo tanto, es más probable que este método de autorización se utilice en un entorno de prueba y desarrollo que en un entorno de producción.
Este es el método de verificación de nombre de usuario y contraseña más común, que se utiliza con mayor frecuencia en sistemas comerciales generales.
El formato es el siguiente:
En comparación con la autenticación de esquema, existen dos diferencias:
La contraseña se puede generar mediante el siguiente método de shell: p>
Por ejemplo:
O puede usar el archivo de la biblioteca zookeeper para generar:
La raíz de salida:jalRr+knv/6L2uXdenC93dEDNuE= es la cadena de identificación pasada a setAcl .
Tenga en cuenta que la identificación requiere texto cifrado solo cuando se configura la ACL del resumen a través de zkCli.sh, y los datos de autenticación correspondientes son texto sin formato cuando se configura la ACL del resumen a través del cliente zookeeper. Este es un problema de implementación de codificación.
En comparación con la autenticación, el resumen tiene las siguientes características:
Es la dirección del cliente, el nombre del host o la dirección IP.
El nombre de host puede ser un nombre de host único o un nombre de dominio. La IP puede ser una única dirección IP o un rango de direcciones IP, como ip:192.168.1.0/16.
No entraré en detalles sobre esto, es relativamente simple y no ha sido verificado.
Configurar un superusuario La configuración de este superusuario debe establecerse dentro de zookeeper antes de que se inicie zookeeper. En este esquema, el superusuario tiene superprivilegios y puede hacer cualquier cosa (cdrwa), no se requiere autorización.
5.1 Establezca la variable de entorno de zookeeper SERVER_JVMFLAGS:
5.2 Reinicie zookeeper
Cree el nodo /test y establezca acl en el usuario jerry1.
5.3 Agregar usuario de autenticación tom
5.4 Acceso al nodo/prueba
Esto falla porque el usuario tom no tiene permiso.
5.3 Agregar usuario root autenticado
5.4 Acceder al nodo /test nuevamente
Éxito, aunque root no está en la lista acl de /test (está jerry1) , pero también se puede acceder a él porque root está configurado como superusuario en el clúster del cuidador del zoológico.