- Platform Release 6.5
- Privacera Platform Installation
- About Privacera Manager (PM)
- Install overview
- Prerequisites
- Installation
- Default services configuration
- Component services configurations
- Access Management
- Data Server
- PolicySync
- Snowflake
- Redshift
- Redshift Spectrum
- PostgreSQL
- Microsoft SQL Server
- Databricks SQL
- RocksDB
- Google BigQuery
- Power BI
- UserSync
- Privacera Plugin
- Databricks
- Spark standalone
- Spark on EKS
- Portal SSO with PingFederate
- Trino Open Source
- Dremio
- AWS EMR
- AWS EMR with Native Apache Ranger
- GCP Dataproc
- Starburst Enterprise
- Privacera services (Data Assets)
- Audit Fluentd
- Grafana
- Ranger Tagsync
- Discovery
- Encryption & Masking
- Privacera Encryption Gateway (PEG) and Cryptography with Ranger KMS
- AWS S3 bucket encryption
- Ranger KMS
- AuthZ / AuthN
- Security
- Access Management
- Reference - Custom Properties
- Validation
- Additional Privacera Manager configurations
- CLI actions
- Debugging and logging
- Advanced service configuration
- Increase Privacera portal timeout for large requests
- Order of precedence in PolicySync filter
- Configure system properties
- PolicySync
- Databricks
- Table properties
- Upgrade Privacera Manager
- Troubleshooting
- How to validate installation
- Possible Errors and Solutions in Privacera Manager
- Unable to Connect to Docker
- Terminate Installation
- 6.5 Platform Installation fails with invalid apiVersion
- Ansible Kubernetes Module does not load
- Unable to connect to Kubernetes Cluster
- Common Errors/Warnings in YAML Config Files
- Delete old unused Privacera Docker images
- Unable to debug error for an Ansible task
- Unable to upgrade from 4.x to 5.x or 6.x due to Zookeeper snapshot issue
- Storage issue in Privacera UserSync & PolicySync
- Permission Denied Errors in PM Docker Installation
- Unable to initialize the Discovery Kubernetes pod
- Portal service
- Grafana service
- Audit server
- Audit Fluentd
- Privacera Plugin
- How-to
- Appendix
- AWS topics
- AWS CLI
- AWS IAM
- Configure S3 for real-time scanning
- Install Docker and Docker compose (AWS-Linux-RHEL)
- AWS S3 MinIO quick setup
- Cross account IAM role for Databricks
- Integrate Privacera services in separate VPC
- Securely access S3 buckets ssing IAM roles
- Multiple AWS account support in Dataserver using Databricks
- Multiple AWS S3 IAM role support in Dataserver
- Azure topics
- GCP topics
- Kubernetes
- Microsoft SQL topics
- Snowflake configuration for PolicySync
- Create Azure resources
- Databricks
- Spark Plug-in
- Azure key vault
- Add custom properties
- Migrate Ranger KMS master key
- IAM policy for AWS controller
- Customize topic and table names
- Configure SSL for Privacera
- Configure Real-time scan across projects in GCP
- Upload custom SSL certificates
- Deployment size
- Service-level system properties
- PrestoSQL standalone installation
- AWS topics
- Privacera Platform User Guide
- Introduction to Privacera Platform
- Settings
- Data inventory
- Token generator
- System configuration
- Diagnostics
- Notifications
- How-to
- Privacera Discovery User Guide
- What is Discovery?
- Discovery Dashboard
- Scan Techniques
- Processing order of scan techniques
- Add and scan resources in a data source
- Start or cancel a scan
- Tags
- Dictionaries
- Patterns
- Scan status
- Data zone movement
- Models
- Disallowed Tags policy
- Rules
- Types of rules
- Example rules and classifications
- Create a structured rule
- Create an unstructured rule
- Create a rule mapping
- Export rules and mappings
- Import rules and mappings
- Post-processing in real-time and offline scans
- Enable post-processing
- Example of post-processing rules on tags
- List of structured rules
- Supported scan file formats
- Data Source Scanning
- Data Inventory
- TagSync using Apache Ranger
- Compliance Workflow
- Data zones and workflow policies
- Workflow Policies
- Alerts Dashboard
- Data Zone Dashboard
- Data zone movement
- Workflow policy use case example
- Discovery Health Check
- Reports
- How-to
- Privacera Encryption Guide
- Overview of Privacera Encryption
- Install Privacera Encryption
- Encryption Key Management
- Schemes
- Encryption with PEG REST API
- Privacera Encryption REST API
- PEG API endpoint
- PEG REST API encryption endpoints
- PEG REST API authentication methods on Privacera Platform
- Common PEG REST API fields
- Construct the datalist for the /protect endpoint
- Deconstruct the response from the /unprotect endpoint
- Example data transformation with the /unprotect endpoint and presentation scheme
- Example PEG API endpoints
- /authenticate
- /protect with encryption scheme
- /protect with masking scheme
- /protect with both encryption and masking schemes
- /unprotect without presentation scheme
- /unprotect with presentation scheme
- /unprotect with masking scheme
- REST API response partial success on bulk operations
- Audit details for PEG REST API accesses
- Make encryption API calls on behalf of another user
- Troubleshoot REST API Issues on Privacera Platform
- Privacera Encryption REST API
- Encryption with Databricks, Hive, Streamsets, Trino
- Databricks UDFs for encryption and masking
- Hive UDFs
- StreamSets Data Collector (SDC) and Privacera Encryption
- Trino UDFs for encryption and masking
- Privacera Access Management User Guide
- Privacera Access Management
- How Polices are evaluated
- Resource policies
- Policies overview
- Creating Resource Based Policies
- Configure Policy with Attribute-Based Access Control
- Configuring Policy with Conditional Masking
- Tag Policies
- Entitlement
- Service Explorer
- Users, groups, and roles
- Permissions
- Reports
- Audit
- Security Zone
- Access Control using APIs
- AWS User Guide
- Overview of Privacera on AWS
- Set policies for AWS services
- Using Athena with data access server
- Using DynamoDB with data access server
- Databricks access manager policy
- Accessing Kinesis with data access server
- Accessing Firehose with Data Access Server
- EMR user guide
- AWS S3 bucket encryption
- Getting started with Minio
- Plugins
- How to Get Support
- Coordinated Vulnerability Disclosure (CVD) Program of Privacera
- Shared Security Model
- Privacera Platform documentation changelog
Snowflake
This topic covers how you can configure Snowflake PolicySync access control using Privacera Manager.
Prerequisites
Ensure the following:
Create a Snowflake account that is accessible from the instance used for Privacera Manager installation.
Create the Snowflake warehouse, database, users, and roles required by PolicySync. For more information, see Snowflake Configuration for PolicySync.
CLI configuration
SSH to the instance where Privacera is installed.
Run the following commands.
cd ~/privacera/privacera-manager cp config/sample-vars/vars.policysync.snowflake.yml config/custom-vars/ vi config/custom-vars/vars.policysync.snowflake.yml
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 Snowflake Connector.
Run the following commands.
cd ~/privacera/privacera-manager ./privacera-manager.sh update
Steps to validate the install.
Install snowsql if it's not already installed.
mkdir -p ~/privacera/downloads cd ~/privacera/downloads wget https://privacera.s3.amazonaws.com/public/pm-demo-data/snowflake/install_snowsql.sh -O install_snowsql.sh chmod +x install_snowsql.sh ./install_snowsql.sh
Download the script for access check.
wget https://privacera.s3.amazonaws.com/public/pm-demo-data/snowflake/snowflake_access_check.sh -O snowflake_access_check.sh chmod +x snowflake_access_check.sh
Run downloaded script. For example,./snowflake_access_check.sh testsnowflake.prod.us-west-2.aws emily welcome123
./snowflake_access_check.sh ${SNOWFLAKE_ACCOUNT} ${USERNAME} ${PASSWORD}
Verify access/denied results by logging in with the Privacera Portal user credentials.
Navigate to Privacera Portal > Access Management > Audit. Now, access to Snowflake will be shown as Allowed.
Configuration properties
JDBC configuration
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
| Yes | Specifies the JDBC URL for the Snowflake connector. | |
|
| Yes | Specifies the JDBC username to use. | |
|
| Yes | Specifies the JDBC password to use. | |
|
|
| Yes | Specifies whether PolicySync uses key-pair authentication. Set this property to |
|
| No | Specifies the file name of the private key that PolicySync uses for key-pair authentication. This file is placed in the Specify this setting only if | |
|
| No | Specifies the password for the private key. If the private key does not have a password, do not specify this setting. Specify this setting only if | |
|
| Yes | Specifies the JDBC warehouse that PolicySync establishes a connection to, which is used to run SQL queries. | |
|
| Yes | Specifies the role that PolicySync uses when it runs SQL queries. | |
|
|
| No | Specifies the maximum size for the JDBC connection pool. |
|
|
| No | Specifies the minimum size of the JDBC connection pool. |
|
|
| No | Specifies the duration in milliseconds that a connection is not part of the connection pool before PolicySync logs a possible connection leak message. If set to |
Resource management
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
| No | Specifies the role that owns the resources managed by PolicySync. You must ensure that this user exists as PolicySync does not create this user.
The following resource types are supported:
| |
|
|
| No | Specifies whether PolicySync changes the ownership of a pipe to the role specified by |
|
| No | Specifies a comma-separated list of warehouse names for which PolicySync manages access control. If unset, access control is managed for all warehouses. If specified, use the following format. You can use wildcards. Names are case-sensitive. An example list of warehouses might resemble the following: testdb1warehouse,testdb2warehouse, sales_dbwarehouse* | |
|
| No | Specifies a comma-separated list of database names for which PolicySync manages access control. If unset, access control is managed for all databases. If specified, use the following format. You can use wildcards. Names are case-sensitive. An example list of databases might resemble the following: If specified, | |
|
| No | Specifies a comma-separated list of schema names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. Use the following format when specifying a schema:
If specified, If you specify a wildcard, such as in the following example, all schemas are managed:
The specified value, if any, is interpreted in the following ways:
| |
|
| No | Specifies a comma-separated list of table names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. Use the following format when specifying a table: <DATABASE_NAME>.<SCHEMA_NAME>.<TABLE_NAME> If specified, If you specify a wildcard, such as in the following example, all matched tables are managed:
The specified value, if any, is interpreted in the following ways:
| |
|
| No | Specifies a comma-separated list of stream names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of streams might resemble the following: testdb1.schema1.stream1,testdb2.schema2.stream* If unset, access control is managed for all streams. | |
|
| No | Specifies a comma-separated list of function names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of functions might resemble the following: testdb1.schema1.fn1,testdb2.schema2.fn* If unset, access control is managed for all functions. | |
|
| No | Specifies a comma-separated list of procedure names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of procedures might resemble the following: testdb1.schema1.procedureA,testdb2.schema2.procedure* If unset, access control is managed for all procedures. | |
|
| No | Specifies a comma-separated list of sequence names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of sequences might resemble the following: testdb1.schema1.seq1,testdb2.schema2.seq* If unset, access control is managed for all sequences. | |
|
| No | Specifies a comma-separated list of file format names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of file formats might resemble the following: testdb1.schema1.fileFmtA,testdb2.schema2.fileFmt* If unset, access control is managed for all file formats. | |
|
| No | Specifies a comma-separated list of pipe names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of pipes might resemble the following: testdb1.schema1.pipeA,testdb2.schema2.pipe* If unset, access control is managed for all pipes. | |
|
| No | Specifies a comma-separated list of external stage names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of external stages might resemble the following: testdb1.schema1.externalStage1,testdb2.schema2.extStage* If unset, access control is managed for all external stages. | |
|
| No | Specifies a comma-separated list of internal stages names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. An example list of internal stages might resemble the following: testdb1.schema1.internalStage1,testdb2.schema2.intStage* If unset, access control is managed for all internal stages. | |
|
| No | Specifies a comma-separated list of warehouse names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all warehouses are subject to access control. This setting supersedes any values specified by | |
|
|
| No | Specifies a comma-separated list of database names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all databases are subject to access control. For example: testdb1,testdb2,sales_db* This setting supersedes any values specified by |
|
|
| No | Specifies a comma-separated list of schema names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all schemas are subject to access control. For example: testdb1.schema1,testdb2.schema2,sales_db*.sales* This setting supersedes any values specified by |
|
| No | Specifies a comma-separated list of table names that PolicySync does not provide access control for. You can specify wildcards. If not specified, all tables are subject to access control. Names are case-sensitive. Specify tables using the following format: <DATABASE_NAME>.<SCHEMA_NAME>.<TABLE_NAME> This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of stream names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all streams are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of functions names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all functions are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of procedures names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all procedures are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of sequences names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all sequences are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of file format names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all file formats are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of pipes names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all pipes are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of external stage names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all external stages are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of internal stage names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all internal stages are subject to access control. This setting supersedes any values specified by |
User, group, and role creation
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies whether PolicySync creates local users for each user in Privacera. |
|
|
| No | Specifies whether PolicySync creates local roles for each user in Privacera. |
|
|
| No | Specifies whether PolicySync uses the user email address as the login name when creating a new user in Snowflake. |
|
| Yes | Specifies the password to use when PolicySync creates new users. | |
|
|
| No | |
|
| No | Specifies the prefix that PolicySync uses when creating local users. For example, if you have a user named | |
|
| No | Specifies the prefix that PolicySync uses when creating local roles. For example, if you have a group named | |
|
| No | Specifies the prefix that PolicySync uses when creating roles from Privacera in the Snowflake data source. For example, if you have a role in Privacera named | |
|
|
| No | |
|
| No | Specifies whether PolicySync maintains user membership in roles in the Snowflake data source. | |
|
| No | Specifies whether PolicySync creates groups from Privacera in the Snowflake data source. | |
|
| No | Specifies whether PolicySync creates roles from Privacera in the Snowflake data source. | |
|
| No | Specifies a comma-separated list of user names for which PolicySync manages access control. You can use wildcards. Names are case-sensitive. If not specified, PolicySync manages access control for all users. If specified, An example user list might resemble the following: | |
|
| No | Specifies a comma-separated list of group names for which PolicySync manages access control. If unset, access control is managed for all groups. If specified, use the following format. You can use wildcards. Names are case-sensitive. An example list of projects might resemble the following: If specified, | |
|
| No | Specifies a comma-separated list of role names for which PolicySync manages access control. If unset, access control is managed for all roles. If specified, use the following format. You can use wildcards. Names are case-sensitive. An example list of projects might resemble the following: If specified, | |
|
| No | Specifies a comma-separated list of user names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all users are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of group names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all groups are subject to access control. This setting supersedes any values specified by | |
|
| No | Specifies a comma-separated list of role names that PolicySync does not provide access control for. You can specify wildcards. Names are case-sensitive. If not specified, all roles are subject to access control. This setting supersedes any values specified by | |
|
|
| No | Specifies a regular expression to apply to a username and replaces each matching character with the value specified by the If not specified, no find and replace operation is performed. |
|
|
| No | Specifies a string to replace the characters matched by the regex specified by the If not specified, no find and replace operation is performed. |
|
|
| No | Specifies a regular expression to apply to a group and replaces each matching character with the value specified by the If not specified, no find and replace operation is performed. |
|
|
| No | Specifies a string to replace the characters matched by the regex specified by the If not specified, no find and replace operation is performed. |
|
|
| No | Specifies a regular expression to apply to a role name and replaces each matching character with the value specified by the If not specified, no find and replace operation is performed. |
|
|
| No | Specifies a string to replace the characters matched by the regex specified by the If not specified, no find and replace operation is performed. |
|
|
| No | Specifies whether PolicySync converts user names to lowercase when creating local users. If set to |
|
|
| No | Specifies whether PolicySync converts group names to lowercase when creating local groups. If set to |
|
|
| No | Specifies whether PolicySync converts role names to lowercase when creating local roles. If set to |
|
|
| No | Specifies how user name conversions are performed. The following options are valid:
This setting applies only if |
|
|
| No | Specifies how group name conversions are performed. The following options are valid:
This setting applies only if |
|
|
| No | Specifies how role name conversions are performed. The following options are valid:
This setting applies only if |
|
|
| No | Set this property to true if you only want to manage users who have an email address associated with them in the portal. |
|
|
| No | Specifies whether to manage only the users that are members of groups specified by |
|
|
| No | Specifies whether to manage only users that are members of the roles specified by |
|
|
| No | Specifies whether PolicySync converts a user role name to uppercase when performing operations. |
|
|
| No | Specifies whether PolicySync converts a group name to uppercase when performing operations. |
|
|
| No | Specifies whether PolicySync converts a role name to uppercase when performing operations. |
Grant updates
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies whether PolicySync performs grants and revokes for access control and creates, updates, and deletes queries for users, groups, and roles. The default value is |
| No | Specifies whether PolicySync applies grants and revokes in batches. If enabled, this behavior improves overall performance of applying permission changes. | ||
|
|
| No | Specifies the maximum number of attempts that PolicySync makes to execute a grant query if it is unable to do so successfully. The default value is |
|
|
| No | Specifies whether PolicySync applies privileges described in Access Manager policies. |
Column level access control
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies whether an access denied exception is displayed if a user does not have access to a table column and attempts to access that column. If enabled, you must set |
Native masking
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies whether PolicySync enables native masking policy creation functionality. |
|
| No | Specifies the name of the database where PolicySync creates custom masking policies. | |
|
|
| No | Specifies the name of the schema where PolicySync creates all native masking policies. If not specified, the resource schema is used as the masking policy schema. |
|
|
| No | Specifies a naming template that PolicySync uses when creating native masking policies. For example, given the following values:
With the default naming template, the following name is used when creating a native masking policy. The customer_db_priv_customer_schema_priv_customer_data_{column} |
Native row filter
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies whether to use the data source native row filter functionality. This setting is disabled by default. When enabled, you can create row filters only on tables, but not on views. |
|
| No | Specifies the name of the database where PolicySync creates native row-filter policies. If not specified, the resource database is considered the same as the row-filter policy database. | |
|
|
| No | Specifies the name of the schema where PolicySync creates all native row-filter policies. If not specified, the resource schema is considered the same as the row-filter policy schema. |
|
|
| No | Specifies a template for the name that PolicySync uses when creating a row filter policy. For example, given a table db_priv_schema_priv_data_<ROW_FILTER_ITEM_NUMBER> |
View based masking/row filter
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies whether to use secure view based row filtering. The default value is While Snowflake supports native filtering, PolicySync provides additional functionality that is not available natively. Enabling this setting is recommended. |
|
|
| No | Specifies whether to use secure view based masking. The default value is |
|
| No | Specifies a prefix string to apply to a secure schema name. By default view-based row filter and masking-related secure views have the same schema name as the table schema name. If you want to change the secure view schema name prefix, specify a value for this setting. For example, if the prefix is | |
|
| No | Specifies a postfix string to apply to a secure view schema name. By default view-based row filter and masking-related secure views have the same schema name as the table schema name. If you want to change the secure view schema name postfix, specify a value for this setting. For example, if the postfix is | |
|
| No | Specifies a prefix string for secure views. By default view-based row filter and masking-related secure views have the same schema name as the table schema name. If you want to change the secure view schema name prefix, specify a value for this setting. For example, if the prefix is | |
|
|
| No | Specifies a postfix string for secure views. By default view-based row filter and masking-related secure views have the same schema name as the table schema name. If you want to change the secure view schema name postfix, specify a value for this setting. For example, if the postfix is |
|
| No | Specifies a suffix to remove from a schema name. For example, if a schema is named You can specify a single suffix or a comma separated list of suffixes. | |
|
| No | Specifies a suffix to remove from a table or view name. For example, if the table is named You can specify a single suffix or a comma separated list of suffixes. | |
|
|
| No | Specifies whether to create secure views for all tables and views that are created by users. If enabled, PolicySync creates secure views for resources regardless of whether masking or filtering policies are enabled. |
Masking/Row filter policy name separator
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies a string to use as part of the name of native row filter and masking policies. |
|
|
| No | Specifies an identifier that PolicySync uses to identify columns from the main table and parse each correctly. |
Masked Value for Masking
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies the default masking value for numeric column types. |
|
|
| No | Specifies the default masking value for |
|
|
| No | Specifies the default masking value for text and string column types. |
|
| No | Specifies the default masking value for date column types. |
PEG integration
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
| No | Specifies the name of the database where the PEG encryption functions reside. | |
|
|
| No | Specifies the schema name where the PEG encryption functions reside. |
Load sql queries from system config json file
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies how PolicySync loads resources from Snowflake. The following values are allowed:
|
Audit integration
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| Yes | Specifies whether Privacera fetches access audit data from the data source. |
|
|
| No | Specifies whether to enable simple auditing. When enabled, PolicySync gathers the following audit information from the database:
If you enabled this setting, do not enable |
|
|
| No | Specifies whether to enable advanced auditing. When enabled, PolicySync gathers the following audit information from the database:
If you enabled this setting, do not enable |
|
| No | Specifies whether PolicySync filters access audit information by managed resources, such as databases, schemas, and so forth. | |
|
|
| No | Specifies the initial delay, in minutes, before PolicySync retrieves access audits from Snowflake. |
|
|
| No | Specifies the database that PolicySync retrieves access audits from. This setting applies only if you set |
Load intervals
Name | Type | Default | Required | Description |
---|---|---|---|---|
|
|
| No | Specifies the interval in seconds for PolicySync to wait before checking for new resources or changes to existing resources. |
|
|
| No | Specifies the interval in seconds for PolicySync to wait before reconciling principals with those in the data source, such as users, groups, and roles. When differences are detected, PolicySync updates the principals in the data source accordingly. |
|
|
| No | Specifies the interval in seconds for PolicySync to wait before reconciling Apache Ranger access control policies with those in the data source. When differences are detected, PolicySync updates the access control permissions on data source accordingly. |
|
|
| No | Specifies the interval in seconds to elapse before PolicySync retrieves access audits and saves the data in Privacera. |
Object Permission Mapping
For more information about object permission mapping, see Snowflake Documentation.
Object | Supported Permissions | Description |
---|---|---|
|
| Enables creating a new virtual warehouse. Enables creating a new database in the system. |
|
| Enables using a virtual warehouse and, as a result, executing queries on the warehouse. Enables changing the state of a warehouse (stop, start, suspend, resume). Enables viewing current and past queries executed on a warehouse as well as usage statistics on that warehouse. Enables altering any properties of a warehouse, including changing its size. |
|
| Enables using a database, including returning the database details in the SHOW DATABASES command output. Enables creating a new schema in a database, including cloning a schema. |
|
| Enables using a schema, including returning the schema details in the SHOW SCHEMAS command output. Enables creating a new table in a schema, including cloning a table. Enables creating a new stored procedure in a schema. Enables creating a new UDF or external function in a schema. Enables creating a new stream in a schema, including cloning a stream. Enables creating a new sequence in a schema, including cloning a sequence. Enables creating a new file format in a schema, including cloning a file format. Enables creating a new stage in a schema, including cloning a stage. Enables creating a new pipe in a schema. Enables creating a new external table in a schema. |
|
| Enables executing a SELECT statement on a table. Enables executing an INSERT command on a table. Enables executing an UPDATE command on a table.. Enables executing a DELETE command on a table. Enables executing a TRUNCATE TABLE command on a table. Enables referencing a table as the unique/primary key table for a foreign key constraint. |
|
| Enables executing a SELECT statement on a view. |
|
| Enables calling a stored procedure. |
|
| Enables calling a function. |
|
| Enables executing a SELECT statement on a stream. |
|
| Enables using a file format in a SQL statement. |
|
| Enables using a sequence in a SQL statement. |
|
| Enables performing any operations that require reading from an internal stage (GET, LIST, COPY INTO <table>); Enables performing any operations that require writing to an internal stage (PUT, REMOVE, COPY INTO <location>); |
|
| Enables using an external stage object in a SQL statement. |
|
| Enables viewing details for the pipe (using DESCRIBE PIPE or SHOW PIPES), pausing or resuming the pipe, and refreshing the pipe. Enables viewing details for the pipe (using DESCRIBE PIPE or SHOW PIPES). |
Changing the owner of a table
By default, Privacera’s PolicySync changes the ownership of all resources (databases and tables) to Privacera’s Admin Roles. The reasoning behind this is that there must be a single entity to manage the privileges for the resource. If the owner is not changed, then the user who created the table could also modify the privileges. This could cause inconsistencies in the privileges and even lead to cases where the owner might involuntarily drop security policies like column masking/row-level filtering or provide excessive permissions to unauthorized users.
In Snowflake, there is a limitation in its privilege model, where DROP privileges can’t be given to specific users. Instead, to drop tables, the user must be the owner of the table or must have an Account Admin Role.
When any table is created by a user in Snowflake, the owner defaults to the database role of the user who created it. After the table is created, Privacera will forcefully change the role to the PRIVACERA_POLICYSYNC_ROLE role. And all those users associated with this role will become the owners of the table.
To change the ownership, do the following:
Edit the following file:
vi config/custom-vars/vars.PolicySync.snowflake.yml
Add the
SNOWFLAKE_OWNER_ROLE
property and enter the PRIVACERA_POLICYSYNC_ROLE role.SNOWFLAKE_OWNER_ROLE: "PRIVACERA_POLICYSYNC_ROLE"
If you do not want to change the ownership, leave it blank.
Run the update.
cd ~/privacera/privacera-manager ./privacera-manager.sh update
Note
When a new object is created by a managed user/group/role and is detected by PolicySync, the PolicySync will change the ownership of that object, as specified in the
SNOWFLAKE_OWNER_ROLE
property.