Masking Sensitive Fields for Certain Users

[sam8]

Looker will not be updating this content, nor guarantees that everything is up-to-date. 

The Problem

You have a field that you want only some of your users to be able to see data in. While data access permissions are usually handled at the model level, you don't want to create a whole new model just to mask this field. You don't mind if other users know that the field exists, but you do want to make sure that the users never see data for that field.

The Solutions

This article discusses two possible ways of approaching this problem:

• Use the ability to reference user attributes in SQL with Liquid syntax to mask the content of these fields.
• Use access grants to leverage user attribute values to control which users can view specific content.

The following examples use email addresses to illustrate these solutions.

User Attributes with Liquid

Referencing user attributes in SQL with Liquid syntax lets you mask the contents of these fields, depending on the user who is querying them.

1. Create a new user attribute called can_see_email. Set User Access to View. This will allow users to see the attribute but not have control over its value. Set the default value to no, so you will have to explicitly change the value to yes for users and groups that you want to be able to see email addresses. When you've finished this step, the settings will look something like this:

2. Now you can create a new dimension that references this user attribute and returns values only when the user attribute is set to yes. When the user attribute is set to no, return a static string such as "REDACTED".

dimension: user_email {
  type: string
  sql:
    {% if _user_attributes['can_see_email']  == 'yes' %}
      ${TABLE}.user_email
    {% else %}
      '[REDACTED]'
    {% endif %}   ;;
}

Bonus: You can take advantage of the fact that Liquid works in the label parameter to let users know the field is redacted for them.

dimension: user_email {
  type: string
  label: "{% if _user_attributes['can_see_email'] == 'yes' %} User Email
    {% else %} User Email (Redacted due to insufficient permissions)
    {% endif %}"
  sql:
  {% if _user_attributes['can_see_email']  == 'yes' %}
      ${TABLE}.user_email
  {% else %}
      '[REDACTED]'
  {% endif %}   ;;
}

Access Grants

Access grants are another way to leverage user attribute values to control which users can view specific Explores, joins, views, or fields. Access grants are defined at the model level with the access_grant parameter. As part of the definition, you associate the access grant with a user attribute. You also specify which user attribute values provide access to the access grant.

Once defined, access grants can be applied to Explores, joins, views, or fields with the required_access_grants parameter to restrict access to those structures.

For example, you can create an access grant to restrict user access to the user_email field:

access_grant: can_see_email {
    user_attribute: can_see_email
    allowed_values: ["yes"]
  }

Then you can apply it to the user_email dimension like so:

  dimension: user_email {
    type: string
    sql: ${TABLE}.user_email;
    required_access_grants: [can_see_email]
  }

This will allow only users who have the can_see_email user attribute value set to "yes" to view the user_email field.

Note: Keep in mind that access grants are additive when nested at multiple LookML structure levels (Explore, join, view, field). Review the access_grant documentation page for additional details.