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
          }

S3 example 1: No file access

In this example, the user should be blocked from reading any file in the finance-funding bucket:

This example uses the three data labels we showed in Data Map example for S3.

data:
  - FUNDING_BUCKET_ALL
rules:
  - identities:
      users:
        - frank.hardy@hhiu.us

By adding FUNDING_BUCKET_ALL to the top data field, we instruct the sidecars that this data label is associated with sensitive data that needs to be governed by this policy. Since the rules block contains no rule declaring access permissions for this data label, user Frank has no access.

S3 example 2: The right to read files only

In this example, the user should be able to read any file from the finance-funding.2023.event folder, but should not be able to list other folders or read files from any other folders inside that bucket.

This example uses the three data labels we showed in Data Map example for S3.

data:
  - FUNDING_BUCKET_ALL
  - FUNDING_2023_EVENTS
rules:
  - identities:
      users:
        - frank.hardy@hhiu.us
    reads:
      - data:
          - FUNDING_2023_EVENTS
        rows: any
        severity: low

By adding FUNDING_BUCKET_ALL to the top data field, we instruct the sidecars that this data label is associated with sensitive data that needs to be governed by this policy. Since the rules block contains no rule providing the access permissions for this data label, user Frank has no access to the bucket as a whole.

By adding FUNDING_2023_EVENTS to the top data field, we instruct the sidecars that this data label is associated with sensitive data that needs to be governed by this policy. This data label also shows up in the rules.reads.data entry, meaning that the read access is governed by that specific rule.

Within this policy, we have two data labels covering the same data:

• FUNDING_2023_EVENTS: covers only the folder finance-funding.2023.event
• FUNDING_BUCKET_ALL: covers all folders in this bucket, including finance-funding.2023.event.

When Cyral encounters a case like this, the most specific data label is used to evaluate policies.

In this example, this means that even though FUNDING_BUCKET_ALL would prohibit Frank from reading data from finance-funding.2023.event, the more specific data label, FUNDING_2023_EVENTS, overrides the broader data label and allows the read to proceed.

Based on the bolicy above, Frank's attempt to run the following will fail because the policy does not contain a reads rule for the FUNDING_BUCKET_ALL. At the command line, Frank would see this:

aws s3 ls s3://finance-funding
Using S3 proxy: http://edge-sidecar-a01.example.cyral.com:453

An error occurred (Forbidden) when calling the ListObjectsV2 operation: Request blocked as user
[frank.hardy@hhiu.us] does not have permission to access the required resource

On the other hand, Frank can successfully download a file from the finance-funding/2023/event folder because the policy for him contains a reads rule for the FUNDING_2023_EVENTS data label. Here's what Frank will see:

aws s3 cp s3://finance-funding/2023/funding/output.txt /tmp
Using S3 proxy: http://edge-sidecar-a01.example.cyral.com:453

download: s3://finance-funding/2023/funding/output.txt to ../../../../tmp/output.txt