Skip to content

Redshift#

This topic covers how you can configure PolicySync Redshift access control using Privacera Manager.

CLI Configuration#

  1. SSH to the instance where Privacera is installed.

  2. Run the following commands.

    cd ~/privacera/privacera-manager
cp config/sample-vars/vars.PolicySync.redshift.yml config/custom-vars/
vi config/custom-vars/vars.PolicySync.redshift.yml

  3. Set the properties for your specific installation. For property details and description, see the Configuration Properties section that follows.

    Note

    Along with the above properties, you can add custom properties that are not included by default. For more information about these properties, see Redshift Connector.

  4. Run the following commands.

    cd ~/privacera/privacera-manager/
./privacera-manager.sh update

Configuration Properties#

Property Mandatory Description Default Value Example
REDSHIFT_V2_ENABLE Yes Property to enable/disable Redshift. true true
REDSHIFT_JDBC_URL Yes

This property used to set JDBC URL which can be used to connect to redshift server.
JDBC URL must follow below convention: jdbc:redshift://<REDSHIFT_SERVER_HOST>:<REDSHIFT_SERVER_PORT>

jdbc:redshift://example.com
REDSHIFT_JDBC_DB Yes This property specifies the JDBC database that will be used to establish the initial connection to Redshift. privacera_db privacera_db
REDSHIFT_JDBC_USERNAME Yes This property is used to specify the JDBC username that will be used to connect to Redshift.
REDSHIFT_JDBC_PASSWORD Yes This property is used to specify the JDBC username password that will be used to connect to Redshift.
Password can be stored in a jceks file and referenced here.
REDSHIFT_DEFAULT_USER_PASSWORD Yes This property is used to specify the password that will be used for each new user created by PolicySync.
REDSHIFT_OWNER_ROLE

Use this property to set the owner for all the resources managed by PolicySync. The specified role will become owner for all managed resources. Privacera supports changing owners of database, schema, tables and views.

Note: If owner role is kept blank, then the user who creates the table/view or any object, they will become the owner of those object. This will not allow PolicySync to perform access control.

REDSHIFT_AUDIT_ENABLE Yes This property enables access audit retrieval from Redshift. true true/false
REDSHIFT_MANAGE_DATABASE_LIST Yes This property specifies a comma-separated list of database names for which PolicySync manages access control.
If you want to manage all databases, you can skip this property.
This also accepts wildcards.
The manage database list takes precedence over the ignore database list.
For example, testdb1, testdb2, sales db*		 testdb1, testdb2, sales db*
REDSHIFT_MANAGE_SCHEMA_LIST This property specifies a comma-separated list of schema FQDN for which PolicySync manages access control.
Enter the value for the property in the following:
{database_name}.{schema_name}
If the value is kept blank, then all schemas will be managed.
If the value is none, then no schemas will be managed.
If the value is specified as {database_name}.*, then all schemas will be managed.
 testdb1.schema1,testdb2.schema2,sales_db*.sales*
REDSHIFT_MANAGE_TABLE_LIST This property specifies a comma-separated list of table FQDN for which PolicySync manages access control.
Enter the value for the property in the following:
{database_name}.{schema_name}.{table_name}
If the value is kept blank, then all tables will be managed.
If the value is none, then no tables will be managed.
If the value is specified as {database_name}.{schema_name}.*, then all tables will be managed.
 testdb1.schema1.table1,testdb2.schema2.view2,sales_db*.sales*.*
REDSHIFT_GRANT_UPDATES Yes This property determines whether actual grant/revoke and create/update/delete queries for user/group/role must be run on Redshift. true
REDSHIFT_MANAGE_USER_LIST This property specifies a comma-separated list of user names for which PolicySync manages access control.
This also works with wildcards.
The ignore users list takes precedence over the manage users list.
For example, user1,user2,dev_user*
 user1,user2,dev_user*
REDSHIFT_MANAGE_GROUP_LIST This property specifies a comma-separated list of group names for which PolicySync manages access control.
If you want to manage all groups, you can skip this property.
This also works with wildcards.
The ignore group list takes precedence over the manage groups list.
For example, group1,group2,dev_group*
 group1,group2,dev_group*
REDSHIFT_MANAGE_ROLE_LIST This property specifies a comma-separated list of role names for which PolicySync manages access control.
If you want to manage all roles, you can skip this property.
This also accepts wildcards.
The manage role list takes precedence over the ignore role list.
For example, role1,role2,dev_role*
 role1,role2,dev_role*
REDSHIFT_IGNORE_USER_LIST This property specifies a comma-separated list of user names for which PolicySync does not manage access control.
If you do not want to ignore any users, you can leave this property blank.
This also accepts wildcards.
This takes precedence over the list of users to manage.
For example, user1,user2,dev_user* 		user1,user2,dev_user*
REDSHIFT_IGNORE_GROUP_LIST This property specifies a comma-separated list of group names for which PolicySync does not manage access control.
If you do not want to ignore any groups, you can leave this property blank.
This also accepts wildcards.
This takes precedence over the list of manage groups.
For example, group1,group2,dev_group* 		group1,group2,dev_group*
REDSHIFT_IGNORE_ROLE_LIST This property specifies a comma-separated list of role names for which PolicySync does not manage access control.
If you do not want to ignore any roles, you can leave this property blank.
This also works with wildcards.
This takes precedence over the manage roles list.
For example, role1,role2,dev role* 		role1,role2,dev_role*
REDSHIFT_MANAGE_USER_FILTERBY_GROUP Set this property to true if you only want to manage users who belong to the groups specified in the REDSHIFT_MANAGE_GROUP_LIST property. false false
REDSHIFT_MANAGE_GROUPS Use this property to create roles in Redshift when groups are retrieved from Ranger. false
REDSHIFT_ENABLE_VIEW_BASED_MASKING

Set this property to true, if you want to enable secure view-based masking in Redshift PolicySync.

Note:- Redshift does not support native masking. It is recommended to use view-based masking.

 true true/false

Note

As there is no concept of role in Redshift, PolicySync internally creates a group for that user and grants permission to that group to which the user belongs.

For example, when you add a role in the Privacera Portal, you will notice that CREATE GROUP priv_role_rol1 is created instead of CREATE ROLE priv_role_rol1.

Limitations with Dynamic Masking and Row Filter#

  • Updating Group/Role will not update Dynamic Row Filter or Dynamic Masking.

  • In case of dynamic view, you must have Usage permission on both VIEW Schema as well as Table Schema.

  • Assuming row filter is enabled, you have cleared RocksDB cache and PolicySync is up, you will not be able to disable the row filter.