Skip to main content
Version: v2.x

Policy structure

Your policy consists of these main parts:

  • The data block lists the data locations (schemas, tables, columns, and so on) that this policy covers, using the LABELs you've established in your data map.
  • The rules block holds your data access rules that govern who can perform which operations on which data.
  • In the case of policies managed via GitOps, we also include a meta block which sets the policy's name
info

For a guided tour of a working policy, skip forward to Interpreting the sample policy now.

To understand policy structure, let's look at our Sample policy again so we can examine its structure:

data:
  - EMAIL
  - CCN
  - SSN
rules:
  - identities:
      groups: [analyst]
    reads:
      - data: any
        rows: 10
    updates:
      - data: [EMAIL, CCN]
        rows: 1
        severity: medium
    deletes:
      - data: any
        rows: 1
        severity: medium
  - identities:
      users: [bob]
    hosts: [192.0.2.22, 203.0.113.16/28]
    reads:
      - data: any
        rows: any
    updates:
      - data: [EMAIL, CCN]
        rows: any
    deletes:
      - data: any
        rows: any
  - reads:
      - data: [EMAIL]
        rows: 1

The meta block of a policy​

The meta block is where you give your policy a name and optional tags. This section is only required if you're automating your policy publishing via Github integration.

caution

If you create a policy here and then move it to the version control system (like GitHub) for automated policy management, you must leave the policy and its name unchanged in the Cyral UI.

The data block of a policy​

In your policy, you use the data block to specify which data fields this policy manages. In the data block, you list each field using the LABEL you established for it in your data map. The actual location of that data (the names of fields, columns, or databases that hold it) is listed in the data map.

tip

As mentioned earlier, each LABEL must be used in only one policy. In other words, no two policies may overlap in terms of the fields they protect. Within a single policy, you may use a single LABEL many times in many rules.

See also​

See Manage Cyral with GitOps to see how you can manage your policies with an audit trail and the ability to roll back unwanted changes.