About security and access controls

Admins can define security rules to give granular permissions to rows and columns for different groups of people. These security rules are configured in a workspace's security YAML. Dataland supports granular row and column level permissions, as well as role-based access control.

To configure security on your workspace, just click on Security in the lefthand navigation bar. Only admins can view and manage security rules.

This example below shows the security configuration YAML defined by an admin on the left, and what an affected user sees on the right (i.e. only books with genre 'fiction').

We've designed our security features to be minimally simple to configure and integrated across all user interface surfaces in the platform.

1. Security doesn't require you to modify anything in your underlying production databases or SaaS tools. Dataland has its own data serving layer, which your security rules act on. This means you don't have to manually add external user email <> user group <> data lookup tables to your underlying databases.
2. Security rules apply across all data sources (including data sources via API, like Stripe, Zendesk, etc.), not just tables from an individual daata source.
3. Security rules are deeply integrated across Dataland. They automatically propagate from base tables to downstream materialized views, apply to any ad-hoc SQL query, and apply to what linked rows that a user can see.

Configuration reference

The security YAML allows admins to define granular access controls in Dataland. Note that access controls only affect member-level users in a Dataland workspace; they don't apply to admins. Admins can see all data and perform all actions in a Dataland workspace. Admins can promote or demote users in a workspace by going to Workspace settings > Members.

To configure the security YAML, click on Security in the lefthand navigation bar. Only admins can view and manage security rules.

Here's an example security YAML as a reference, with comments:

baseConstraints:
  - constraintId: base-constraint # the name of the base constraint
    # when restrict_all_rows is true, Members by default cannot view any rows in this workspace, unless given extra permissions below
    restrictAllRows: true
    columnRestrictionPolicies:
      - tableSlug: test-flow-data-table-asheqfy
        # Members by default cannot see the following columns in this table
        excludeColumns:
          - c_address
          - c_comment
          - c_phone

permissions:
  - permissionId: machinery-access
    rowAccessPolicies:
      # Members assigned this permission can see rows where the "c_mktsegment" column is 'MACHINERY' n this table
      - tableSlug: 'test-flow-data-table-asheqfy'
        whereClause: "c_mktsegment = 'MACHINERY'"

    columnAccessPolicies:
      # Members assigned this permission can see the "c_comment" column in this table
      - tableSlug: 'test-flow-data-table-asheqfy'
        includeColumns:
          - c_comment

roles:
  # Name of role
  - roleId: machinery-specialists
    # List of permissions that the role has access to
    permissionIds:
      - machinery-access
    # List of user emails that are assigned this role
    userEmails:
      - 'simon@example.com'
      - 'garfunkel@example.com'

Base constraints (baseConstraints)

Base constraints apply security rules to every member-level user in a Dataland workspace. Think of base constraints as a the "base set" of permissions that every member gets, and members with specific permissions and roles will get additional access layered on.

You can define multiple base constraints, but usually it only makes sense to use one.

Here's an example:

baseConstraints:
  - constraintId: base-constraint
    restrictAllRows: true
    columnRestrictionPolicies:
      - tableSlug: test-flow-data-table-asheqfy
        # Members by default cannot see the following columns in this table
        excludeColumns:
          - c_address
          - c_comment
          - c_phone

• constraintId: You can name the constraint whatever you'd like.
• restrictAllRows: When restrict_all_rows is true, Members by default cannot view any rows in this workspace, unless given extra permissions. When this is unspecified, restrictAllRows is false.
• columnRestrictionPolicies: This expects a list of tableSlug and excludeColumn list combinations. This is commonly used to restrict columns that contain sensitive information, like PII. Tip: Use the handy table reference on the workspace Security page to see a list of all tables, their slugs, and columns so you can write YAML more efficiently.

Permissions (permissions)

Permissions define specific access policies to rows and columns. You can define multiple permissions. Here's an example:

permissions:
  - permissionId: machinery-access
    rowAccessPolicies:
      # Members assigned this permission can see rows where the "c_mktsegment" column is 'MACHINERY' n this table
      - tableSlug: 'test-flow-data-table-asheqfy'
        whereClause: "c_mktsegment = 'MACHINERY'"
    columnAccessPolicies:
      # Members assigned this permission can see the "c_comment" column in this table
      - tableSlug: 'test-flow-data-table-asheqfy'
        includeColumns:
          - c_address

• permissionId: A uniquely identifying name for the permission. This permissionId can be later assigned to roles.
• rowAccessPolicies: A list of row access policies, where each policy specifies which rows from the table that a member can access
  • tableSlug: A table slug is a unique identifier for the table. You can find the tableSlug by going to the table URL and taking the last portion of the URL (i.e. /workspace/../table/{{TABLE_SLUG}}), or you can reference the table slug list on the workspace Security page.
  • whereClause: A SQL clause that defines what data is accessible in the table. Examples could be:
    • 'true' to return all rows
    • order_status = 'pending' - to find all rows where the order status is pending
    • order_line_items ILIKE '%apples&' - to find all rows where the order_line_items column contains the word apples, case insensitive.
    • column_1 = 'x' AND column_2 = 'y' - to find all rows where both column_1 is 'x' and column_2 is 'y'
• columnAccessPolicies: A list of column access policies, where each policy specifies wich columns on the table that a member can access
  • tableSlug: A table slug is a unique identifier for the table. You can find the tableSlug by going to the table URL and taking the last portion of the URL (i.e. /workspace/../table/{{TABLE_SLUG}}), or you can reference the table slug list on the workspace Security page.
  • includeColumns: A list of column names from that table. Tip: Use the handy table reference to see a list of all tables, their slugs, and columns so you can write YAML more efficiently.

Permissions apply on top of base constraints. In the above example, the base constraint hides all rows and several columns in a specific table from members. However, members with the machinery-access permission get to see machinery related rows in a specific table, and the c_address column.

Roles (roles)

Roles are assignments of permissions to user groups, listed by user email. Here's an example:

roles:
  # Name of role
  - roleId: machinery-specialists
    # List of permissions that the role has access to
    permissionIds:
      - machinery-access
    # List of user emails that are assigned this role
    userEmails:
      - 'simon@example.com'
      - 'garfunkel@example.com'

• roleId: A uniquely identifying name for the role. Members that are assigned a role will see the role ID in their navigation bar.
• permissionIds: A list of permission IDs.
• userEmails: A list of members according to the email address they use for Dataland. Tip: For easy YAML writing, use the handy user reference in the workspace Security page, which lists all members and their emails.

By configuring the security YAML, admins can create complex access control policies enforced across all data sources and user interfaces in Dataland.