Use cases

Sample policy use cases

Example 1: Read-only access

Here, the user bob has unlimited read-only access to the data EMAIL, CCN, and SSN, disallowing update and delete access.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      users: [bob]
    reads:
      - data: any
        rows: any

Example 2: Add a default rule

This policy includes a default rule (rule with no identities specified) which allows reads of EMAIL up to 1 row at a time if the accessing user is neither bob nor alice. In the previous cases where the default rule isn't specified, no accesses (reads, updates, or deletes) are allowed for users for which an identified rule is not specified.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      users: [bob]
    reads:
      - data: any
        rows: any
    updates:
      - data: [CCN]
        rows: 1
    deletes:
      - data: any
        rows: 1
  - identities:
      users: [alice]
    reads:
      - data: [EMAIL, CCN]
        rows: 1
    updates:
      - data: [EMAIL]
        rows: 1
  - reads:
      - data: [EMAIL]
        rows: 1

Example 3: Apply the same rules to a group of users

The following policy specifies bob, tom, and alex have unlimited read access and limited update and delete access, whereas alice and jeff have limited read and update access and no delete access.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      users: [bob, tom, alex]
    reads:
      - data: any
        rows: any
    updates:
      - data: [CCN]
        rows: 1
    deletes:
      - data: any
        rows: 1
  - identities:
      users: [alice, jeff]
    reads:
      - data: [EMAIL, CCN]
        rows: 1
    updates:
      - data: [EMAIL]
        rows: 1

Example 4: Apply rule to a service identified by its name

The following policy specifies that the service operatingCostPredictor can read an unlimited number of rows from the data location CCN but cannot update or delete.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      services: [operatingCostPredictor]
    reads:
      - data: [CCN]
        rows: any

Example 5: Apply rule to users accessing data through Looker

The following policy specifies that users accessing data through Looker have unlimited read access and no update or delete privileges.

data: [EMAIL, CCN, SSN]
rules:
  - identities:
      services: [looker]
    reads:
      - data: any
        rows: any

Example 6: Only allow users to see data pertaining to themselves

The following policy specifies that any amount of EMAIL, CCN, and SSN can be read, so long as the individual accessing the data was authenticated through SSO, and that they are accessing records which contain their own email address.

Specifically, this rule checks that the request satisfies a filter allowing retrieval of only those records whose userInfo.email value matches the requesting user's email address. The rule is able to read the user's email address from the identity.endUser field of the activity log because the user has authenticated through SSO (ensured by requiring the existence of the identity.group field).

data: [EMAIL, CCN, SSN]
rules:
  - reads:
      - data: any
        rows: any
        additionalChecks: |
          is_valid_request {
            identity.group
            filter := request.filters[_]
            filter.field == "userInfo.email"
            filter.op == "="
            filter.value == identity.endUser
          }