Skip to content

Column-level Access Control

Column-level access control is a core data security feature of the Hydrolix platform. Using column policies and permissions, data administrators can implement granular rules limiting access to their datasets.

How does it work?⚓︎

Data administrators construct column policies using the Config API.

Column policies are a list of blocked columns attached to a single table and one or more roles. They combine into a set of allowed columns. Roles are associated with user and service accounts. Changes take place immediately.

The query system retrieves an account's SQL permissions containing the combined column policies before executing a query.

The query system parses the query and rejects any query that includes a column not allowed to the account.

Concepts⚓︎

Hydrolix supports a fully-featured account permissions system that allows definition of roles. Multiple roles can be assigned to users and service accounts, to describe rich access permissions.

Hydrolix column policies

When an authorized account initiates a query, the query head denies queries operating on columns not in the allowed list for that account.

Roles are intentionally composable in an additive fashion to express rich access rules. Roles can be empty or can contain arbitrary combinations of role-based access control (RBAC) permissions, row policies, and column policies. Roles, permissions, row, and column policies combine with a design of positive permissions. See also data access policy design strategies.

Feature interaction⚓︎

Column policies are fully compatible with

Blocked and allowed columns⚓︎

Data administrators specify blocked columns. Only columns that already exist in a table can be blocked.

The Config API computes the allowed columns by combining column policies for enforcement in the query system. For backward compatibility, an empty allowed list is equivalent to listing all columns in a table.

Always add the select_sql permission to a role with a column policy

Column policies don't apply unless the select_sql permission is present in the attached role.

Combining column policies⚓︎

The Config API performs all of the combination logic, and returns the final list of allowed columns for enforcement at query time.

Combining across all roles⚓︎

  1. For each role, collect all sets of blocked columns from all column policies.
  2. Using set intersection, identify columns blocked across all sets.
  3. Create the allowed list by removing the blocked columns from all existing table columns.

The combining logic supports the additive access design. More roles and permissions means more access.

To meet the goal of additive permissions for column policies, a column

  • is blocked if all column polices for roles on an account mention that column
  • is allowed if even one of the column policies in the roles on an account doesn't block the column

Query-time operation⚓︎

When a query head receives a query over any interface, it retrieves the account's permissions and allowed columns from private endpoint /config/v1/users/sqlperms/.

The query head parses the incoming SQL query and verifies that all columns in the incoming query are present in the allowed set for the current user.

If all columns are allowed to the user, the query head continues execution of the query. Otherwise, the query head returns an informative access denied error to the client.

Limitations⚓︎

See data access policy design limitations.

Use cases⚓︎

Column-level access controls

  • allow multiple distinct user populations to be served from the same table, each with a different policy
  • decrease data ingestion complexity when a single data stream serves user populations with distinct data access permissions
  • decrease management effort for table settings and transforms when tables are structurally identical and differ only in data access permissions
  • decrease application or query complexity for cross-table joins where multiple tables were formerly in use
  • support backward compatibility by retaining default visibility when no policies are in effect