Applying RLS rules to GIS module

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.

1. Overview

The GIS module is one of the subsystems that provide access to Registry data. In Registry regulations, the access to Registry data can be restricted, among other ways, with RLS read rules. Currently, the GIS module ignores these rules.

To fix this drawback, it is recommended to add filtering rules for the envoy proxy server, based on RLS Registry regulations read rule configuration.

3. Functional scenarios

  • Viewing and searching for geodata, restricted by RLS rules

4. Target design

gis-rls-deployment

The configuration of envoy created by Istrio Pilot for the GeoServer is performed using Istio EnvoyFilter.

The configured envoy-filter intercepts requests to the layers with data sources that have configured RLS read rules for. Envoy adds RLS filter conditions to these requests, based on authenticated user attributes, received from jwt.

The GeoServer receives filtered requests and returns only the data that the user is authorized to view.

EnvoyFilter settings are created by service generator, based on RLS metadata, and are set or updated on regulations deployment.

4.1. Service generator

A new value must be added to the module parameter in service generator: --module=geoserver-rls.

On receiving this parameter the service generator will generate Istio EnvoyFilter that takes RLS key from the JWT-token, and adds a CQL_FILTER based on that key to the request parameters, for all requests that require RLS check.

A detailed example of envoy filter that adds the attribute from jwt to the request heading can be found here - how to extract jwt in envoy.

First, on generation it is necessary to find all the RLS read rules for tables and representations used on GeoServer. These rules are stored in the ddm_rls_metadata table. Out of this table, rules where type = read and check_table contain the name of a table or a representation that has geometry type columns.

For every such rule, it is necessary to generate Envoy Filter code that will apply it. The following example shows pseudocode that describes the logic of the check.

Pseudocode example
--The following placeholders are qreplaced by values from the
--corresponding RLS configuration columns from the ddm_rls_metadata table
--${jwtAttribute}
--${checkTable}
--${checkColumn}

--If it is a table read request or view that has RLS configured for, the processing starts
if request_params("service") = "WFS"
    and request_params("request") = "getFeature"
    and request_params("typeName") = "registry:"+${checkTable} then

    --Get value ${jwtAttribute} from token
    jwtRLSattribute = get_jwt_payload(${jwtAttribute})

    if jwtRLSattribute is not null then
        --If jwtAttribute is not empty, rlscolumn filter is formed, like 'jwtAttrValue%'
        --jwtAttribute may contain a data array,
        --a condition is added for each value using or
        for i in jwtRLSattribute loop
            if i !=0
                rls_filter =rls_filter + "or"
            end
            rls_filter =rls_filter + "${checkColumn} like '"+jwtRLSattribute[i]+"%25'"
        end
        rls_filter ="("+rls_filter +")"
    else
        --If jwtAttribute is empty, then a response filter without any value is formed
        rls_filter = "1=0"
    end

    if exists request_params("CQL_FILTER") then
        --If the request already had a cql фільтр, take it into parentheses, add RLS filter
        --conditions and replace CQL_FILTER with the filter formed in request parameters
        request_params("CQL_FILTER") = "("+request_params("CQL_FILTER")+") and "+rls_filter
    else
        --If the request didn't have a cql filter, just add your RLS filter into request parameters
        request_params("CQL_FILTER") = rls_filter
    end
end

4.2. Regulations publication

If the Registry is deployed with the GIS module, the regulations publication pipeline must call the service generator with an option of RLS rule generation for the GIS module. The generated Istio EnvoyFilter resource must be installed or updated in the Registry environment.

If there are no RLS rules, delete Istio EnvoyFilter that could be created in the previous regulations versions.

4.3. System components and their function within the solution design

This section lists system components that are involved, or need to be changed/created within the realization of functional requirements according to the technical solution design.

Component Service name Function / Changes brief

Service generator

service-generation-utility

EnvoyFilter generation based on regulations template and RLS configuration

Registry regulations publication pipeline

registry-regulations-publication-pipeline

Application of the generated EnvoyFilter

4.4. Migration

As RLS rules are not used in existing Registries for GeoServer search conditions, the mechanism of EnvoyFilter generation for the existing RLS rules is not required for Registry update.

On the first regulations deployment after an update, the EnvoyFilter will be generated if RLS rules exist.

5. High-level development plan

5.2. Development plan

  • EnvoyFilter template development

  • Extension of service generator with the capabilities for EnvoyFilter generation, based on template and RLS configuration of the regulations

  • Extension of regulations publication pipeline using the generated EnvoyFilter