En Couchbase 4.5, los datos estaban protegidos cubo por cubo. Cada bucket tenía una contraseña, y para acceder a un bucket a través de una consulta N1QL, el usuario tenía que incluir la contraseña del bucket en la consulta. Los buckets sin contraseña eran posibles, pero no se recomendaban para uso en producción.
Este esquema ofrecía una protección básica, pero era de grano muy grueso: un usuario podía hacer todo con un cubo, o nada en absoluto. Además, para acceder a varios buckets era necesario introducir una contraseña para cada uno de ellos, lo que resultaba incómodo, sobre todo si las contraseñas cambiaban.
Para permitir a nuestros usuarios evitar estos problemas, hemos introducido el control de acceso basado en roles (RBAC) en Couchbase Server 5.0. El acceso a los datos se controla ahora a través de roles detallados en los buckets, y a cada usuario se le pueden asignar roles que se ajusten a lo que realmente debería estar haciendo en la base de datos.
En este artículo te guiaré a través de las principales funcionalidades ofrecidas por RBAC en Couchbase Server 5.0. Los ejercicios prácticos te permitirán probar las nuevas características por ti mismo.
Configurar
Para los ejercicios prácticos, necesitarás instalar Couchbase Server 5.0, Enterprise Edition. Durante la instalación, configúralo para tener un administrador llamado "Administrator" con contraseña "password". Esto no es una práctica recomendada en un entorno de producción, por supuesto.
Accede a la consola de administración (en http://localhost:8091) y ve a la pantalla Buckets. Allí crea dos buckets, "testbucket1" y "testbucket2", cada uno con una cuota de memoria de 100 MB para evitar quedarte sin memoria.
A continuación, vaya a la pantalla Consulta y cree índices primarios en los dos buckets que acaba de crear. Los índices primarios le permiten ejecutar consultas en los buckets.
|
1 2 |
CREAR PRIMARIO ÍNDICE EN cubo de pruebas1 CREAR PRIMARIO ÍNDICE EN cubo de pruebas2 |
Puede ir a la pantalla Índices para comprobar que los índices se han creado realmente. Ambos se llamarán "#primary".
Funciones principales
Hay cuatro roles principales que controlan quién puede ejecutar qué consultas N1QL. Los roles query_select, query_insert, query_update y query_delete permiten ejecutar consultas N1QL del tipo correspondiente. También hay tres roles más especializados (query_manage_index, query_system_catalog, y query_external_access) que serán cubiertos en la siguiente sección, Roles Adicionales Importantes.
Pero hay más. Estos roles están parametrizados por el cubo al que se aplican. Un usuario no puede tener simplemente el rol query_select; necesitamos saber en qué cubo está el rol, como query_select[testbucket1], que permite al usuario ejecutar una consulta SELECT contra testbucket1. También es posible tener este rol en todos los cubos, indicado por query_select[*].
Para probarlo tú mismo, entra en la consola de Couchbase y en la pantalla de Seguridad crea un nuevo usuario user1 con contraseña "password" y rol query_select[testbucket1].
La función se encuentra en "Funciones de consulta" en el menú de creación de usuarios.
A continuación, haga lo mismo para "usuario2", pero dele a ese usuario query_select[testbucket2].
Ahora vamos a intentar ejecutar una consulta contra estos buckets usando los roles. Usaré la herramienta de shell CBQ que viene con Couchbase.
|
1 |
cbq -e http://localhost:8093/ -s "select * from testbucket1" |
Que nos dan esta respuesta:
|
1 2 3 4 5 6 7 8 9 |
{ "requestID": "d838da35-24a3-415e-b9e1-69ac02a9820b", "firma": {"*":"*"}, "resultados": [ ], "errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar consultas SELECT en el bucket testbucket1. Añade el rol query_select en testbucket1 para permitir la ejecución de la consulta".}], "status": "parado", "métricas": {"tiempo transcurrido": "4.214692ms","executionTime": "4.190101ms","resultCount": 0,"resultSize": 0,"errorCount": 1} } |
Fíjate que el error nos dice muy claramente qué rol nos falta. Intentémoslo de nuevo con el usuario1, que tiene el rol correcto:
|
1 |
cbq -e http://localhost:8093/ -s "select * from testbucket1" -u usuario1 -p contraseña |
Funcionó:
|
1 2 3 4 5 6 7 8 |
{ "requestID": "caeba7de-d9eb-4e2f-8f67-d6e795fb1dbd", "firma": {"*":"*"}, "resultados": [ ], "status": "éxito", "métricas": {"tiempo transcurrido": "11.501861ms","executionTime": "11.471201ms","resultCount": 0,"resultSize": 0} } |
Intente usted mismo la consulta con el usuario2, que tiene el rol correcto pero en el cubo equivocado. La solicitud fallará.
Intentemos ahora una consulta más compleja que afecte a dos buckets. Comience ejecutando esta consulta:
|
1 2 3 |
cbq -e http://localhost:8093/ -s "INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECT * FROM fuente testbucket1 WHERE fuente.nueva = true" |
El sistema nos dice que necesita el rol query_insert[testbucket2]:
|
1 2 |
"errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar consultas INSERT en el bucket testbucket2. Añade el rol query_insert en testbucket2 para permitir la ejecución de la consulta."}], |
Crea un nuevo usuario "user3" con el rol requerido, e inténtalo de nuevo:
|
1 2 |
"errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar consultas SELECT en el bucket testbucket1. Añade el rol query_select en testbucket1 para permitir la ejecución de la consulta."}], |
Seguimos recibiendo un error, pero es un error diferente al de antes. La consulta que estamos intentando ejecutar tiene dos partes; selecciona de testbucket1 e inserta en testbucket2. Hemos proporcionado suficientes credenciales para la inserción pero no para la selección. Ve a la consola, añade query_select[testbucket2] a user3 e inténtalo de nuevo. Esta vez la consulta funciona.
|
1 2 3 4 5 6 7 8 |
{ "requestID": "3c313c29-8b67-4e63-92b0-763586345f59", "firma": null, "resultados": [ ], "status": "éxito", "métricas": {"tiempo transcurrido": "11.451689ms","executionTime": "11.415157ms","resultCount": 0,"resultSize": 0} } |
Intentemos una cosa más. Añade una cláusula RETURNING a la consulta e intenta ejecutarla:
|
1 2 3 |
cbq -e http://localhost:8093/ -s "INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECCIONAR * DESDE cubo de pruebas1 fuente DONDE fuente.nuevo = verdadero DEVOLVER meta().id id" -u usuario3 -p contraseña |
Esto falla:
|
1 2 |
"errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar consultas SELECT en el bucket testbucket2. Añade el rol query_select en testbucket2 para permitir la ejecución de la consulta."}], |
Lo que ocurre aquí es que la cláusula RETURNING está siendo tratada como un SELECT sobre el bucket en el que hemos insertado (testbucket2), ocurriendo justo después de la inserción. El usuario no tiene el rol query_select[testbucket2] y por lo tanto está siendo rechazado.
Añade el rol query_select[testbucket2] a user3 y vuelve a ejecutar la consulta. Ahora funcionará.
Funciones adicionales importantes
Hay tres funciones más que debes conocer cuando trabajes con N1QL.
query_manage_index
En primer lugar, vamos a intentar crear un índice:
|
1 |
cbq -e http://localhost:8093/ -s "CREATE INDEX test_idx ON testbucket1(price)" |
Eso nos da un error:
|
1 2 3 |
"errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar operaciones de índice. Añade el rol query_manage_index en testbucket1 para permitir la ejecución de la consulta."}], "status": "parado", |
El rol Query Manage Index en un bucket es necesario para crear, borrar o construir índices en ese bucket.
Crea un nuevo usuario "user4" con el rol query_manage_index[testbucket1]. Prueba el creación de índices de nuevo. Ahora la consulta funcionará.
|
1 2 |
cbq -e http://localhost:8093/ -s "CREATE INDEX test_idx ON testbucket1(price)" -u usuario4 -p contraseña |
catálogo_sistema_consulta
En versiones anteriores de Couchbase, las tablas del sistema eran totalmente accesibles para cualquiera. Ahora están más restringidas de varias maneras que se describirán más adelante en este documento, pero hay un rol útil, query_system_catalog, que permite el acceso a las tablas del sistema. Esto es particularmente útil para el personal que necesita ser capaz de depurar problemas con las consultas o el sistema, pero no se les debe dar privilegios de administrador completo.
Si consultamos system:keyspaces como administrador, veremos los dos buckets que hemos creado en el sistema:
|
1 |
cbq -e http://localhost:8093/ -s "SELECT * FROM system:keyspaces" -u Administrador -p contraseña |
|
1 2 3 4 5 6 7 8 9 10 |
{ "requestID": "46ee066e-25f6-4bef-a70a-553f4c224c39", "firma": {"*":"*"}, "resultados": [ {"keypaces":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket2","nombre":"testbucket2","namespace_id":"por defecto"}}, {"keypaces":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket1","nombre":"testbucket1","namespace_id":"por defecto"}} ], "status": "éxito", "métricas": {"tiempo transcurrido": "16.562026ms","executionTime": "16.52656ms","resultCount": 2,"resultSize": 238} } |
Pero si ejecutamos la misma consulta sin credenciales, los resultados se filtran:
|
1 2 3 4 5 6 7 8 9 |
{ "requestID": "932e6b73-3058-4877-8da1-1715b16e53f5", "firma": {"*":"*"}, "resultados": [ ], "advertencias": [{"código":11011,"msg":"Uno o más documentos fueron excluidos del cubo system:keyspaces debido a permisos de usuario insuficientes".}], "status": "éxito", "métricas": {"tiempo transcurrido": "20.563024ms","executionTime": "20.532213ms","resultCount": 0,"resultSize": 0,"warningCount": 1} } |
Cree un nuevo usuario "user5" con el rol query_system_catalog, y vuelva a ejecutar la consulta. Verás los mismos resultados que cuando ejecutamos la consulta como Administrador.
Consulta_acceso_externo
La nueva función CURL() permite consultar servicios REST desde N1QL. Para usar la función, necesitamos hacer alguna configuración, y ejecutar la consulta usando el nuevo rol query_external_access.
Probemos primero la consulta:
|
1 2 3 |
cbq -e http://localhost:8093/consulta/servicio -s 'SELECT CURL("https://maps.googleapis.com/maps/api/geocode/json", {"data": "dirección=Media+Luna+Bahía", "get":true}) GEO |
La consulta se rechaza porque no se facilitan los permisos adecuados:
|
1 2 |
"errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar consultas utilizando la función CURL(). Añade el rol query_external_access para permitir la ejecución de la consulta".}] |
Crea un usuario "user6" con el rol query_external_access y vuelve a ejecutar la consulta utilizando ese usuario. Esta vez la consulta se niega a ejecutarse porque no hemos habilitado CURL(); por motivos de seguridad está deshabilitado por defecto.
Cree un archivo "curl_whitelist.json" con el siguiente contenido:
|
1 |
{"all_access":verdadero} |
Colóquelo en el directorio couchbase. En un Mac, la ubicación exacta es "/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/var/lib/couchbase/n1qlcerts/curl_whitelist.json". En otros sistemas, la ubicación es ligeramente diferente. Pruebe de nuevo la consulta, que debería ejecutarse correctamente, descargando los datos de la siguiente manera:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
"dirección_componentes" : [ { "nombre_largo" : "Half Moon Bay", "nombre_corto" : "Half Moon Bay", "tipos" : [ "localidad", "político" ] }, { "nombre_largo" : "Condado de San Mateo", "nombre_corto" : "Condado de San Mateo", "tipos" : [ "zona_administrativa_nivel_2", "político" ] }, { "nombre_largo" : "California", "nombre_corto" : "CA", "tipos" : [ "zona_administrativa_nivel_1", "político" ] }, { "nombre_largo" : "Estados Unidos", "nombre_corto" : "US", "tipos" : [ "país", "político" ] } |
La lista completa de funciones de N1QL es la siguiente:
| Papel | Permisos | Sintaxis GRANT |
| Seleccionar consulta | Declaraciones SELECT | GRANT select ON testbucket TO myuser |
| Insertar consulta | Declaraciones INSERT | GRANT insert ON testbucket TO myuser |
| Actualización de consultas | Declaraciones UPDATE | GRANT update ON testbucket TO myuser |
| Consulta Borrar | Declaraciones DELETE | GRANT delete ON testbucket to myuser |
| Consultar el catálogo del sistema | Acceso a los espacios de claves del sistema | GRANT query_system_catalog TO myuser |
| Consulta Gestionar índice | Operaciones de indexación | GRANT query_manage_index ON testbucket TO myuser |
| Consulta de acceso externo | Función CURL() | GRANT query_external_access TO myuser |
explicar y preparar
Por supuesto, podemos hacer otras cosas con las consultas además de ejecutarlas. Podemos usar EXPLAIN para entender cómo el motor de consultas calcula una consulta. Y podemos utilizar PREPARE para configurar una consulta para su ejecución repetida.
En Couchbase 5.0, los permisos para EXPLAIN y PREPARE son simples. Son los mismos que los permisos requeridos para la sentencia subyacente. Eso es todo.
Para comprobarlo, intentemos EXPLICAR una sentencia SELECT sencilla, la misma que utilizamos en la sección anterior "Funciones principales":
|
1 |
cbq -e http://localhost:8093/ -s "explain select * from testbucket1" |
En respuesta recibimos un mensaje de error que nos pide un rol específico:
|
1 2 |
"errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar consultas SELECT en el bucket testbucket1. Añade el rol query_select en testbucket1 para permitir la ejecución de la consulta."}], |
Proporcionemos un usuario con ese rol:
|
1 |
cbq -e http://localhost:8093/ -s "explain select * from testbucket1" -u usuario1 -p contraseña |
Éxito, tal y como vimos para la propia declaración en "Funciones principales".
Ahora vamos a intentar PREPARAR la segunda declaración de "Roles primarios":
|
1 2 3 |
cbq -e http://localhost:8093/ -s "PREPARE INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECT * FROM fuente testbucket1 WHERE fuente.nueva = true" |
Recibimos el mismo mensaje de error que recibimos originalmente para la propia sentencia:
|
1 2 |
"errores": [{"código":13014,"msg":"El usuario no tiene credenciales para ejecutar consultas INSERT en el cubo testbucket2. Añade el rol query_insert en testbucket2 para permitir la ejecución de la consulta."}], |
Y si añadimos un usuario con credenciales para el SELECT y el INSERT, el PREPARE tiene éxito:
|
1 2 3 4 5 |
cbq -e http://localhost:8093/ -s "PREPARE INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECT * FROM fuente testbucket1 WHERE fuente.nueva = true" -u usuario3 -p contraseña |
CONCEDER y REVOCAR
En 5.0, N1QL incluye sentencias para dar roles a los usuarios (GRANT) y para quitarlos (REVOKE). Estas sentencias requieren permiso de Administrador para ejecutarse.
Antes de probar estas declaraciones, revisemos qué usuarios están configurados y qué roles tienen. Esto es lo que deberías ver en la pantalla de Seguridad de la consola de Couchbase.
Podemos otorgar un nuevo rol cluster_admin al usuario1 de la siguiente manera:
|
1 |
cbq -e http://localhost:8093/ -s "grant cluster_admin to user1" -u Administrador -p contraseña |
Esto tendrá éxito, y poco después la consola de Couchbase se actualizará para reflejar la nueva asignación de roles.
También podemos asignar roles parametrizados, así:
|
1 2 3 4 |
cbq -e http://localhost:8093/ -s "grant query_insert on testbucket2 to user2" -u Administrador -p contraseña |
Podemos deshacer la concesión inicial mediante un REVOKE:
|
1 |
cbq -e http://localhost:8093/ -s "revocar cluster_admin del usuario1" -u Administrador -p contraseña |
Todos estos parámetros pueden recibir listas de argumentos:
|
1 2 3 4 |
cbq -e http://localhost:8093/ -s "grant query_insert, query_delete on testbucket1, testbucket2 to user5, user6" -u Administrador -p contraseña |
Por último, el prefijo query_ es opcional para query_insert, query_update, query_delete y query_select, lo que hace que parte de la sintaxis resulte más familiar:
|
1 2 |
cbq -e http://localhost:8093/ -s "grant insert,delete on testbucket1 to user4" -u Administrador -p contraseña |
Comparación con Oracle
El control de acceso basado en roles en Couchbase 5.0 ha sido diseñado para ser familiar a los profesionales que han utilizado el control de acceso en otros sistemas de bases de datos actuales. A estas alturas, ya deberías haber reconocido conceptos familiares como que los permisos de inserción/selección/actualización/eliminación son aplicables a los buckets, que son algo así como tablas. También debería resultarte familiar la noción de usuarios administradores con amplios permisos. El control de acceso basado en roles en Couchbase 5.0 ha sido diseñado para ser familiar a los profesionales que han utilizado el control de acceso en otros sistemas de bases de datos actuales. A estas alturas, ya deberías haber reconocido conceptos familiares como que los permisos de inserción/selección/actualización/eliminación son aplicables a los buckets, que son algo así como tablas. También debería resultarle familiar la noción de usuarios administradores con amplios permisos.
Por ejemplo, esta consulta GRANT funcionará tanto en Couchbase como en Oracle:
|
1 |
SUBVENCIÓN seleccione, insertar EN por defecto A jlarson, pedwards |
Una diferencia conceptual entre Couchbase y otros sistemas como Oracle es que nosotros tenemos un modelo binario de privilegios: usuarios y roles. Ellos típicamente tienen un modelo trinario, con usuarios, roles y privilegios. En consecuencia, dar permisos a los usuarios en Oracle es conceder privilegios sobre objetos a los usuarios. En Couchbase, se trata de otorgar roles parametrizados a los usuarios.
Los roles son estáticos en 5.0. No existen sentencias equivalentes a CREATE/DROP/ALTER ROLE.
Los permisos de Couchbase son sobre el sistema en su conjunto o sobre los buckets. No tenemos noción de permisos sobre tablas, columnas o colecciones.
En Couchbase GRANT y REVOKE solo son posibles por usuarios Admin. No existe tal cosa como una OPCIÓN ADMIN o una OPCIÓN GRANT. Cambiar permisos requiere que seas un Administrador.
Finalmente, no tenemos equivalente de SET ROLE. SET ROLE es un comando a nivel de sesión, lo que no tiene sentido en Couchbase porque no tenemos sesiones, sólo peticiones RESTful individuales.
Nuevos espacios clave del sistema
Couchbase 5.0 introduce tres nuevos espacios de claves del sistema relacionados con los usuarios. El primero de ellos es system:user_info. Este keypace lista los usuarios configurados en el sistema, incluyendo sus roles. Intentemos una consulta:
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:user_info" -u Administrador -p contraseña |
Eso nos da siete entradas como esta, una por cada usuario que hayamos configurado, más el Administrador configurado:
|
1 2 3 |
{"user_info":{"dominio":"local","id":"user4","nombre":"Usuario4","roles":[{"nombre_cubo":"testbucket1","rol":"query_manage_index"},{"nombre_cubo":"testbucket1","rol":"insertar"},{"nombre_cubo":"testbucket1","rol":"borrar"}]}}, {"user_info":{"dominio":"local","id":"usuario2","nombre":"Usuario 2","roles":[{"nombre_cubo":"testbucket2","rol":"seleccionar"},{"nombre_cubo":"testbucket2","rol":"insertar"}]}}, {"user_info":{"dominio":"local","id":"usuario5","nombre":"Usuario5","roles":[{"nombre_cubo":"testbucket2","rol":"insertar"},{"nombre_cubo":"testbucket1","rol":"insertar"},{"nombre_cubo":"testbucket2","rol":"borrar"},{"nombre_cubo":"testbucket1","rol":"borrar"},{"rol":"query_system_catalog"}]}}, |
El espacio clave system:applicable_roles es similar, pero divide cada rol de usuario en una entrada independiente, lo que produce una visión más relacional de los datos:
|
1 2 3 4 |
cbq -e http://localhost:8093/ -s "select * from system:applicable_roles where grantee = 'user3'" -u Administrador -p contraseña |
|
1 2 3 4 5 |
"resultados": [ {"applicable_roles":{"nombre_cubo":"testbucket2","becario":"usuario3","rol":"seleccionar"}}, {"applicable_roles":{"nombre_cubo":"testbucket1","becario":"usuario3","rol":"seleccionar"}}, {"applicable_roles":{"nombre_cubo":"testbucket2","becario":"usuario3","rol":"insertar"}} ], |
Por último, el espacio de claves system:my_user_info muestra la parte de system:my_user_info correspondiente al usuario cuyas credenciales se introducen con la consulta.
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:my_user_info" -u usuario3 -p contraseña |
|
1 2 3 4 |
"resultados": [ {"mi_info_usuario":{"dominio":"local","id":"usuario3","nombre":"Usuario 3", "roles":[{"nombre_cubo":"testbucket2","rol":"seleccionar"},{"nombre_cubo":"testbucket1","rol":"seleccionar"},{"nombre_cubo":"testbucket2","rol":"insertar"}]}} ], |
Acceso a los espacios de claves del sistema
Siguiendo una filosofía general de funcionamiento seguro, los espacios de claves del sistema (buckets) están protegidos en la versión 5.0. El grado de restricción varía en función de los datos presentes en cada espacio de claves.
Tres espacios de claves no tienen nada que pueda ser valioso para un atacante:
- sistema:almacenes de datos
- sistema:espacios de nombres
- sistema:dual
Por consiguiente, estos espacios de claves no están protegidos. No se necesitan credenciales para acceder a ellos.
|
1 |
cbq -e http://localhost:8093/query/service -s "select * from system:datastores" |
|
1 2 3 |
"resultados": [ {"almacenes de datos":{"id":"http://127.0.0.1:8091","url":"http://127.0.0.1:8091"}} ], |
En el otro extremo de la seguridad están system:user_info y system:applicable_roles, que contienen la lista de usuarios y sus roles. Sólo pueden acceder a ellas los usuarios Admin y Read Only Admin. La tabla system:my_user_info es similar, pero sólo muestra la información relevante para el usuario cuyas credenciales se presentan con la consulta. Ya hemos explorado estas tablas anteriormente.
Los siguientes cuatro espacios de claves del sistema contienen una variedad de información de tiempo de ejecución y configuración.
- Sistema:preparados
- Sistema:solicitudes_realizadas
- Sistema:solicitudes_activas
- Sistema:nodos
Como la información que contienen no es tan sensible como la de los usuarios, son más accesibles. La mayoría de los administradores, incluso los de menor importancia, pueden acceder a ellos: Admin, Read Only Admin, Cluster Admin, Query System Catalog, Replication Admin, Bucket Admin(cualquier bucket), o Views Admin(cualquier bucket).
Intentemos ver system:prepareds como user5, el usuario que creamos con permiso Query System Catalog, arriba.
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:prepareds" -u usuario5 -p contraseña |
Esto nos muestra una declaración preparada que creamos anteriormente.
El espacio clave system:keyspaces muestra la lista de buckets configurados en el sistema. Esta información es algo sensible, ya que proporciona a un atacante información sobre para qué se utiliza un sistema. En consecuencia, los usuarios con roles de alto nivel (Admin, Read Only Admin, Cluster Admin) ven todo lo que hay en este espacio de claves. Los usuarios con el rol Catálogo del Sistema de Consulta también ven todo, ya que este rol está destinado a depurar problemas de consulta. Para otros usuarios, la vista está filtrada; el usuario sólo ve aquellos espacios clave para los que tiene permiso query_select.
Por ejemplo, una consulta en system:keyspaces sin credenciales tendrá éxito pero no mostrará ninguna entrada:
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:keyspaces" |
|
1 2 3 |
"resultados": [ ], |
Añada las credenciales para el usuario5, que tiene el rol Consulta del Catálogo del Sistema, y se mostrarán todas las entradas:
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:keyspaces" -u usuario5 -p contraseña |
|
1 2 3 4 |
"resultados": [ {"keypaces":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket1","nombre":"testbucket1","namespace_id":"por defecto"}}, {"keypaces":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket2","nombre":"testbucket2","namespace_id":"por defecto"}} ], |
Utiliza las credenciales para el usuario1, que sólo tiene query_select[testbucket1], y verás sólo la entrada para testbucket1.
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:keyspaces" -u usuario1 -p contraseña |
|
1 2 3 |
"resultados": [ {"keypaces":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket1","nombre":"testbucket1","namespace_id":"por defecto"}} ], |
El espacio de claves system:indexes se gestiona de forma muy similar a system:keyspaces: los roles de alto nivel permiten el acceso completo, mientras que el rol query_select permite el acceso filtrado. La diferencia real es que el rol query_manage_index permite acceso filtrado, como query_select.
Protección de las API administrativas
El motor de consultas N1QL tiene APIs RESTful correspondientes a tres de los espacios clave del sistema: system:prepareds, system:completed_requests, y system:active_requests. Estos solían ser abiertos en Couchbase 4.6, pero ahora son seguros. Requieren las mismas credenciales que los espacios clave.
|
1 |
rizo http://localhost:8093/admin/prepareds |
|
1 2 3 4 |
{"llamante":"auth:268", "código":13014,"llave":"datastore.couchbase.insufficient_credentiasl", "mensaje":"El usuario no tiene credenciales para ejecutar consultas que accedan a las tablas del sistema. Añade el rol query_system_catalog para permitir la ejecución de la consulta".} |
Si lo intentamos de nuevo con el usuario5, que tiene el rol requerido, funciona.
|
1 |
rizo http://localhost:8093/admin/prepareds -u usuario5:contraseña |
Acceso a los cubos migrados sin contraseña
Al migrar de 4.6 a 5.0, es útil conservar los patrones de permisos existentes, para permitir que las aplicaciones heredadas sigan funcionando como antes. En este caso es un poco complicado, porque en 4.6 el acceso se controlaba mediante contraseñas en los propios buckets, mientras que en 5.0 el control de acceso se basa en usuarios con varios roles.
Para preservar los patrones de acceso heredados, durante el proceso de actualización creamos usuarios con nombres y contraseñas que coinciden con el bucket original. Esto permite que las aplicaciones existentes sigan haciendo lo que hacían, incluso en el caso de acceso sin contraseña alguna.
Ver esto en acción va a requerir algo de trabajo. Ponte cómodo.
Empieza instalando Couchbase 4.6. A continuación, crea dos buckets, "openbucket" sin contraseña y "closedbucket" con contraseña "password".
Vaya a la pestaña Consulta y añada índices primarios para ambos buckets a fin de permitir la ejecución de consultas N1QL.Vaya a la pestaña Consulta y añada índices primarios para ambos buckets a fin de permitir la ejecución de consultas N1QL.
|
1 2 |
crear principal índice en openbucket crear principal índice en closedbucket |
Compruebe que openbucket puede consultarse sin contraseña:
|
1 |
cbq -e http://localhost:8093/ -s "select * from openbucket" |
Pero la consulta a closedbucket sin contraseña falla:
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" |
Pero closedbucket se puede consultar con una contraseña:
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" -u closedbucket -p password |
Este es el patrón de acceso que queremos preservar cuando actualicemos a 5.0. Ahora apaga Couchbase, y actualiza a 5.0, preservando los datos subyacentes que acabamos de crear. Luego ve a la pantalla de Seguridad de la consola de Couchbase. Allí verás dos nuevos usuarios creados por el proceso de actualización.
El usuario "closedbucket" tiene el mismo nombre que el bucket "closedbucket" y la contraseña que se asignó al bucket en la versión 4.6. Nos permite preservar el acceso heredado a closedbucket. El usuario "openbucket" hace lo mismo, pero para openbucket.
Comprobemos que el patrón de acceso anterior sigue funcionando.
|
1 |
cbq -e http://localhost:8093/ -s "select * from openbucket" |
Openbucket sigue siendo accesible sin contraseña.
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" |
El acceso a Closedbucket falla sin contraseña.
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" -u closedbucket -p password |
Pero el acceso a closedbucket tiene éxito con una contraseña.
¡Hurra! Las cosas funcionan como antes. Ve a prepararte un capricho.
Resumen
- El control de acceso en Couchbase 4.6 usaba contraseñas para los buckets. En 5.0 se utilizan roles asignados a los usuarios.
- Los roles principales utilizados para controlar el acceso de un usuario a N1QL son query_select/query_insert/query_update/query_delete. Todos ellos están parametrizados por bucket.
- Otras funciones importantes más especializadas son query_manage_index, query_system_catalog y query_external_access.
- Explicar o preparar una consulta requiere las mismas funciones que ejecutarla.
Hay nuevas sentencias que permiten CONCEDER y REVOCAR roles. - El sistema de roles debería resultar familiar a los usuarios familiarizados con otras bases de datos importantes. La principal diferencia es que Couchbase no tiene noción de permisos fuera de los roles.
- Hay nuevos espacios clave del sistema para consultar los usuarios y las funciones que tienen asignadas.
Los espacios de claves del sistema se controlan por motivos de seguridad. El comportamiento varía de un espacio de claves a otro en función de la sensibilidad de los datos que contiene. - Los patrones de acceso existentes, incluso para los buckets sin contraseña, deberían seguir funcionando tras la migración de 4.6 a 5.0.
