Local Policies

Local policies apply to a specific repository and specify access control at the level of tables or collections in a repository. Local policies are created and managed from the Policies tab in the Repository Details page.

Policy Structure

The structure of a local policy is very similar to that of a global policy with the same top level fields: governedData, readRules, deleteRules, and updateRules. The specific differences within these fields are specified below.

• governedData is an object with a single required field locations that specifies the database tables or collections (or objects in case of S3) that the policy applies to. In the most general case, a location is specified as <database>.<schema>.<table>. Wildcard characters are permitted. In case of specific database types, the format may be slightly different. For example, for MySQL, you would only specify <schema>.<table> while for MongoDB, you would specify <database>.<collection>. Note that local policies cannot be granularly applied to individual fields.

• Rules and how they are evaluated is nearly identical to that for global policies, including how the rule conditions are defined. The only difference is that the constraints object has the following fields (all optional).

  • maxRows: row limit while accessing the table.
  • alert: as for global policies, specifies an alert to be raised when the table is accessed.
  • datasetRewrite: Dataset rewrites are a very powerful policy feature that allows the incoming query to be rewritten such that every occurrence of the table is replaced by a specified subquery. In the most common case, the subquery would add a filter condition to the table being accessed. Placeholder values representing the database and the table specification as well as fields from the activity log can be used in the substitution query. As an example, the value of this field can be "SELECT * from ${dataset} WHERE email = '${identity.endUserEmail}'".

  Note that datasetRewrite can only be specified in readRules.

Complete Policy Example

The following policy governs access to the table customers within any schema in the database appdb. Users except those in the admin group are restricted to reading their own data. The web application that uses the database account webapp can read the data without restrictions. Further, only this application can update or delete data in the table.

{
    "governedData": {
        "locations": ["appdb.*.customers"]
    },
    "readRules": [
        {
            "conditions": [
                "attribute": "identity.userGroups",
                "operator": "contains",
                "value": "admin"
            ],
            "constraints": {}
        },
        {
            "conditions": [
                {
                    "attribute": "identity.repoUser",
                    "operator": "equals",
                    "value": "webapp"
                }
            ],
            "constraints": {}
        },
        {
            "conditions": [],
            "constraints": {
                "datasetRewrite": "SELECT * FROM ${dataset} WHERE email = '${identity.endUserEmail}'"
            }
        }
    ],
    "updateRules": [
        {
            "conditions": [
                {
                    "attribute": "identity.repoUser",
                    "operator": "equals",
                    "value": "webapp"
                }
            ],
            "constraints": {}
        }
    ],
    "deleteRules": [
        {
            "conditions": [
                {
                    "attribute": "identity.repoUser",
                    "operator": "equals",
                    "value": "webapp"
                }
            ],
            "constraints": {}
        }
    ]
}

The policy above has two read rules. The first applies only if the user is a member of the admin group and allows access without any constraints. The second rule has no conditions and hence applies to all users. This rule specifies a dataset rewriting constraint that specifies a substition query that will filter out all rows from the table except those pertaining to the user themselves. Since the rules are evaluated in sequence and evaluation stops when the first matching rule is found, the effect of these two rules is that members of the admin group will see all the data while all other users will only see their own data.

There is just one update rule and a similar delete rule. These rules have a condition requiring the database account to be webapp and no constraints. For all other users, this rule will not match and hence update or delete access will be denied.