CREATE ROW POLICY

Documentación de ROW POLICY

Crea una ROW POLICY, es decir, un filtro que se utiliza para determinar qué filas puede leer un usuario de una tabla.

Las ROW POLICY solo tienen sentido para usuarios con acceso de solo lectura. Si un usuario puede modificar una tabla o copiar particiones entre tablas, las restricciones de las ROW POLICY dejan de ser efectivas.

Sintaxis:

-- Multiple names on one table target
CREATE [ROW] POLICY [IF NOT EXISTS | OR REPLACE] policy_name [, ...]
    [ON CLUSTER cluster_name]
    ON { [db.]table | db.* }
    [IN access_storage_type]
    [[FOR SELECT] USING {condition | NONE}]
    [AS {PERMISSIVE | RESTRICTIVE}]
    [TO {role1 [, role2 ...] | ALL | ALL EXCEPT role1 [, role2 ...]}]

-- One name on multiple table targets
CREATE [ROW] POLICY [IF NOT EXISTS | OR REPLACE] policy_name
    [ON CLUSTER cluster_name]
    ON { [db.]table | db.* } [, ...]
    [IN access_storage_type]
    [[FOR SELECT] USING {condition | NONE}]
    [AS {PERMISSIVE | RESTRICTIVE}]
    [TO {role1 [, role2 ...] | ALL | ALL EXCEPT role1 [, role2 ...]}]

-- Mixed packing: each name paired with its own table target
CREATE [ROW] POLICY [IF NOT EXISTS | OR REPLACE]
    policy_name ON { [db.]table | db.* } [, policy_name ON { [db.]table | db.* } ...]
    [ON CLUSTER cluster_name]
    [IN access_storage_type]
    [[FOR SELECT] USING {condition | NONE}]
    [AS {PERMISSIVE | RESTRICTIVE}]
    [TO {role1 [, role2 ...] | ALL | ALL EXCEPT role1 [, role2 ...]}]

ParserRowPolicyNames acepta tres formas de empaquetado (no un producto cartesiano completo):

1. Varios nombres, un destino — pol1, pol2 ON table1 crea cada uno de los nombres indicados en esa única tabla (o db.*).
2. Un nombre, varios destinos — pol1 ON table1, table2 crea el mismo nombre corto en cada destino indicado.
3. Pares mixtos — p1 ON t1, p2 ON t2 crea cada nombre únicamente en el destino con el que está emparejado.

Una lista de varios nombres no puede combinarse con una lista ON de varias tablas en un mismo grupo: se rechaza p1, p2 ON t1, t2. Después de un grupo de varios nombres, tampoco se puede añadir otro grupo name ON target separado por comas en la misma sentencia.

El ON CLUSTER opcional se aplica a toda la sentencia (un nombre de clúster). ClickHouse no acepta un ON CLUSTER distinto para cada nombre de política empaquetado en una sola creación; ejecute sentencias CREATE ROW POLICY independientes cuando las ROW POLICY deban crearse en clústeres distintos.

CREATE ROW POLICY requiere el privilegio CREATE ROW POLICY en la tabla en la que se crea la política. OR REPLACE descarta una política existente con el mismo nombre, incluidos los roles a los que se aplica, por lo que también requiere el privilegio DROP ROW POLICY en esa tabla. El privilegio DROP ROW POLICY es necesario tanto si la política ya existe como si no, por lo que la sentencia no puede utilizarse para averiguar qué políticas existen.

​

Varios nombres y tablas

Válido:

-- Several policy names, one table
CREATE ROW POLICY pol1, pol2, pol3 ON table1
    FOR SELECT USING id = 1
    TO accountant;

-- One policy name, several tables
CREATE ROW POLICY IF NOT EXISTS pol1 ON table1, table2, table3
    FOR SELECT USING id = 1
    TO accountant;

-- Mixed packing: different name per table
CREATE ROW POLICY p4 ON db.table, p5 ON db2.table2
    USING a = b;

-- Same policy on several tables, on a cluster
CREATE ROW POLICY IF NOT EXISTS pol1 ON CLUSTER replicated_cluster ON table1, table2
    FOR SELECT USING id = 1
    TO accountant;

No válido:

-- Multi-name × multi-table in one ON-group (not a Cartesian product)
CREATE ROW POLICY p1, p2 ON t1, t2
    FOR SELECT USING id = 1
    TO accountant;

-- Different clusters per name in one statement
CREATE ROW POLICY pol1 ON CLUSTER cluster1 ON table1, pol2 ON CLUSTER cluster2 ON table2

​

Cláusula USING

Permite especificar una condición para filtrar filas. Un usuario verá una fila si la condición se evalúa como distinta de cero para esa fila.

​

Cláusula TO

En la sección TO puedes indicar una lista de usuarios y roles a los que se aplicará esta política. Por ejemplo, CREATE ROW POLICY ... TO accountant, john@localhost.

La palabra clave ALL significa todos los usuarios de ClickHouse, incluido el usuario actual. La palabra clave ALL EXCEPT permite excluir algunos usuarios de la lista de todos los usuarios; por ejemplo, CREATE ROW POLICY ... TO ALL EXCEPT accountant, john@localhost

Los roles indicados en la sección TO, incluidos los que aparecen después de ALL EXCEPT, se comparan con los roles habilitados del usuario actual (system.enabled_roles), y no con todos los roles concedidos al usuario, por lo que SET ROLE puede cambiar qué políticas se aplican.

​

Cláusula AS

Se permite que haya más de una política habilitada en la misma tabla para el mismo usuario al mismo tiempo. Por lo tanto, necesitamos una forma de combinar las condiciones de varias políticas.

De forma predeterminada, las políticas se combinan mediante el operador booleano OR. Por ejemplo, las siguientes políticas:

CREATE ROW POLICY pol1 ON mydb.table1 USING b=1 TO mira, peter
CREATE ROW POLICY pol2 ON mydb.table1 USING c=2 TO peter, antonio

permitir al usuario peter ver las filas con b=1 o c=2.

La cláusula AS especifica cómo deben combinarse las políticas entre sí. Las políticas pueden ser permisivas o restrictivas. De forma predeterminada, las políticas son permisivas, lo que significa que se combinan mediante el operador booleano OR.

Como alternativa, una política puede definirse como restrictiva. Las políticas restrictivas se combinan mediante el operador booleano AND.

Esta es la fórmula general:

row_is_visible = (one or more of the conditions from the permissive policies that apply to the current user and their enabled roles are non-zero) AND
                 (all of the conditions from the restrictive policies that apply to the current user and their enabled roles are non-zero)

Si no se aplica ninguna condición permisiva, la primera condición no tiene efecto y solo deciden las políticas restrictivas, porque access_control_improvements.users_without_row_policies_can_read_rows está habilitado de forma predeterminada. Por lo tanto, un usuario al que no se le aplique ninguna condición ve todas las filas, y access_control_improvements.throw_on_unmatched_row_policies, deshabilitado de forma predeterminada, lanza en su lugar una excepción cuando la tabla sí tiene condiciones y ninguna de ellas se aplica.

Por ejemplo, las siguientes políticas:

CREATE ROW POLICY pol1 ON mydb.table1 USING b=1 TO mira, peter
CREATE ROW POLICY pol2 ON mydb.table1 USING c=2 AS RESTRICTIVE TO peter, antonio

permiten al usuario peter ver filas solo si b=1 Y c=2.

Las políticas de base de datos se combinan con las políticas de tabla.

Por ejemplo, las siguientes políticas:

CREATE ROW POLICY pol1 ON mydb.* USING b=1 TO mira, peter
CREATE ROW POLICY pol2 ON mydb.table1 USING c=2 AS RESTRICTIVE TO peter, antonio

permiten que el usuario peter vea las filas de table1 solo si se cumplen tanto b=1 COMO c=2, aunque cualquier otra tabla de mydb tendría aplicada únicamente la política b=1 para el usuario.

​

Tablas Distributed y con respaldo remoto

Una ROW POLICY filtra las filas en el lugar donde se leen realmente los datos de la tabla. Una tabla que delega la lectura en servidores remotos, como una tabla Distributed o un envoltorio de una de ellas (por ejemplo, una vista materializada con un destino Distributed), solo envía el texto de la consulta a los servidores remotos y no puede aplicar el filtro de la ROW POLICY a la lectura remota. Para evitar que el filtro se omita silenciosamente, las consultas a este tipo de tabla realizadas por usuarios a los que se aplica la ROW POLICY se rechazan con el error ILLEGAL_PREWHERE.

En su lugar, defina la ROW POLICY en las tablas locales subyacentes de cada servidor remoto; se aplicará allí cuando la consulta enviada las lea:

-- Filters reads of local_table on this server, including reads shipped by a Distributed table over it.
CREATE ROW POLICY filter ON mydb.local_table USING a < 1000 TO john;

Esto funciona cuando la consulta se envía como texto, que es el comportamiento predeterminado. Con serialize_query_plan = 1, el iniciador envía en su lugar un plan de lectura ya generado, y un servidor remoto que ejecuta ese plan no aplica sus propias ROW POLICY, por lo que la lectura de una tabla Distributed sobre local_table devuelve filas sin filtrar. Mantenga serialize_query_plan = 0 para los usuarios cuyas ROW POLICY deban aplicarse. Consulte el issue #112891.

​

Cláusula ON CLUSTER

Permite crear políticas de fila en un clúster; consulta DDL distribuido. También es una forma práctica de crear la política en las tablas locales de cada servidor del clúster.

​

Ejemplos

CREATE ROW POLICY filter1 ON mydb.mytable USING a<1000 TO accountant, john@localhost

CREATE ROW POLICY filter2 ON mydb.mytable USING a<1000 AND b=5 TO ALL EXCEPT mira

CREATE ROW POLICY filter3 ON mydb.mytable USING 1 TO admin

CREATE ROW POLICY filter4 ON mydb.* USING 1 TO admin