CONFIG_ENTITY_PERMISSIONS

CONFIG_ENTITY_PERMISSIONS is a configuration package that is used to configure entity permissions, such as adding Snowflake user roles to specific entity types.

See also:

• Entity import

Usage

1. Open the configuration package from Designer package list.

2. Click Export package in the Actions tab.

3. Click Download.

4. Edit JSON file.

5. Import edited JSON back to Designer with Import Package.

After a successful import, changes to the configuration package have been applied to Designer only. It is recommended to deploy the same changes to Runtime environments as well.

Contents

Entity permission configuration

Entity permission configurations are managed inside the JSON array block named, entityPermissions.

You can add new entity permission or update the contents of existing entity permission

Example: Entity Permission Configuration

"entityPermissions": [
  . . .
  {
    "permission": "SELECT",
    "description": "Select permission"
  }
  . . .
]

If existing entity permission needs to be deleted, simply remove it from the set of values before importing the configuration package.

Grantee configuration

Grantee configurations are managed inside the JSON array block named, grantees.

You can add new grantee or update the contents of an existing grantee.

It is also possible to refer to predefined environment variables or environment variables defined in a config package CONFIG_ENVIRONMENT_VARIABLES with ${variable}-syntax in the grantee name field.

Example: Grantee Configuration

"grantees": [
  . . .
  {
    "granteeId": 2,
    "granteeName": "READ_ONLY",
    "superGranteeId": null
  },
  {
    "granteeId": 3,
    "granteeName": "${EXEC_ROLE}",
    "superGranteeId": null
  }
  . . .
]

If an existing grantee needs to be deleted, simply remove it from the set of values before importing the configuration package.

Grantee type configuration

Grantee type configurations are managed inside the JSON array block named, granteeTypes.

You can add new granteeType or update the contents of an existing granteeType.

It is also possible to refer to predefined environment variables or environment variables defined in a config package CONFIG_ENVIRONMENT_VARIABLES with ${variable}-syntax in the grantee name field.

Example: Grantee Type Configuration

"granteeTypes": [
  . . .
  {
    "granteeType": "USER",
    "description": "For granting permissions for users"
  },
    {
      "granteeType": "ROLE",
      "description": "For granting permissions for roles"
    },
    {
      "granteeType": "SHARE",
      "description": "For granting permissions for shares"
    }
  . . .
]

If an existing grantee type needs to be deleted, remove or alter also the grantees currently stated currently to be in such granteeType.

Please notice that grantee types for Google BigQuery are case sensitive and the default grantee type USER will be lowercase as required (Google BigQuery user list)

Default grant configuration

Default grant configurations are managed inside the JSON array block named, defaultGrants.

You can add new default grant or update the contents of an existing default grant.

Example: Default Grant Configuration

"defaultGrants": [
  . . .
  {
    "entityType": "GENERIC",
    "permission": "SELECT",
    "granteeId": 2,
    "withGrantOption": false,
    "defaultGrantId": 1
  },
  . . .
]

If an existing default grant needs to be deleted, simply remove it from the set of values before importing the configuration package.

Notes

Variables have to be referred in grantee names with ${variable_name} which differs from the standard notation <variable_name>.

Examples

Using the environment_name variable

Agile Data Engine provides predefined variables that can be used with CONFIG_ENTITY_PERMISSIONS.

In this example, environment_name is used as part of grantee name to use environment specific roles:

 ...
 "grantees": [
    ... ,
    {
      "granteeId": 1,
      "granteeName": "${environment_name}_ANALYST",
      "granteeType": "ROLE"
    },
    {
      "granteeId": 2,
      "granteeName": "${environment_name}_DEVELOPER",
      "granteeType": "ROLE"
    },
    ...
  ]
  ...

Note that any environment variable used in grantee name value is substituted and transformed to uppercase.

Any '-' and '.' are replaced with '_' (except for BigQuery).

For example:

Environment name:

Runtime.1_for-test

Grantee name:

${environment_name}-BI-Developer

Transformed result:

RUNTIME_1_FOR_TEST_BI_Developer.

(for BigQuery > RUNTIME.1_FOR-TEST-BI-Developer)

Row Level Policies configuration

Row Level Policies configurations are managed inside the JSON array block named, rowLevelPolicies.

Example: Row Level Policy Configuration

"rowLevelPolicies": [
  . . .
  {
    "rowLevelPolicyId" : "4ab86cae-614d-47b7-8bb3-f770e6e0bda4",
    "label" : "Sales info only if allowed",
    "preDefinedPolicyFunctionName" : "manager_test.limited_sales_regions",
    "nameSuffix" : "allowed_role",
    "requiresDefinedGrantees" : true,
    "deleted" : false,
    "ruleExpression" : "sales_region = 'APAC'",
    "description" : "Information only to allowed roles"
  }
  . . .
]

If an existing row level policy needs to be deleted, remove or alter also the row level policy attributes currently stated to be in such row level policy. Keep in mind that the modifications to the row level policies do take effect only after the packages where the affected entities are stored are deployed.

Row Level Policy Attributes configuration

Row Level Policy Attributes configurations are managed inside the JSON array block named, rowLevelPolicyAttributes.

Example: Row Level Policy Attribute Configuration

"rowLevelPolicyAttributes": [
  . . .
  {
    "rowLevelPolicyAttributeId" : "9b855c37-ecee-4e97-93a5-ec0e7705d73a",
    "rowLevelPolicyId" : "29862c45-d36b-4da4-bb07-461892dca8f6",
    "attributeName" : "sales_unit",
    "position" : 1,
    "datatype" : "VARCHAR"
  }
  . . .
]

If an existing row level policy attribute needs to be deleted, keep in mind that the modifications to the row level policies do take effect only after the packages where the affected entities are stored are deployed.

Good to know about applying the Row Access Policies

The entity which the policy is wanted to be added must contain the configured policy attributes before the policy can be attached to it.

1. Attribute names must match

2. Attribute datatype must match

3. if Datalength/DataScale/DataPrecision have been defined, they must match - Amazon Redshift has strict matching with the datatypes in policies being attached, so it is recommended to utilise these.