- Welcome to Privacera
- Introduction to Privacera
- Privacera Platform installation
- Plan for Privacera Platform
- Privacera Platform overview
- Privacera Platform installation overview
- Privacera Platform deployment size
- Privacera Platform installation prerequisites
- Choose a cloud provider
- Select a deployment type
- Configure proxy for Privacera Platform
- Prerequisites for installing Privacera Platform on Kubernetes
- Default Privacera Platform port numbers
- Required environment variables for installing Privacera Platform
- Privacera Platform system requirements for Azure
- Prerequisites for installing Privacera Manager on AWS
- Privacera Platform system requirements for Docker in GCP
- Privacera Platform system requirements for Docker in AWS
- Privacera Platform system requirements for Docker in Azure
- Privacera Platform system requirements for Google Cloud Platform (GCP)
- System requirements for Privacera Manager Host in GKE
- System requirements for Privacera Manager Host in EKS
- System requirements for Privacera Manager Host in AKS
- Install Privacera Platform
- Download the Privacera Platform installation packages
- Privacera Manager overview
- Install Privacera Manager on Privacera Platform
- Install Privacera Platform using an air-gapped install
- Upgrade Privacera Manager
- Troubleshoot Privacera Platform installation
- Validate Privacera Platform installation
- Common errors and warnings in Privacera Platform YAML config files
- Ansible Kubernetes Module does not load on Privacera Platform
- Unable to view Audit Fluentd audits on Privacera Platform
- Unable to view Audit Server audits on Privacera Platform
- No space for Docker images on Privacera Platform
- Unable to see metrics on Grafana dashboard
- Increase storage for Privacera PolicySync on Kubernetes
- Permission denied errors in PM Docker installation
- Non-portal users can access restricted Privacera Platform resources
- Storage issue in Privacera Platform UserSync and PolicySync
- Privacera Manager not responding
- Unable to Connect to Docker
- Privacera Manager unable to connect to Kubernetes Cluster
- Unable to initialize the Discovery Kubernetes pod
- Unable to upgrade from 4.x to 5.x or 6.x due to Zookeeper snapshot issue
- 6.5 Platform Installation fails with invalid apiVersion
- Database lockup in Docker
- Remove the WhiteLabel Error Page on Privacera Platform
- Unable to start the Privacera Platform portal service
- Connect applications to Privacera Platform for Access Management
- Connect applications to Privacera Platform using the Data Access Server
- Data Access Server overview
- Integrate AWS with Privacera Platform using the Data Access Server
- Integrate GCS and GCP with Privacera Platform using the Data Access Server
- Integrate ADLS with Privacera Platform using the Data Access Server
- Access Kinesis with the Data Access Server on Privacera Platform
- Access Firehose with Data Access Server on Privacera Platform
- Use DynamoDB with Data Access Server on Privacera Platform
- Connect MinIO to Privacera Platform using the Data Access Server
- Use Athena with Data Access Server on Privacera Platform
- Custom Data Access Server properties
- Connect applications to Privacera Platform using the Privacera Plugin
- Overview of Privacera plugins for Databricks
- Connect Trino Open Source to Privacera Platform via plugin
- Connect AWS EMR with Native Apache Ranger to Privacera Platform
- Configure AWS EMR with Privacera Platform
- Configure Databricks Spark Fine-Grained Access Control Plugin [FGAC] [Python, SQL]
- Configure Databricks Spark Fine-Grained Access Control Plugin [FGAC] [Python, SQL]
- EMR user guide for Privacera Platform
- Connect Kafka datasource via plugin to Privacera Platform
- Connect PrestoSQL standalone to Privacera Platform using Privacera plugin
- Connect Starburst Enterprise to Privacera Platform via plugin
- Connect GCP Dataproc to Privacera Platform using Privacera plugin
- Connect Spark standalone to Privacera Platform using the Privacera plugin
- Connect Amazon EKS to Privacera Platform using Privacera plugin
- Privacera Spark plugin versus Open-source Spark plugin
- Connect Dremio to Privacera Platform via plugin
- Connect applications to Privacera Platform using the Data Access Server
- Connect portal users to Privacera Platform
- Connect Privacera Platform portal users from LDAP
- Set up portal SSO for Privacera Platform with OneLogin using SAML
- Set up portal SSO for Privacea Platform with Okta using SAML
- Set up portal SSO for Privacera Platform with Okta using OAuth
- Set up portal SSO for Privacera Platform with AAD using SAML
- Set up portal SSO for Privacera Platform with PingFederate
- Generate an Okta Identity Provider metadata file and URL
- Configure AuditServer on Privacera Platform
- Configure Solr destination on Privacera Platform
- Enable Solr authentication on Privacera Platform
- Solr properties on Privacera Platform
- Configure Kafka destination on Privacera Platform
- Enable Pkafka for real-time audits in Discovery on Privacera Platform
- AuditServer properties on Privacera Platform
- Configure Fluentd audit logging on Privacera Platform
- Configure High Availability for Privacera Platform
- Configure Privacera Platform system security
- Privacera Platform system security
- Configure SSL for Privacera Platform
- Enable CA-signed certificates on Privacera Platform
- Enable self-signed certificates on Privacera Platform
- Upload custom SSL certificates on Privacera Platform
- Custom Crypto properties on Privacera Platform
- Enable password encryption for Privacera Platform services
- Authenticate Privacera Platform services using JSON Web Tokens
- Configure JSON Web Tokens for Databricks
- Configure JSON Web Tokens for EMR FGAC Spark
- Custom configurations for Privacera Platform
- Privacera Platform system configuration
- Add custom properties using Privacera Manager on Privacera Platform
- Privacera Platform system properties files overview
- Add domain names for Privacera service URLs on Privacera Platform
- Configure Azure PostgreSQL on Privacera Platform
- Spark Standalone properties on Privacera Platform
- AWS Data Access Server properties on Privacera Platform
- Add custom Spark configuration for Databricks on Privacera Platform
- Configure proxy for Privacera Platform
- Configure Azure MySQL on Privacera Platform
- System-level settings for Zookeeper on Privacera Platform
- Configure service name for Databricks Spark plugin on Privacera Platform
- Migrate Privacera Manager from one instance to another
- Restrict access in Kubernetes on Privacera Platform
- System-level settings for Grafana on Privacera Platform
- System-level settings for Ranger KMS on Privacera Platform
- Generate verbose logs on Privacera Platform
- System-level settings for Spark on Privacera Platform
- System-level settings for Azure ADLS on Privacera Platform
- Override Databricks region URL mapping for Privacera Platform on AWS
- Configure Privacera Platform system properties
- EMR custom properties
- Configure AWS Aurora DB (PostgreSQL/MySQL) on Privacera Platform
- Merge Kubernetes configuration files
- Scala Plugin properties on Privacera Platform
- System-level settings for Trino Open Source on Privacera Platform
- System-level settings for Kafka on Privacera Platform
- System-level settings for Graphite on Privacera Platform
- System-level settings for Spark plugin on Privacera Platform
- Create CloudFormation stack
- Configure pod topology for Kubernetes on Privacera Platform
- Configure proxy for Kubernetes on Privacera Platform
- Externalize access to Privacera Platform services with NGINX Ingress
- Custom Privacera Platform portal properties
- Add Data Subject Rights
- Enable or disable the Data Sets menu
- Kubernetes RBAC
- Spark FGAC properties
- Audit Fluentd properties on Privacera Platform
- Privacera Platform on AWS overview
- Privacera Platform Portal overview
- AWS Identity and Access Management (IAM) on Privacera Platform
- Set up AWS S3 MinIO on Privacera Platform
- Integrate Privacera services in separate VPC
- Install Docker and Docker compose (AWS-Linux-RHEL) on Privacera Platform
- Multiple AWS S3 IAM role support in Data Access Server
- Enable AWS CLI on Privacera Platform
- Configure S3 for real-time scanning on Privacera Platform
- Multiple AWS account support in Dataserver using Databricks on Privacera Platform
- Enable AWS CLI
- AWS S3 Commands - Ranger Permission Mapping
- Plan for Privacera Platform
- PrivaceraCloud setup
- PrivaceraCloud data access methods
- Create PrivaceraCloud account
- Log in to PrivaceraCloud with or without SSO
- Connect applications to PrivaceraCloud
- Connect applications to PrivaceraCloud with the setup wizard
- Connect Azure Data Lake Storage Gen 2 (ADLS) to PrivaceraCloud
- Connect Amazon Textract to PrivaceraCloud
- Connect Athena to PrivaceraCloud
- Connect Aurora to PrivaceraCloud
- Azure Data Factory Integration with Privacera Enabled Databricks Cluster
- Connect Google BigQuery to PrivaceraCloud
- Connect Cassandra to PrivaceraCloud for Discovery
- Connect Databricks to PrivaceraCloud
- Connect Databricks SQL to PrivaceraCloud
- Connect Databricks to PrivaceraCloud
- Configure Databricks SQL PolicySync on PrivaceraCloud
- Create an endpoint in Databricks SQL
- Databricks SQL fields on PrivaceraCloud
- Databricks SQL Masking Functions
- Connect Databricks SQL to Hive policy repository on PrivaceraCloud
- Enable Privacera Encryption services in Databricks SQL on PrivaceraCloud
- Example: Create basic policies for table access
- Connect Dremio to PrivaceraCloud
- Connect DynamoDB to PrivaceraCloud
- Connect Elastic MapReduce from Amazon application to PrivaceraCloud
- Connect EMR application
- EMR Spark access control types
- PrivaceraCloud configuration
- AWS IAM roles using CloudFormation setup
- Create a security configuration
- Create EMR cluster
- EMR Native Ranger Integration with PrivaceraCloud
- Connect EMRFS S3 to PrivaceraCloud
- Connect Files to PrivaceraCloud
- Connect Google BigQuery to PrivaceraCloud
- Connect Google Cloud Storage to PrivaceraCloud
- Connect Glue to PrivaceraCloud
- Connect Kinesis to PrivaceraCloud
- Connect Lambda to PrivaceraCloud
- Connect MS SQL to PrivaceraCloud
- Connect MySQL to PrivaceraCloud for Discovery
- Connect Open Source Apache Spark to PrivaceraCloud
- Connect Oracle to PrivaceraCloud for Discovery
- Connect PostgreSQL to PrivaceraCloud
- Connect Power BI to PrivaceraCloud
- Connect Presto to PrivaceraCloud
- Connect Redshift to PrivaceraCloud
- Redshift Spectrum PrivaceraCloud overview
- Connect Snowflake to PrivaceraCloud
- Starburst Enterprise with PrivaceraCloud
- Connect Starburst Enterprise Presto to PrivaceraCloud
- Connect Synapse to PrivaceraCloud
- Connect S3 to PrivaceraCloud
- Connect Trino to PrivaceraCloud
- Trino SQL command permissions
- Trino SQL command permissions - Iceberg connector
- Manage applications on PrivaceraCloud
- Terminology
- Connect an application on PrivaceraCloud
- View application connection status on PrivaceraCloud
- Edit application name and description on PrivaceraCloud
- Delete applications on PrivaceraCloud
- View application connection status on PrivaceraCloud
- Edit applications on PrivaceraCloud
- Delete applications on PrivaceraCloud
- Connect users to PrivaceraCloud
- Data sources on PrivaceraCloud
- PrivaceraCloud custom configurations
- Access AWS S3 buckets from multiple AWS accounts on PrivaceraCloud
- Configure multiple JWTs for EMR
- Access cross-account SQS queue for PostgreSQL audits on PrivaceraCloud
- AWS Access with IAM role on PrivaceraCloud
- Databricks cluster deployment matrix with Privacera plugin
- Whitelist py4j security manager via S3 or DBFS
- General functions in PrivaceraCloud settings
- Cross account IAM role for Databricks
- Operational status of PrivaceraCloud and RSS feed
- How to get support
- Access Management
- Get started with Access Management
- Audits
- Required permissions to view audit logs on Privacera Platform
- About PolicySync access audit records and policy ID on Privacera Platform
- View audit logs
- View PEG API audit logs
- Generate audit logs using GCS lineage
- Configure Audit Access Settings on PrivaceraCloud
- Configure AWS RDS PostgreSQL instance for access audits
- Accessing PostgreSQL Audits in GCP
- Configure Microsoft SQL server for database synapse audits
- Examples of audit search
- Entitlement on Privacera Platform
- Permissions
- Policies
- How polices are evaluated
- Resource policies
- About service groups on PrivaceraCloud
- Service/Service group global actions
- Create resource policies: general steps
- Configure resource policies
- Configure ADLS resource policies
- Configure AWS S3 resource policies
- Configure Athena resource policies
- Configure Databricks resource policies
- Configure PowerBI resource policies
- Configure Hive resource policy
- Configure Lambda resource policies
- Configure Hive resource policies
- Configure Kinesis resource policies
- Configure GBQ resource policies
- Configure Redshift resource policies
- Configure Presto resource policies
- Configure GCS resource policies
- Configure Glue resource policies
- Configure Postgres resource policies
- Configure Kafka resource policies
- Configure Files resource policies
- Configure MSSQL resource policies
- Configure DynamoDB resource policies
- Configure Snowflake resource policies
- Configure Policy with Attribute-Based Access Control (ABAC) on PrivaceraCloud
- Attribute-based access control (ABAC) macros
- Configure access policies for AWS services on Privacera Platform
- Configure policy with conditional masking on Privacera Platform
- Create access policies for Databricks on Privacera Platform
- Order of precedence in PolicySync filter
- Example: Manage access to Databricks SQL with Privacera
- Service/service group global actions on the Resource Policies page
- Tag policies
- Reports
- Policy configuration settings
- Manage Databricks policies on Privacera Platform
- Create a custom policy repository with Databricks
- Configure policy with Attribute-Based Access Control on Privacera Platform
- Create Databricks policies on Privacera Platform
- Example: Create basic policies for table access
- Examples of access control via programming
- Secure S3 via Boto3 in Databricks notebook
- Other Boto3/Pandas examples to secure S3 in Databricks notebook with PrivaceraCloud
- Secure Azure file via Azure SDK in Databricks notebook
- Control access to S3 buckets with AWS Lambda function on PrivaceraCloud or Privacera Platform
- PolicySync design on Privacera Platform
- PolicySync design and configuration
- Relationships: policy repository, connector, and datasource
- PolicySync topologies
- Connector instance directory/file structure
- Required basic PolicySync topology: always at least one connector instance
- Optional topology: multiple connector instances for Kubernetes pods and Docker containers
- Recommended PolicySync topology: individual policy repositories for individual connectors
- Optional encryption of property values
- Preview: AlloyDB connector for PolicySync
- Databricks SQL connector for PolicySync
- Databricks SQL connector properties for PolicySync
- Dremio connector for PolicySync
- Dremio connector properties for PolicySync
- Google BigQuery connector for PolicySync
- BigQuery connector properties for PolicySync
- Microsoft SQL Server connector for PolicySync
- Microsoft SQL connector properties for PolicySync
- PostgreSQL connector for PolicySync
- PostgreSQL connector properties for PolicySync
- Power BI connector for PolicySync
- Power BI connector properties for PolicySync
- Redshift and Redshift Spectrum connector for PolicySync
- Redshift and Redshift Spectrum connector properties for PolicySync
- Snowflake PolicySync prerequisites: users, roles, warehouse, permissions, and UDFs
- Snowflake connector for PolicySync
- Snowflake connector properties for PolicySync
- Migration to PolicySync v2 on Privacera Platform 7.2
- PolicySync design and configuration
- Security zones
- Service Explorer
- Users, groups, and roles
- UserSync
- Add UserSync connectors
- UserSync connector properties on Privacera Platform
- UserSync connector fields on PrivaceraCloud
- UserSync system properties on Privacera Platform
- About Ranger UserSync
- Customize user details on sync
- UserSync integrations
- SCIM Server User-Provisioning on PrivaceraCloud
- Azure Active Directory UserSync integration on Privacera Platform
- LDAP UserSync integration on Privacera Platform
- Portal user management
- Discovery
- Get started with Discovery
- Planning for Privacera Discovery
- Install and Enable Privacera Discovery
- Set up Discovery on Privacera Platform
- Set up Discovery on AWS for Privacera Platform
- Set up Discovery on Azure for Privacera Platform
- Set up Discovery on Databricks for Privacera Platform
- Set up Discovery on GCP for Privacera Platform
- Enable Pkafka for real-time audits in Discovery on Privacera Platform
- Customize topic and table names on Privacera Platform
- Enable Discovery on PrivaceraCloud
- Scan resources
- Supported file formats for Discovery Scans
- Privacera Discovery scan targets
- Processing order of scan techniques
- Register data sources on Privacera Platform
- Data sources on Privacera Platform
- Add a system data source on Privacera Platform
- Add a resource data source on Privacera Platform
- Add AWS S3 application data source on Privacera Platform
- Add Azure ADLS data source on Privacera Platform
- Add Databricks Spark SQL data source on Privacera Platform
- Add Google BigQuery (GBQ) data source on Privacera Platform
- Add JDBC-based systems as data sources for Discovery on Privacera Platform
- Add Google Pub-Sub data source on Privacera Platform
- Add Google Cloud Storage data source on Privacera Platform
- Set up cross-project scanning on Privacera Platform
- Google Pub-Sub Topic message scan on Privacera Platform
- Add and scan resources in a data source
- Start a scan
- Start offline and realtime scans
- Scan Status overview
- Cancel a scan
- Trailing forward slash (/) in data source URLs/URIs
- Configure Discovery scans
- Tags
- Add Tags
- Import Tags
- Add, edit, or delete Tag attributes
- Edit Tag descriptions
- Delete Tags
- Export Tags
- Search for Tags
- Fetch AWS S3 Tags
- Propagate Privacera Discovery Tags to Ranger
- TagSync using Apache Ranger on Privacera Platform
- Add Tags with Ranger REST API
- Dictionaries
- Types of dictionaries
- Dictionary Keys
- Manage dictionaries
- Default dictionaries
- Add a dictionary
- Import a dictionary
- Upload a dictionary
- Enable or disable a dictionary
- Include a Dictionary
- Exclude a dictionary
- Add keywords to an included dictionary
- Edit a dictionary
- Copy a dictionary
- Export a dictionary
- Search for a dictionary
- Test dictionaries
- Dictionary tour
- Patterns
- Models
- Rules
- Configure scans
- Scan setup
- Adjust default scan depth on Privacera Platform
- Classifications using random sampling on PrivaceraCloud
- Enable Discovery Realtime Scanning Using IAM Role on PrivaceraCloud
- Enable Real-time Scanning on ADLS Gen 2 on PrivaceraCloud
- Enable Real-time Scanning of S3 Buckets on PrivaceraCloud
- Connect ADLS Gen2 Application for Data Discovery on PrivaceraCloud
- Include and exclude resources in GCS
- Configure real-time scan across projects in GCP
- Enable offline scanning on ADLS Gen 2 on PrivaceraCloud
- Include and exclude datasets and tables in GBQ
- Google Sink to Pub/Sub
- Tags
- Data Zones on Privacera Platform
- Planing data zones on Privacera Platform
- Data Zone Dashboard
- Enable data zones on Privacera Platform
- Add resources to a data zone on Privacera Platform
- Create a data zone on Privacera Platform
- Edit data zones on Privacera Platform
- Delete data zones on Privacera Platform
- Import data zones on Privacera Platform
- Export data zones on Privacera Platform
- Disable data zones on Privacera Platform
- Create tags for data zones on Privacera Platform
- Data zone movement
- Data zones overview
- Configure data zone policies on Privacera Platform
- Encryption for Right to Privacy (RTP) on Privacera Platform
- Workflow policy use case example
- Define Discovery policies on Privacera Platform
- Disallowed Groups policy
- Disallowed Movement Policy
- Compliance Workflow policies on Privacera Platform
- De-identification policy
- Disallowed Subnets Policy
- Disallowed Subnet Range Policy
- Disallowed Tags policy
- Expunge policy
- Disallowed Users Policy
- Right to Privacy policy
- Workflow Expunge Policy
- Workflow policy
- View scanned resources
- Discovery reports and dashboards
- Alerts Dashboard
- Discovery Dashboard
- Built-in reports
- Offline reports
- Saved Reports
- Reports with the Query Builder
- Discovery Health Check
- Set custom Discovery properties on Privacera Platform
- Get started with Discovery
- Encryption
- Get started with Encryption
- The encryption process
- Encryption architecture and UDF flow
- Install Encryption on Privacera Platform
- Encryption on Privacera Platform deployment specifications
- Configure Ranger KMS with Azure Key Vault on Privacera Platform
- Enable telemetry data collection on Privacera Platform
- AWS S3 bucket encryption on Privacera Platform
- Set up PEG and Cryptography with Ranger KMS on Privacera Platform
- Provide user access to Ranger KMS
- PEG custom properties
- Enable Encryption on PrivaceraCloud
- Encryption keys
- Master Key
- Key Encryption Key (KEK)
- Data Encryption Key (DEK)
- Encrypted Data Encryption Key (EDEK)
- Rollover encryption keys on Privacera Platform
- Connect to Azure Key Vault with a client ID and certificate on Privacera Platform
- Connect to Azure Key Vault with Client ID and Client Secret on Privacera Platform
- Migrate Ranger KMS master key on Privacera Platform
- Ranger KMS with Azure Key Vault on Privacera Platform
- Schemes
- Encryption schemes
- Presentation schemes
- Masking schemes
- Scheme policies
- Formats
- Algorithms
- Scopes
- Deprecated encryption schemes
- About LITERAL
- User-defined functions (UDFs)
- Encryption UDFs for Apache Spark on PrivaceraCloud
- Hive UDFs for encryption on Privacera Platform
- StreamSets Data Collector (SDC) and Privacera Encryption on Privacera Platform
- Trino UDFs for encryption and masking on Privacera Platform
- Privacera Encryption UDFs for Trino
- Prerequisites for installing Privacera crypto plugin for Trino
- Install the Privacera crypto plugin for Trino using Privacera Manager
- privacera.unprotect with optional presentation scheme
- Example queries to verify Privacera-supplied UDFs
- Privacera Encryption UDFs for Trino on PrivaceraCloud
- Syntax of Privacera Encryption UDFs for Trino
- Prerequisites for installing Privacera Crypto plug-in for Trino
- Download and install Privacera Crypto jar
- Set variables in Trino etc/crypto.properties
- Restart Trino to register the Privacera encryption and masking UDFs for Trino
- Example queries to verify Privacera-supplied UDFs
- Privacera Encryption UDF for masking in Trino on PrivaceraCloud
- Databricks UDFs for Encryption
- Create Privacera protect UDF
- Create Privacera unprotect UDF
- Run sample queries in Databricks to verify
- Create a custom path to the crypto properties file in Databricks
- Create and run Databricks UDF for masking
- Privacera Encryption UDF for masking in Databricks on PrivaceraCloud
- Set up Databricks encryption and masking
- Get started with Encryption
- API
- REST API Documentation for Privacera Platform
- Access Control using APIs on Privacera Platform
- UserSync REST endpoints on Privacera Platform
- REST API endpoints for working tags on Privacera Platform
- PEG REST API on Privacera Platform
- API authentication methods on Privacera Platform
- Anatomy of the /protect API endpoint on Privacera Platform
- Construct the datalist for protect
- Deconstruct the datalist for unprotect
- Example of data transformation with /unprotect and presentation scheme
- Example PEG API endpoints
- /unprotect with masking scheme
- REST API response partial success on bulk operations
- Audit details for PEG REST API accesses
- REST API reference
- Make calls on behalf of another user on Privacera Platform
- Troubleshoot REST API Issues on Privacera Platform
- Encryption API date input formats
- Supported day-first date input formats
- Supported month-first date input formats
- Supported year-first date input formats
- Examples of supported date input formats
- Supported date ranges
- Day-first formats
- Date input formats and ranges
- Legend for date input formats
- Year-first formats
- Supported date range
- Month-first formats
- Examples of allowable date input formats
- PEG REST API on PrivaceraCloud
- REST API prerequisites
- Anatomy of a PEG API endpoint on PrivaceraCloud
- About constructing the datalist for /protect
- About deconstructing the response from /unprotect
- Example of data transformation with /unprotect and presentation scheme
- Example PEG REST API endpoints for PrivaceraCloud
- Audit details for PEG REST API accesses
- Make calls on behalf of another user on PrivaceraCloud
- Apache Ranger API on PrivaceraCloud
- API Key on PrivaceraCloud
- Administration and Releases
- Privacera Platform administration
- Change password for Privacera Platform services
- Generate tokens on Privacera Platform
- Validations on Privacera Platform
- Health check on Privacera Platform
- Event notifications for system health
- Export or import a configuration file on Privacera Platform
- Logs on Privacera Platform
- Increase Privacera Platform portal timeout for large requests
- Platform Support Policy and End-of-Support Dates
- Enable Grafana metrics on Privacera Platform
- Create an endpoint in Databricks SQL
- Enable Azure CLI on Privacera Platform
- Migrate from PrestoSQL to Trino
- Ranger Admin properties on Privacera Platform
- Event notifications for system health
- Metrics
- Get ADLS properties
- PrivaceraCloud administration
- About the Account page on PrivaceraCloud
- Statistics on PrivaceraCloud
- PrivaceraCloud dashboard
- Event notifications for system health
- Metrics
- Usage statistics on PrivaceraCloud
- Update PrivaceraCloud account info
- Manage PrivaceraCloud accounts
- Create and manage IP addresses on PrivaceraCloud
- Scripts for AWS CLI or Azure CLI for managing connected applications
- Add UserInfo in S3 Requests sent via Data Access Server on PrivaceraCloud
- Previews
- PrivaceraCloud previews
- Preview: Scan Electronic Health Records with NER Model
- Preview: File Explorer for GCS
- Preview: File Explorer for Azure
- Preview: OneLogin setup for SAML-SSO
- Preview: File Explorer for S3
- Preview: PingFederate UserSync
- Preview: Azure Active Directory SCIM Server UserSync
- Preview: OneLogin UserSync
- Privacera UserSync Configuration
- Databricks Partner Connect - Quickstart for Unity Catalog
- Preview: Governed Data Sharing on PrivaceraCloud
- Overview of Governed Data Sharing on PrivaceraCloud
- Concepts in Governed Data Sharing
- Supported Applications
- Prerequisites and planning
- Additional features
- Applications and database resources
- Granular permissions on resources
- Automatic expiry of access for shared datasets or projects
- At-a-glance dashboards by role
- Optional data steward
- Privacera Discovery scans by admin or data owner
- Optional project leader
- Optional terms of use
- Discoverability of shared datasets
- User request access to datasets
- Notifications
- Overview to examples by role
- Privacera Platform previews
- PrivaceraCloud previews
- Release documentation
- Privacera system security initiatives
- Privacera Platform administration
PolicySync design and configuration
To help you reach compliance, Privacera PolicySync distributes your defined access management policies to the third-party datasources you connect to Privacera.
Policies are created in Privacera at Access Management > Resource Policies or Access Management > Tag Policies in policy repositories:
![]() |
Some of the characteristics of a PolicySync connector are:
Authentication to connect to the third-party system, such as JDBC URL, username, and password,
Polling intervals for syncing policies or auditing and other network-related characteristics.
Multiple instances of a connector to distribute work across Kubernetes pods and Docker containers.
Relationships: policy repository, connector, and datasource
The mechanics of PolicySync involve a Privacera connector with its Privacera policy repository to distribute your defined policies from that repository to a third-party datasource:
An internal-to-Privacera policy repository stores the access management policies you create via the Privacera UI at Access Management > Resource Policies. These are the policies distributed by the connector to the datasource.
An internal-to-Privacera instance of a connector to that third-party system is configured by YAML files on Privacera Platform that contain properties or fields in PrivaceraCloud. Properties and fields are name/value pairs to set various features or characteristics of the connector and third-party system.
An external-to-Privacera instance of a third-party application's database or file or other object is called a datasource. This is your application.
PolicySync topologies
Connector instances, policy repository instances, and datasource instances can be configured in various topologies.
Required basic PolicySync topology
The default, basic, required topology is a single connector instance, a single policy repository, a single third-party system datasource.
![]() |
Creating this basic topology is detailed in Required basic PolicySync topology: always at least one connector instance.
PolicySync topology: multiple connectors and datasources, single policy repository
An alternative to the basic topology is a single Privacera policy repository with multiple Privacera connector instances to distribute the same policies to several different datasources.
![]() |
Creating this configuration is detailed in Optional topology: multiple connector instances for Kubernetes pods and Docker containers.
PolicySync topology: unique connectors, datasources, and policy repositories
The optimal topology is one connector instance with one policy repository instance for a single datasource instance.
For distinct access management policies for distinct organizational groups that require distinct access rights, Privacera recommends the PolicySync topology of a separate, unique policy repository for each connector instance and its associated datasource instance.
![]() |
Creating this configuration is detailed in Recommended PolicySync topology: individual policy repositories for individual connectors
Connector instance directory/file structure
PolicySync works with configured connector instances for each instance of the third-party system datasource you want to manage.
You configure connectors in the following directories in Privacera Manager, with a YAML properties file for each instance of the connector:
~/privacera/privacera-manager/config/custom-vars/connectors/<ConnectorName>/<someInstanceName>/vars.connector.<ConnectorName>.yml
where the following sections define this syntax.
Directory naming conventions for PolicySync
~/privacera/privacera-manager/config/custom-vars/connectors/
is the base directory for all connector instances.
<ConnectorName>
is a subdirectory with the lowercase, reserved-word name of a third-party system to connect to, such as databricks-sql-analytics
, postgres
, or mssql
.
These names are reserved words defined by Privacera for each supported third-party system detailed in the PolicySync documentation for each.
biquery
for Google BigQuery.databricks-sql-analytics
for Databricks SQL.dremio
for Dremio.mssql
for Microsoft SQL Server.postgres
for PostgreSQL on several different platforms.powerbi
for Power BI.redshift
for Redshift and Redshift Spectrum connector for PolicySyncsnowflake
for Snowflake.
<someInstanceName>
is a subdirectory whose name you create to indicate a single instance of a connector for the third-party datasource.
<someInstanceName>
must be composed of only alphanumeric characters and hyphens.
For example, suppose you have three different Kubernetes pods for three different instances of PostgreSQL. Let's name the <someInstanceName>
subdirectories for these instances as follows:
postgres-dev-instance
for Software Development.postgres-qa-instance
for Quality Assurance.postgres-prod-instance
for Production.
YAML file with connector-specific properties
vars.connector.<ConnectorName>.yml
is a YAML file of name-value pairs you complete for a connector instance, including authentication, features, and other details.
These property names are defined by Privacera for each third-party system and are detailed in the PolicySync documentation for each.
vars.connector.bigquery.yml
: see BigQuery connector properties for PolicySync.vars.connector.databricks.sql.analytics.yml
: see Databricks SQL connector properties for PolicySync.vars.connector.dremio.yml
: see Dremio connector properties for PolicySync.vars.connector.mssql.yml
: see Microsoft SQL connector properties for PolicySync.vars.connector.postgres.yml
: see PostgreSQL connector properties for PolicySync.vars.connector.powerbi.yml
: see Power BI connector properties for PolicySync.vars.connector.redshift.yml
: see Redshift and Redshift Spectrum connector properties for PolicySync.vars.connector.snowflake.yml
: see Snowflake connector properties for PolicySync.
Required basic PolicySync topology: always at least one connector instance
For each third-party system datasource, you must always create at least one PolicySync connector instance with the directory structure and file naming described in Connector instance directory/file structure.
For example, suppose you have a single instance of PostgreSQL in production. Let's call this instance postgres-prod-instance
.
Follow these steps to create the PolicySync configuration for it.
cd ~/privacera/privacera-manager # # Make the connector subdirectory # for the PostgreSQL production instance # called postgres-prod-instance mkdir -p config/custom-vars/connectors/postgres/postgres-prod-instance # # Copy the template PostgreSQL connector properties .yml file # to the postgres-prod-instance subdirectory # for the production instance cp config/sample-vars/vars.connector.postgres.yml \ config/custom-vars/connectors/postgres/postgres-prod-instance # # Set the values of the properties in the YAML file # called vars.connector.postgres.yml # for this example postgres-prod-instance instance # # Properties are defined in the documentation # for each of the individual third-party systems. # vi config/custom-vars/connectors/postgres/postgres-prod-instance/vars.connector.postgres.yml # # Save the file # # Update the running configuration ./privacera-manager.sh update
Note
Every time you save changes to a configuration file, you must run privacera-manager.sh update
to apply those changes to the running configuration.
Optional topology: multiple connector instances for Kubernetes pods and Docker containers
Suppose you have three different Kubernetes pods for three different instances of PostgreSQL databases. Let's name the subdirectories for these instances as follows:
postgres-dev-instance
for Software Development.postgres-qa-instance
for Quality Assurance.postgres-prod-instance
for Production.
For each connector instance, create the directory/file structure following the details in Required basic PolicySync topology: always at least one connector instance and define the PolicySync properties for each instance in its vars.connector.<ConnectorName>.yml
YAML file.
You will have a directory structure like this:
cd ~/privacera/privacera-manager ls -R config/custom-vars/connectors config/custom-vars/connectors/postgres: postgres-dev-instance postgres-prod-instance postgres-qa-instance config/custom-vars/connectors/postgres/postgres-dev-instance: vars.connector.postgres.yml config/custom-vars/connectors/postgres/postgres-prod-instance: vars.connector.postgres.yml config/custom-vars/connectors/postgres/postgres-qa-instance: vars.connector.postgres.yml
Recommended PolicySync topology: individual policy repositories for individual connectors
By default, when you configure multiple connectors, policies are stored in the connector's default single PolicySync policy repository. But you can define an individual policy repository for each individual connector instance and datasource instance.
For distinct access management policies for distinct organizational groups that require distinct access rights, Privacera recommends the PolicySync topology of a separate, unique policy repository for each connector instance and its associated datasource instance.
When you configure a connector's first instance, the following properties for the policy repository are added to your connector instance's YAML file, in this example, ~/privacera/privacera-manager/config/custom-vars/connectors/postgres/postgres-prod-instance/vars.connector.postgres.yml
.
Any new connector instances share that same single, common policy repository. The example below shows this shared repository: privacera_postgres
.
ranger.policysync.connector.0.ranger.service.name=privacera_postgres ranger.policysync.connector.0.ranger.service.appid=privacera_postgres
Setting up individual repositories per connector is a two-step process:
In Privacera, go to Access Management > Resource Policies, create the individual repositories for the planned connectors.
Set up the per-connector properties to point to the individual policy repositories.
Prerequisites
Make sure you have the following details ready:
Decide which connector to a third-party datasource to create the unique policy repository for. In this example, we work with PostgreSQL.
Decide names for the policy repository instances that correspond to the connector instances and their datasources.
Use
privacera_
as a prefix for the repository instance to help distinguish the repository instance from the connector instance it is associated with.In this example, we decide to use the connector instance names we have already defined, each with the
privacera_
prefix:privacera_postgres_dev_instance
for Software Development.privacera_postgres_qa_instance
for Quality Assurance.privacera_postgres_prod_instance
for Production.
Be sure to have created at least one connector for the third-party system datasource, as detailed in Required basic PolicySync topology: always at least one connector instance.
Create policy repository for each connector instance in Privacera Access Management
In this example, create the privacera_postgres_prod_instance
. policy repository.
As administrator, go to Access Management > Resource Policies.
Locate the third-party connector already available. In this example, the single shared repository for PostgreSQL is shown:
From the three vertical dots on the upper right, select Add Service:
Enter the Service Name. Follow your naming convention described in 2. In this example,
privacera_postgres_prod_instance
.Under Select Tag Service, choose
privacera_tag
.Click Save.
The new repository has been created.
Repeat these steps for as many other policy repositories you want.
In this example, the three separate repositories are ready:
![]() |
Configuring properties to point to individual policy repositories
When you create other connector instances, each points to the single common repository.
To define a separate unique repository, for each connector instance, create a connector-custom.properties
file to replace the name of the shared repository with the name of the unique repository.
The connector-custom.properties
file must be in the same directory as the connector instance's YAML file, as described in Connector instance directory/file structure.
~/privacera/privacera-manager/config/custom-vars/connectors/<ConnectorName>/custom/connector-custom.properties
Following the examples in this discussion, for each connector instance, specify the name of instance's policy repository on the following lines in connector-custom.properties
:
Connector instance for Software Development:
custom-vars/connectors/postgres/postgres-dev-instance/custom/connector-custom.properties
:ranger.policysync.connector.0.ranger.service.name=privacera_postgres_dev_instance ranger.policysync.connector.0.ranger.service.appid=privacera_postgres_dev_instance
Connector instance for Quality Assurance:
custom-vars/connectors/postgres/postgres-qa-instance/custom/connector-custom.properties
:ranger.policysync.connector.0.ranger.service.name=privacera_postgres_qa_instance ranger.policysync.connector.0.ranger.service.appid=privacera_postgres_qa_instance
Connector instance for Production:
custom-vars/connectors/postgres/postgres-prod-instance/custom/connector-custom.properties
:ranger.policysync.connector.0.ranger.service.name=privacera_postgres_prod_instance ranger.policysync.connector.0.ranger.service.appid=privacera_postgres_prod_instance
These three separate connector instances are now associated with their respective policy repositories viewable at Access Management > Resource Policies or Access Management > Tag Policies.
Optional encryption of property values
To protect sensitive values in your YAML files, PolicySync can encrypt them.
To encrypt property values, create the following file and specify the property names whose values to encrypt:
~/privacera/privacera-manager/config/custom-vars/vars.encrypt.secrets.ymlThe contents of
vars.encrypt.secrets.yml
must look like this:CONNECTOR_ENCRYPT_PROPS_LIST: - <PROPERTY_NAME1> - <PROPERTY_NAME2> - <PROPERTY_NAME3>
where:
CONNECTOR_ENCRYPT_PROPS_LIST:
is exactly as shown.The indented
<PROPERTY_NAME1>
,<PROPERTY_NAME2>
, and<PROPERTY_NAME3>
are names of connector properties whose values to encrypt.The property names can be for any connector.
There is no limit to the number of property names you can specify.
Example: In the following example, the file ~/privacera/privacera-manager/config/custom-vars/vars.encrypt.secrets.yml
specifies encryption of the PostgreSQL connector's property values of JDBC username, JDBC password, and JDBC database and the Google BigQuery connector's property values of JDBC URL and organization ID:
CONNECTOR_ENCRYPT_PROPS_LIST: - CONNECTOR_POSTGRES_JDBC_USERNAME - CONNECTOR_POSTGRES_JDBC_PASSWORD - CONNECTOR_POSTGRES_JDBC_DB - CONNECTOR_BIGQUERY_JDBC_URL - CONNECTOR_BIGQUERY_ORGANIZATION_ID
Because AlloyDB works with PostgreSQL on Google Cloud Platform, see the following documentation:
This topic shows how to configure access control for Databricks SQL.
Generalized approach for implementing PolicySync
To help you reach compliance, Privacera PolicySync distributes your defined access management policies to the third-party datasources you connect to Privacera.
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: databricks-sql-analytics
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
databricks-sql-analytics
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above and in the example in Required basic PolicySync topology: always at least one connector instance, replace postgres
with the above.
Prerequisites
Ensure the following prerequisites are met:
Create an SQL warehouse in Databricks SQL with a user having admin privileges. For more information, see Databricks documentation.
As you configure the warehouse make a note of the following values, which you to specify in the PolicySync properties for Databricks SQL :
Host URL
JDBC URL
SQL endpoint token
Database List
These Databricks SQL connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC fields described here and then examine the ADVANCED fields to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default | Allowable values |
JDBC configuration properties | ||||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_JDBC_URL | This property is used to set jdbc jdbc url which can be used to connect to databricks sql endpoint. JDBC URL should follow below convention jdbc:spark://<WORKSPACE_URL>:443/<DATABASE>;transportMode=http;ssl=1;AuthMech=3;httpPath=/sql/1.0/endpoints/1234567890 Example :- jdbc:spark://example.cloud.databricks.com:443/default;transportMode=http;ssl=1;AuthMech=3;httpPath=/sql/1.0/endpoints/1234567890 | ||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_JDBC_USERNAME | This property is used to set jdbc Username to be used to make connection to databricks sql endpoint. This is just an email used to log in to Databricks to manage the SQL endpoint. (ex. eric.yuan@privacera.com) | ||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_JDBC_PASSWORD | This is a personal access token used to access the databricks sql endpoint, that is created in Databricks by going to SQL endpoints and then "Create a personal access token". It should look like this: dapi71f8493d87bce9847d09e17a10ba8d53 | ||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_JDBC_DB | This property is used to set jdbc database to be used to make initial connection to databricks sql endpoint. | ||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_OWNER_ROLE | This property is used to set ownership for all the resources managed by policysync. The specified user will become owner for all managed resources and will have full control on those resources.We support changing owners of database, tables and views. Note :- If owner role is kept as blank, then ownership will not change and users who creates tables/views or any other object will be the owner of those objects and policysync won't be able to do access control on that object | ||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_HOST_URL | This property is used to make a call to SQL analytics API for users/groups/audits. It should simply be the base url of Databricks, for example https://db1.cloud.databricks.com/ | ||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_DEFAULT_USER_PASSWORD | This property is used to set password which will be used for every new user creation by policysync. | ||
Resources management | ||||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_DATABASE_LIST | This property is used to set comma separated database names which access control should be managed by policysync. If you want to manage all databases then you can skip specifying this property. This supports wildcards as well. The ignore database list has precedence over manage database list. Eg. testdb1,testdb2,sales_db* **NOTE: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_TABLE_LIST | This property is used to set comma separated table/view Fqdn which access control should be managed by policysync. If you want to manage all tables/views then you can skip specifying this property. This supports wildcards as well. The ignore table list has precedence over manage table list. Eg. testdb1.schema1.table1,testdb2.schema2.view2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_IGNORE_DATABASE_LIST | This property is used to set comma separated database names which access control you don't want to be managed by policysync. If you don't want to ignore any database then you can skip specifying this property. This supports wildcards as well. This has precedence over manage database list. Eg. testdb1,testdb2,sales_db* **NOTE: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_IGNORE_TABLE_LIST | This property is used to set comma separated table/view Fqdn which access control you don't want to be managed by policysync. If you don't want to ignore any tables/views then you can skip specifying this property. This supports wildcards as well. This has precedence over manage table list. Eg. testdb1.schema1.table1,testdb2.schema2.view2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | ||
Users/Groups/Roles management | ||||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_USER_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_USER_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_GROUP_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a group name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_GROUP_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified group name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_ROLE_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a role name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_ROLE_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified role name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_USER_NAME_PERSIST_CASE_SENSITIVITY | After loading user from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_GROUP_NAME_PERSIST_CASE_SENSITIVITY | After loading group from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_ROLE_NAME_PERSIST_CASE_SENSITIVITY | After loading role from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_CREATE_USER | This property controls whether we should create user in databricks sql endpoint for users fetched from ranger. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_USERS | This property controls whether we should create role in databricks sql endpoint for users fetched from ranger. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_DELETE_USERS | When this property is set to true, PolicySync will delete users in Databricks when they are deleted in Portal. The property is set to false by default, as deleting users in Databricks wipes out their access tokens and other info. | false | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_GROUPS | This property controls whether we should create role in databricks sql endpoint for groups fetched from ranger. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_ROLES | This property controls whether we should create role in databricks sql endpoint for roles fetched from ranger. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_USER_LIST | This property is used to set comma separated user names which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_GROUP_LIST | This property is used to set comma separated group names which access control should be managed by policysync. If you want to manage all group then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedence over manage group list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_ROLE_LIST | This property is used to set comma separated role names which access control should be managed by policysync. If you want to manage all role then you can skip specifying this property. This supports wildcards as well. The ignore role list has precedence over manage role list. Eg. role1,role2,dev_role* | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_IGNORE_USER_LIST | This property is used to set comma separated user names which access control you don't want to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_IGNORE_GROUP_LIST | This property is used to set comma separated group names which access control you don't want to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedence over manage groups list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_IGNORE_ROLE_LIST | This property is used to set comma separated role names which access control you don't want to be managed by policysync. If you don't want to ignore any roles then you can skip specifying this property. This supports wildcards as well. This has precedence over manage roles list. Eg. role1,role2,dev_role* | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_GROUP_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in databricks sql endpoint for group from ranger. For example if you have group named dev in ranger and you have defined prefix as test_group_ then the role which we create for dev in databricks sql endpoint will have name test_group_dev. NOTE: This property does not exist for users because users are using emails instead of usernames to log in. | priv_group_ | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_ROLE_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in databricks sql endpoint for role from ranger. For example if you have role named finance in ranger and you have defined prefix as test_role_ then the role which we create for finance in databricks sql endpoint will have name test_role_finance. NOTE: This property does not exist for users because users are using emails instead of usernames to log in. | priv_role_ | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_USE_NATIVE_PUBLIC_GROUP | Set this property to true, if you want PolicySync to use the "public" group in databricks for access grants whenever there is policy created referring to public group inside it. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belongs to the groups defined in manage groups list property. | false | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MANAGE_USER_FILTERBY_ROLE | Set this property to true, if you want to manage only the users who belongs to the roles defined in manage roles list property. | false | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_USER_USE_EMAIL_AS_SERVICE_NAME | This Property is used to map the username as email address while grant/revoke | true | |
Access control management | ||||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_ENABLE_VIEW_BASED_MASKING | Set this property to true, if you want to enable secure view based masking in databricks policysync. Note :- Databricks does not support native masking, so it is recommended to use view based masking. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_ENABLE_VIEW_BASED_ROW_FILTER | Set this property to true, if you want to enable secure view based tr filter in databricks policysync. Note :- Databricks does not support native tr filters,so it is recommended to use view based tr filters. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_SECURE_VIEW_CREATE_FOR_ALL | Set this property to true, if you want to create secure view for all tables as well all view which were created by end users. This will create secure view for resource regardless whether there any masking/tr filter policy exists in ranger. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MASKED_NUMBER_VALUE | This property is used to specify the default masking value for numeric columns | 0 | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_MASKED_TEXT_VALUE | This property is used to specify the default masking value for text/string columns | <MASKED>' | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_SECURE_VIEW_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_SECURE_VIEW_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_SECURE_VIEW_DATABASE_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same schema name as the table database name. If you want to change the secure view database name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view database name will be in this format : {prefix}{view_database_name}{postfix} | ||
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_SECURE_VIEW_DATABASE_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same database name as the table database name. If you want to change the secure view database name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view database name will be in this format : {prefix}{view_database_name}{postfix} | _secure | |
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_GRANT_UPDATES | This property controls whether actual grant/revoke and create/update/delete queries for user/group/role should be run on databricks sql endpoint. | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_ENABLE_DATA_ADMIN | This property is used to enable data admin feature, with data admin feature enabled you can create all the policies on table/native view and by default respective grants will be made on secure view of table table or native view. And this secure view will have tr filter and masking capability as well. In case if you need permission on table then you can select the permission you want plus dataadmin in the policy, In this case that permissions will be granted on both, the table/native view and its secure view as well | true | |
Access audits management | ||||
BASIC | CONNECTOR_DATABRICKS_SQL_ANALYTICS_AUDIT_ENABLE | This property is used to enable access audit fetching from databricks sql endpoint | true | |
ADVANCED | CONNECTOR_DATABRICKS_SQL_ANALYTICS_AUDIT_EXCLUDED_USERS | This property is used to exclude the users while pushing the audits logs to ranger access audits. Recommended to set this as JDBC user name as there will be audits from policysync application. | {{DATABRICKS_SQL_ANALYTICS_JDBC_USERNAME}} |
This topic shows how to configure access control for Dremio
Generalized approach for implementing PolicySync
To help you reach compliance, Privacera PolicySync distributes your defined access management policies to the third-party datasources you connect to Privacera.
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: dremio
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
dremio
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above and in the example in Required basic PolicySync topology: always at least one connector instance, replace postgres
with the above.
These Dremio connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC properties and then examine the ADVANCED properties to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default |
JDBC configuration properties | |||
BASIC | CONNECTOR_DREMIO_JDBC_URL | This property is used to set JDBC url which can be used to create a direct connection to a Dremio coordinator node. JDBC URL should follow below convention jdbc:dremio:direct=<DREMIO_COORDINATOR>:31010 Example :- jdbc:dremio:direct=example-12345fg.us-east-1.elb.amazonaws.com:31010 | |
BASIC | CONNECTOR_DREMIO_JDBC_USERNAME | This property is used to set JDBC Username to be used to make connection to Dremio coordinator. This is just an username used to log in to Dremio to manage the Authorization. (ex. adminUser) | |
BASIC | CONNECTOR_DREMIO_JDBC_PASSWORD | This property is used to set JDBC user's password to be used to make connection to Dremio coordinator. | |
BASIC | CONNECTOR_DREMIO_OWNER_ROLE | This property is used to set ownership for all the resources managed by policysync. The specified user will become owner for all managed resources and will have full control on those resources. We support changing owners of source, space, source folders, space folders, physical datasets and virtual datasets. Note :- If owner role is kept as blank, then ownership will not change and users who creates resources or any other object will be the owner of those objects and policysync won't be able to do access control on that objects. | |
BASIC | CONNECTOR_DREMIO_URL | This property is used to make a call to Dremio API for catalogs/users/groups/audits. For example https://internal-dummy.us-east-1.elb.amazonaws.com:9047 | |
BASIC | CONNECTOR_DREMIO_DEFAULT_USER_PASSWORD | This property is used to set password which will be used as default password for every new user created by policysync. | |
Resources management | |||
BASIC | CONNECTOR_DREMIO_MANAGE_SPACE_LIST | This property is used to set comma separated space names for which access control should be managed by policysync. If you want to manage all spaces then you can skip specifying this property. This supports wildcards as well. The ignore space list has precedence over manage space list. Eg. testspace1,testspace2,space* Note :- values for this property are case-sensitive. | |
BASIC | CONNECTOR_DREMIO_MANAGE_SOURCE_LIST | This property is used to set comma separated source names which access control should be managed by policysync. If you want to manage all sources then you can skip specifying this property. This supports wildcards as well. The ignore source list has precedence over manage source list. Eg. testsource1,testsource2,source* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_SOURCE_FOLDER_LIST | This property is used to set comma separated source folder for which access control should be managed by policysync. If you want to manage all source folder then you can skip specifying this property. This supports wildcards as well. The ignore source folder list has precedence over manage source folder list. Eg. source.sourcefolder,source*.sales* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_SPACE_FOLDER_LIST | This property is used to set comma separated space folder for which access control should be managed by policysync. If you want to manage all space folders then you can skip specifying this property. This supports wildcards as well. The ignore space folder list has precedence over manage space folder list. Eg. space.spacefolder,space*.sales* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_PHYSICAL_DATASET_LIST | This property is used to set comma separated physical datasets for which access control should be managed by policysync. If you want to manage all physical datasets then you can skip specifying this property. This supports wildcards as well. The ignore physical dataset list has precedence over manage physical dataset list. Eg. source.folder1.physicaldataset,source*.sales*.* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_VIRTUAL_DATASET_LIST | This property is used to set comma separated virtual datasets for which access control should be managed by policysync. If you want to manage all virtual datasets then you can skip specifying this property. This supports wildcards as well. The ignore virtual dataset list has precedence over manage virtual dataset list. Eg. space.folder1.virtualdataset,space*.sales*.* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_SOURCE_LIST | This property is used to set comma separated source names for which you don't want access control to be managed by policysync. If you don't want to ignore any source then you can skip specifying this property. This supports wildcards as well. This has precedence over manage source list. Eg. testsource,sales* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_SPACE_LIST | This property is used to set comma separated space names for which you don't want access control to be managed by policysync. If you don't want to ignore any space then you can skip specifying this property. This supports wildcards as well. This has precedence over manage space list. Eg. testspace,sales* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_SOURCE_FOLDER_LIST | This property is used to set comma separated source folder names for which you don't want access control to be managed by policysync. If you don't want to ignore any source folder then you can skip specifying this property. This supports wildcards as well. This has precedence over manage source folder list. Eg. source.sourcefolder,source*.sales* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_SPACE_FOLDER_LIST | This property is used to set comma separated space folder names for which you don't want access control to be managed by policysync. If you don't want to ignore any space folder then you can skip specifying this property. This supports wildcards as well. This has precedence over manage space folder list. Eg. space.spacefolder,space*.sales* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_PHYSICAL_DATASET_LIST | This property is used to set comma separated physical dataset names for which you don't want access control to be managed by policysync. If you don't want to ignore any physical dataset then you can skip specifying this property. This supports wildcards as well. This has precedence over manage physical dataset list. Eg. source.folder1.physicaldataset,source*.sales*.* Note :- values for this property are case-sensitive. | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_VIRTUAL_DATASET_LIST | This property is used to set comma separated virtual dataset names for which you don't want access control to be managed by policysync. If you don't want to ignore any virtual dataset then you can skip specifying this property. This supports wildcards as well. This has precedence over manage virtual dataset list. Eg. source.folder1.virtualdataset,source*.sales*.* Note :- values for this property are case-sensitive. | |
Users/Groups/Roles management | |||
ADVANCED | CONNECTOR_DREMIO_USER_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.\\\\s^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] |
ADVANCED | CONNECTOR_DREMIO_USER_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | _ |
ADVANCED | CONNECTOR_DREMIO_GROUP_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a group name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.\\\\s^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] |
ADVANCED | CONNECTOR_DREMIO_GROUP_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified group name regex property. If kept blank, no find and replace operation is performed. | _ |
ADVANCED | CONNECTOR_DREMIO_ROLE_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a role name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.\\\\s^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] |
ADVANCED | CONNECTOR_DREMIO_ROLE_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified role name regex property. If kept blank, no find and replace operation is performed. | _ |
ADVANCED | CONNECTOR_DREMIO_USER_NAME_PERSIST_CASE_SENSITIVITY | After loading user from Ranger API's all users are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false |
ADVANCED | CONNECTOR_DREMIO_GROUP_NAME_PERSIST_CASE_SENSITIVITY | After loading group from Ranger API's all groups are converted into lowercase, but in some cases, you would need to have the groups in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false |
ADVANCED | CONNECTOR_DREMIO_ROLE_NAME_PERSIST_CASE_SENSITIVITY | After loading role from Ranger API's all roles are converted into lowercase, but in some cases, you would need to have the roles in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false |
CONNECTOR_DREMIO_USER_NAME_CASE_CONVERSION | This property only applicable if USER NAME PERSIST CASE SENSITIVITY is set to false. Managed users name would be treated as lowercase by default. If the value is set to "upper" then the user name would be treated as uppercase. If the value is set to "none" then the user name case is preserved as present in ranger. | lower | |
ADVANCED | CONNECTOR_DREMIO_CREATE_USER | This property controls whether we should create user in dremio for users fetched from ranger. | true |
ADVANCED | CONNECTOR_DREMIO_CREATE_USER_ROLE | This property controls whether we should create role over the end user in dremio for users fetched from ranger. | true |
ADVANCED | CONNECTOR_DREMIO_MANAGE_USERS | This property controls whether we should create role in dremio for users fetched from ranger. | true |
ADVANCED | CONNECTOR_DREMIO_MANAGE_GROUPS | This property controls whether we should create role in dremio for groups fetched from ranger. | true |
CUTSTOM | CONNECTOR_DREMIO_MANAGE_GROUP_MEMBERS | true | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_ROLES | This property controls whether we should create role in dremio for roles fetched from ranger. | true |
CUTSTOM | CONNECTOR_DREMIO_MANAGE_GROUP_MEMBERS | true | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_USER_LIST | This property is used to set comma separated user names which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedence over manage users list. Eg. user1,user2,dev_user* | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_GROUP_LIST | This property is used to set comma separated group names which access control should be managed by policysync. If you want to manage all group then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedence over manage group list. Eg. group1,group2,dev_group* | |
ADVANCED | CONNECTOR_DREMIO_MANAGE_ROLE_LIST | This property is used to set comma separated role names which access control should be managed by policysync. If you want to manage all role then you can skip specifying this property. This supports wildcards as well. The ignore role list has precedence over manage role list. Eg. role1,role2,dev_role* | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_USER_LIST | This property is used to set comma separated user names which access control you don't want to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedence over manage users list. Eg. user1,user2,dev_user* | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_GROUP_LIST | This property is used to set comma separated group names which access control you don't want to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedence over manage groups list. Eg. group1,group2,dev_group* | |
ADVANCED | CONNECTOR_DREMIO_IGNORE_ROLE_LIST | This property is used to set comma separated role names which access control you don't want to be managed by policysync. If you don't want to ignore any roles then you can skip specifying this property. This supports wildcards as well. This has precedence over manage roles list. Eg. role1,role2,dev_role* | |
ADVANCED | CONNECTOR_DREMIO_USER_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in Dremio for user from ranger. For example if you have user named john in ranger and you have defined prefix as test_user_ then the role which we create for john in Dremio will have name test_user_john | priv_user_ |
ADVANCED | CONNECTOR_DREMIO_GROUP_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in Dremio for group from ranger. For example if you have group named dev in ranger and you have defined prefix as test_group_ then the role which we create for dev in Dremio will have name test_group_dev. | priv_group_ |
ADVANCED | CONNECTOR_DREMIO_ROLE_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in Dremio for role from ranger. For example if you have role named finance in ranger and you have defined prefix as test_role_ then the role which we create for finance in Dremio will have name test_role_finance. | priv_role_ |
ADVANCED | CONNECTOR_DREMIO_USE_NATIVE_PUBLIC_GROUP | Set this property to true, if you want policysync to use the "public" group from Dremio for access grants whenever there is policy created referring to public group inside it. | true |
ADVANCED | CONNECTOR_DREMIO_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belongs the the groups defined in manage groups list property. | false |
ADVANCED | CONNECTOR_DREMIO_MANAGE_USER_FILTERBY_ROLE | Set this property to true, if you want to manage only the users who belongs the the roles defined in manage roles list property. | false |
Access control management | |||
ADVANCED | CONNECTOR_DREMIO_ENABLE_VIEW_BASED_MASKING | Set this property to true, if you want to enable secure view based masking in Dremio policysync. | false |
ADVANCED | CONNECTOR_DREMIO_ENABLE_VIEW_BASED_ROW_FILTER | Set this property to true, if you want to enable secure view based tr filter in Dremio policysync. | false |
ADVANCED | CONNECTOR_DREMIO_SECURE_VIEW_CREATE_FOR_ALL | Set this property to true, if you want to create secure view for all datasets which were created by end users. This will create secure view for datasets regardless whether there any masking/tr filter policy exists in ranger. | false |
ADVANCED | CONNECTOR_DREMIO_ENABLE_ROW_FILTER | This property controls whether to enable native tr filter policy creation functionality in policysync. | true |
ADVANCED | CONNECTOR_DREMIO_ENABLE_MASKING | This property controls whether to enable native masking policy creation functionality in policysync. | true |
ADVANCED | CONNECTOR_DREMIO_MASKED_NUMBER_VALUE | This property is used to specify the default masking value for numeric columns | 0 |
ADVANCED | CONNECTOR_DREMIO_MASKED_DOUBLE_VALUE | This property is used to specify the default masking value for double datatype columns | 0 |
ADVANCED | CONNECTOR_DREMIO_MASKED_TEXT_VALUE | This property is used to specify the default masking value for text/string columns | <MASKED>' |
ADVANCED | CONNECTOR_DREMIO_SECURE_SPACE_PREFIX | By default view-based tr filter and masking related secure views have the same space name as the table/view source/space name. If you want to change the secure view space name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view space name will be in this format : {prefix}{view_space_name}{postfix} | |
ADVANCED | CONNECTOR_DREMIO_SECURE_SPACE_POSTFIX | By default view-based tr filter and masking related secure views have the same space name as the table/view source/space name. If you want to change the secure view space name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view space name will be in this format : {prefix}{view_space_name}{postfix} | _secure |
BASIC | CONNECTOR_DREMIO_GRANT_UPDATES | This property controls whether actual grant/revoke and create/update/delete queries for user/group/role should be run on Dremio. | true |
ADVANCED | CONNECTOR_DREMIO_ENABLE_DATA_ADMIN | This property is used to enable data admin feature, with data admin feature enabled you can create all the policies on table/native view and by default perspective grants will be maid on secure view of table table or native view. And this secure view will have tr filter and masking capability as well. In case if you need permission on table then you can select the permission you want plus DataAdmin in the policy, In this case that permissions will be granted on both, the table/native view and its secure view as well. | false |
Access audits management | |||
BASIC | CONNECTOR_DREMIO_AUDIT_ENABLE | This property is used to enable access audit fetching from Dremio. | true |
ADVANCED | CONNECTOR_DREMIO_AUDIT_EXCLUDED_USERS | This property is used to exclude the users while pushing the audits logs to ranger access audits. Recommended to set this as JDBC user name as there will be audits from policysync application. | {{DREMIO_JDBC_USERNAME}} |
Google BigQuery provides fine-grained access control on datasets. This includes:
Table-level Access Control
Column-level Access Control
Native/Dynamic secure view-based Row Filter
Masking With Dynamic secure views created using PolicySync
Generalized approach for implementing PolicySync
To help you reach compliance, Privacera PolicySync distributes your defined access management policies to the third-party datasources you connect to Privacera.
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: bigquery
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
bigquery
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above and in the example in Required basic PolicySync topology: always at least one connector instance, replace postgres
with the above.
Prerequisites
Create PrivaceraPolicySyncRole IAM Role
You need to give Privacera PolicySync basic access to GCP. To grant that access, create PrivaceraPolicySyncRole
IAM role in your GCP project or GCP organization using the following commands on Google Cloud's shell (gcloud). The shell can be installed and accessed locally or through Google Console.
Run the following command to create the file containing the permissions required for the PrivaceraPolicySyncRole
role:
ROLE_NAME="PrivaceraPolicySyncRole" cat << EOF > ${ROLE_NAME}.yaml title: "${ROLE_NAME}" description: "${ROLE_NAME}" stage: "ALPHA" includedPermissions: - resourcemanager.projects.get - resourcemanager.projects.getIamPolicy - resourcemanager.projects.setIamPolicy - iam.roles.list - iam.roles.get - iam.roles.create - iam.roles.update - bigquery.jobs.create - bigquery.datasets.get - bigquery.datasets.create - bigquery.datasets.update - bigquery.datasets.delete - bigquery.datasets.getIamPolicy - bigquery.datasets.setIamPolicy - bigquery.tables.list - bigquery.tables.get - bigquery.tables.getData - bigquery.tables.create - bigquery.tables.update - bigquery.tables.delete - bigquery.tables.getIamPolicy - bigquery.tables.setIamPolicy - bigquery.rowAccessPolicies.list - bigquery.rowAccessPolicies.create - bigquery.rowAccessPolicies.update - bigquery.rowAccessPolicies.delete - bigquery.rowAccessPolicies.getIamPolicy - bigquery.rowAccessPolicies.setIamPolicy EOF
GCP Project-level access
Note
If you have multiple projects in your GCP organization and want them to be managed by a single BigQuery connector, then repeat the steps below for each project. Assign the role to the same service account which will be used across multiple projects.
Run the following command. Replace
<GCP_PROJECT_ID>
with your GCP project ID.PROJECT_ID="<GCP_PROJECT_ID>"
To create
PrivaceraPolicySyncRole
role in your GCP project, run the following command.gcloud iam roles create ${ROLE_NAME} --project=${PROJECT_ID} --file=${ROLE_NAME}.yaml
GCP Organization-level access
Run the following command. Replace
<GCP_ORGANIZATION_ID>
with your GCP organization ID.ORGANIZATION_ID="<GCP_ORGANIZATION_ID>"
To create
PrivaceraPolicySyncRole
role in your GCP organization, run the following command.gcloud iam roles create ${ROLE_NAME} --organization=${ORGANIZATION_ID} --file=${ROLE_NAME}.yaml
Attach IAM Role to Service Account
To attach the PrivaceraPolicySyncRole
IAM role created above, do the following steps:
Log in to your GCP console.
Select IAM & admin > Service accounts and click + CREATE SERVICE ACCOUNT.
Enter values in the fields and click CREATE.
In Grant this service account access to project, select the role as
PrivaceraPolicySyncRole
.On the Services Account Page, find the newly created service account and copy the email address of the new service account for use in a later step.
Note
This email will be the Service Account Email for configuring PolicySync in Privacera Manager.
If you are using a Google VM machine to configure Google BigQuery for PolicySync, then you can attach the service account created above to your VM machine and skip below steps.
On the Services Account Page, go to the Keys tab and click Add Key and select Create New Key.
Select the JSON key type, and click CREATE. A JSON key file downloads to your system. Store the file at an accessible location. It will be used for configuring PolicySync in Privacera Manager.
See the Google documentation for a detailed information on creating a service account.
Configure Logs for Auditing
A sink is required to collect all the logs from Google BigQuery. To create a sink, do the following steps:
In the search bar, search for Logging, and then click Logs Router, and click Create Sink.
Enter the sink name as PolicySyncBigQueryAuditSink, and then click Next.
Enter the sink destination.
In the Select sink service, select BigQuery.
In SelectBigQuerydataset, click Create newBigQuerydataset.
Enter the Dataset ID as bigquery_audits and click Create Dataset.
Click Next.
Add theBigQuerylogs in the sink:
In the Build an inclusion filter, add the following line:
resource.type="bigquery_resource"
Click Create Sink.
See the Google documentation for a detailed information on creating a sink.
Optional Basic Authentication for PolicySync
To optionally enable basic authenticate for PolicySync toGoogle BigQuery you can create a JSON file in your connector instance subdirectory.
The name of the file must be XXX.json
.
An example of the contents of XXX.json
.:
{ "type": "service_account", "project_id": "your_project_id", "private_key_id": "autogenerated_value", "private_key": "-----BEGIN PRIVATE KEY-----autogenerated_value-----END PRIVATE KEY-----\n", "client_email": "autogenerated_value", "client_id": "autogenerated_value", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/autogenerated_value" }
These BigQuery connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC properties and then examine the ADVANCED properties to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default | Allowable values |
JDBC configuration properties | ||||
BASIC | CONNECTOR_BIGQUERY_PROJECT_LOCATION | The BigQuery data location. We can check any of the table details and we can see its data location value. https://cloud.google.com/bigquery/docs/locations?hl=en&_ga=2.44580199.-217615852.1620270192 | us | |
BASIC | CONNECTOR_BIGQUERY_PROJECT_ID | This property is used to set the project id which can be used for initial interaction with BigQuery APIs to explore the other projects and datasets available. Example :- privacera-demo-project | ||
CONNECTOR_BIGQUERY_JDBC_URL | This property is used to set JDBC url which can be used to connect to bigquery server. | jdbc:bigquery://https://www.googleapis.com/bigquery/v2:443 | ||
CONNECTOR_BIGQUERY_USE_VM_CREDENTIALS | This is property is used to set whether if you want to use service account attached to your VM for getting credentials to connect to bigquery to get metadata and to apply grants. when this property is used to set there is no need to set BIGQUERY_OAUTH_PRIVATE_KEY_PATH | FALSE | ||
BASIC | CONNECTOR_BIGQUERY_OAUTH_SERVICE_ACCOUNT_EMAIL | This property is used to set service account email address which is to be used for policysync to connect to bigquery | ||
CONNECTOR_BIGQUERY_OAUTH_PRIVATE_KEY_PATH | This property is used to set the path of service account credential json file downloaded from google service account keys section. This property value is needed when BIGQUERY_USE_VM_CREDENTIALS is set to false. | /workdir/connector/{{connector}}/cust_conf/{{ CONNECTOR_BIGQUERY_OAUTH_PRIVATE_KEY_FILE_NAME }} | ||
BASIC | CONNECTOR_BIGQUERY_OAUTH_PRIVATE_KEY_FILE_NAME | This property is used to set the credential JSON file name which you have copied inside your connector instance configuration folder. | policysync-gbq-service-account.json | |
BASIC | NA | NA | NA | |
Custom IAM Roles | ||||
ADVANCED | CONNECTOR_BIGQUERY_CREATE_CUSTOM_IAM_ROLES | Enable this property if you want policysync to create custom IAM roles automatically in your GCP project or organization for fine grained access control. If you keep this disable, then you have to create all custom IAM roles manually in your GCP project or organization. | true | |
ADVANCED | CONNECTOR_BIGQUERY_CUSTOM_IAM_ROLES_SCOPE | BigQuery policysync used custom IAM roles for fine grained access control. These roles can be created at each individual project level IAM or at organization level IAM. This can be configurable by setting this property value to project or org. project - create/use custom IAM roles from each individual project level. org - create/use custom IAM roles from organization level. | project | project - create/use custom iam roles from each individual project level. org - create/use custom iam roles from organization level. |
ADVANCED | CONNECTOR_BIGQUERY_ORGANIZATION_ID | This is property is used to set your GCP organization id if you decide to use the custom IAM roles at the organization level. | ||
ADVANCED | CONNECTOR_BIGQUERY_CUSTOM_IAM_ROLES_NAME_MAPPING | BigQuery policysync used custom IAM roles for fine grained access control. These roles are created with some default privacera defined names, but if you want to change those names as per your organization standards then you can update those using this property and policysync will continue to use those customized role names. It should be specified in syntax like Example value can look like below PrivaceraGBQProjectListRole:CustomBigQueryProjectListRole,PrivaceraGBQJobListRole:CustomBigQueryJobListRole,PrivaceraGBQJobListAllRole:CustomBigQueryJobListAllRole,PrivaceraGBQJobCreateRole:CustomBigQueryJobCreateRole,PrivaceraGBQJobGetRole:CustomBigQueryJobGetRole,PrivaceraGBQJobUpdateRole:CustomBigQueryJobUpdateRole,.... Below are the list of default custom role names which we have - PrivaceraGBQProjectListRole - PrivaceraGBQJobListRole - PrivaceraGBQJobListAllRole - PrivaceraGBQJobCreateRole - PrivaceraGBQJobGetRole - PrivaceraGBQJobUpdateRole - PrivaceraGBQJobDeleteRole - PrivaceraGBQDatasetCreateRole - PrivaceraGBQDatasetGetMetadataRole - PrivaceraGBQDatasetUpdateRole - PrivaceraGBQDatasetDeleteRole - PrivaceraGBQTableListRole - PrivaceraGBQTableCreateRole - PrivaceraGBQTableGetMetadataRole - PrivaceraGBQTableQueryRole - PrivaceraGBQTableExportRole - PrivaceraGBQTableUpdateMetadataRole - PrivaceraGBQTableUpdateRole - PrivaceraGBQTableSetCategoryRole - PrivaceraGBQTableDeleteRole - PrivaceraGBQTransferUpdateRole - PrivaceraGBQTransferGetRole | ||
Load keys and intervals | ||||
CONNECTOR_BIGQUERY_AUDIT_SYNC_INTERVAL | This property is used to set the interval in seconds for getting access audits process. Access audits process is the process where get the access audits from the bigquery which tells us who access what and then we push those audits to SOLR so we can display it in Privacera Access Audit UI Page. This process happens in defined interval time. | 30 | ||
BASIC | CONNECTOR_BIGQUERY_MANAGE_PROJECT_LIST | This property is used to set comma separated project names for which access control should be managed by policysync. If you want to manage all projects then you can skip specifying this property. This supports wildcards as well. The ignore projects list has precedence over manage projects list. Eg. testproject1,testproject2,sales_project* Note :- values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_BIGQUERY_MANAGE_DATASET_LIST | This property is used to set comma separated dataset fqdn for which access control should be managed by policysync. If you want to manage all datasets then you can skip specifying this property. This supports wildcards as well. The ignore dataset list has precedence over manage dataset list. Eg. testproject1.dataset1,testproject2.dataset2,sales_project*.sales* Note :- values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_BIGQUERY_MANAGE_TABLE_LIST | This property is used to set comma separated table/view fqdn for which access control should be managed by policysync. If you want to manage all tables/views then you can skip specifying this property. This supports wildcards as well. The ignore table list has precedence over manage table list. Eg. testproject1.dataset1.table1,testproject2.dataset2.view2,sales_project*.sales*.* Note :- values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_BIGQUERY_IGNORE_PROJECT_LIST | This property is used to set comma separated project names for which you don't want access control to be managed by policysync. If you don't want to ignore any project then you can skip specifying this property. This supports wildcards as well. This has precedence over manage project list. Eg. testproject1,testproject2,sales_project* Note :- values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_BIGQUERY_IGNORE_DATASET_LIST | This property is used to set comma separated dataset fqdn for which you don't want access control to be managed by policysync. If you don't want to ignore any dataset then you can skip specifying this property. This supports wildcards as well. This has precedence over manage dataset list. Eg. testproject1.dataset1,testproject2.dataset2,sales_project*.sales* Note :- values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_BIGQUERY_IGNORE_TABLE_LIST | This property is used to set comma separated table/view fqdn for which you don't want access control to be managed by policysync. If you don't want to ignore any tables/views then you can skip specifying this property. This supports wildcards as well. This has precedence over manage table list. Eg. testproject1.dataset1.table1,testproject2.dataset2.view2,sales_project*.sales*.* Note :- values for this property are case-sensitive. | ||
Users/Groups/Roles management | ||||
ADVANCED | CONNECTOR_BIGQUERY_MANAGE_USER_LIST | This property is used to set comma separated user names for which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_BIGQUERY_MANAGE_GROUP_LIST | This property is used to set comma separated group names for which access control should be managed by policysync. If you want to manage all group then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedence over manage group list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_BIGQUERY_IGNORE_USER_LIST | This property is used to set comma separated user names for which you don't want access control to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_BIGQUERY_IGNORE_GROUP_LIST | This property is used to set comma separated group names for which you don't want access control to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedence over manage groups list. Eg. group1,group2,dev_group* | ||
BASIC | CONNECTOR_BIGQUERY_NATIVE_PUBLIC_GROUP_IDENTITY_NAME | Set this property to your preferred value, policysync uses this native public group for access grants whenever there is policy created referring to public group inside it. | ALL_AUTHENTICATED_USERS - all gcp project authenticated users. ALL_USERS - all google authenticated users. | |
ADVANCED | CONNECTOR_BIGQUERY_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belongs the the groups defined in manage groups list property. | false | |
Access control management | ||||
ADVANCED | CONNECTOR_BIGQUERY_COLUMN_ACCESS_CONTROL_TYPE | This property is used to set the method of column level access control to be used by policysync. | view | view - This supports view based column level access control, which means whatever the columns users not having the access they will see those columns as null in the secure view of table or secure view of native view. |
ADVANCED | CONNECTOR_BIGQUERY_POLICY_NAME_SEPARATOR | This property is used to set separator, this separator is used while creating name for native tr filter policy | _ | |
ADVANCED | CONNECTOR_BIGQUERY_ROW_FILTER_POLICY_NAME_TEMPLATE | This property is used to set template, which will be used to create native tr filter policy names. For example, multiple native tr filters added on table will look like tr_filter_item_1, tr_filter_item_2 etc. | tr_filter_item_ | |
ADVANCED | CONNECTOR_BIGQUERY_ENABLE_ROW_FILTER | Set this property to true, if you want to enable native tr filter functionality. This is not recommended to use, since the native tr filters can only be created on tables, they can't be created on views. | false | |
ADVANCED | CONNECTOR_BIGQUERY_ENABLE_VIEW_BASED_MASKING | Set this property to true, if you want to enable secure view based masking in bigquery policysync. Note :- Bigquery don't support native masking yet, thus recommended to use view based masking. | true | |
ADVANCED | CONNECTOR_BIGQUERY_ENABLE_VIEW_BASED_ROW_FILTER | Set this property to true, if you want to enable secure view based tr filter in bigquery policysync. Note :- Bigquery support native tr filters, but due to its some limitations we recommended to use view based tr filter. | true | |
ADVANCED | CONNECTOR_BIGQUERY_SECURE_VIEW_CREATE_FOR_ALL | Set this property to true, if you want to create secure view for all tables as well all views which were created by end users. This will create secure view for resource regardless whether there is any masking/tr filter policy exists in ranger. | true | |
CONNECTOR_BIGQUERY_MASKING_FUNCTIONS_DATASET | This property is used to set the name of the dataset in the gcp project which can be used to create custom masking functions required by policysync if any. | privacera_dataset | ||
ADVANCED | CONNECTOR_BIGQUERY_MASKED_NUMBER_VALUE | This property is used to specify the default masking value for numeric columns | 0 | |
ADVANCED | CONNECTOR_BIGQUERY_MASKED_TEXT_VALUE | This property is used to specify the default masking value for text/string columns | <MASKED>' | |
ADVANCED | CONNECTOR_BIGQUERY_SECURE_VIEW_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same name as the table name. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | ||
ADVANCED | CONNECTOR_BIGQUERY_SECURE_VIEW_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same name as the table name. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | ||
ADVANCED | CONNECTOR_BIGQUERY_SECURE_VIEW_DATASET_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same schema name as the table schema name postfixed by _secure. If you want to change the secure view schema name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} | ||
ADVANCED | CONNECTOR_BIGQUERY_SECURE_VIEW_DATASET_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same schema name as the table schema name postfixed by _secure. If you want to change the secure view schema name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} | _secure | |
ADVANCED | CONNECTOR_BIGQUERY_SECURE_VIEW_NAME_REMOVE_SUFFIX_LIST | You can remove any unwanted suffix attached at the end of a table/view name. For example, if the table name is some_name_table, you can remove the suffix, _table. and then your secure name will be {prefix}some_name{postfix} Enter a suffix string or a comma-separated list of suffix strings. | ||
ADVANCED | CONNECTOR_BIGQUERY_SECURE_VIEW_DATASET_NAME_REMOVE_SUFFIX_LIST | You can remove any unwanted suffix attached at the end of a schema name. For example, if the schema is some_name_schema, you can remove the suffix, _schema. and then your secure schema name will be {schema_prefix}some_schema{schema_postfix} Enter a suffix string or a comma-separated list of suffix strings. | ||
CONNECTOR_BIGQUERY_ENABLE_AUTHORIZED_VIEW_ACL_UPDATER | This property is used to enable unsynchronized authorized view ACLs updater thread, it updates the dataset ACLs with authorized secure view names, It also does it periodically with by batching the requests for one or more views | true | ||
ADVANCED | CONNECTOR_BIGQUERY_GRANT_UPDATES | This property controls whether actual grant/revoke should be run on bigquery. | true | |
ADVANCED | CONNECTOR_BIGQUERY_ENABLE_DATA_ADMIN | This property is used to enable data admin feature, with data admin feature enabled you can create all the policies on table/native view and by default perspective grants will be made on secure view of table, table or native view. And the secure views will have tr filter and masking capability as well. In case if you need permission on table then you can select the permission you want plus DataAdmin in the policy, In this case that selected permissions will be granted on both, the table/native view and its secure view as well. | true | |
Access audits management | ||||
BASIC | CONNECTOR_BIGQUERY_AUDIT_ENABLE | This property is used to enable access audit fetching from bigquery. | false | |
ADVANCED | CONNECTOR_BIGQUERY_AUDIT_EXCLUDED_USERS | This property is used to set the list of users whose access audits should be ignored by policysync. It takes list of comma separated email addresses of the users. | BIGQUERY_OAUTH_SERVICE_ACCOUNT_EMAIL | |
ADVANCED | CONNECTOR_BIGQUERY_AUDIT_PROJECT_ID | This property is used to set the project id which should be used when running query to fetch the audits from bigquery. | CONNECTOR_BIGQUERY_PROJECT_ID | |
ADVANCED | CONNECTOR_BIGQUERY_AUDIT_DATASET_NAME | This property is used to set the dataset name which should be used when running query to fetch the audits from bigquery. | bigquery_audits |
These instructions enable and configure Privacera Microsoft SQL Server database connector to an existing Microsoft SQL Server database running on the Azure cloud platform or the AWS Relational Database Service (RDS). This connector uses the PolicySync method in which access policies defined in Privacera are mapped to and synchronized to the 'native' access controls in MS SQL.
The PolicySync approach has several benefits and advantages:
Fine-grained access control - at the database, schema, table, view, and column levels.
Column level masking
Dynamic row-level filters on tables and views
Generalized approach for implementing PolicySync
To help you reach compliance, Privacera PolicySync distributes your defined access management policies to the third-party datasources you connect to Privacera.
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: mssql
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
mssql
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above and in the example in Required basic PolicySync topology: always at least one connector instance, replace postgres
with the above.
Prerequisites
The Microsoft SQL Server must already be installed and running.
If you are installing an evaluation, you may need to install and configure an Microsoft SQL Server with one or more databases to test against.
1) Target Database Access
The Microsoft SQL Server must also be accessible from the Privacera Platform hosts. The standard inbound port for Microsoft SQL Server access is TCP 1433. Make sure that is open 'outbound' from Privacera Platform hosts and inbound to your target Microsoft SQL Server.
2) Access Control by Privacera Service Account
Privacera Platform requires access to the target database and the service account must be established in a 'loginmanager' role. This can be configured in three ways: (1) Access Control on Azure AD Users; (2) Access Control on Local Database Users; or (3) Access Control on both Azure AD user and local users.
Access Control on Azure AD Users
Confirm the Microsoft SQL Server is configured to work with Azure AD Users.
In your Azure AD, create a Privacera 'service' user to be used by Privacera for the Policy access control synchronization. For this example we'll assume the name is 'privacera_policysync@example.com' but set the value appropriately for your domain(s). Keep note of the username and password as we'll use both later.
For each targeted database:
Log on to the target database with an Admin role account.
Execute the following:
IF DATABASE_PRINCIPAL_ID('privacera_policysync@example.com') IS NULL BEGIN CREATE USER [privacera_policysync@example.com] FROM EXTERNAL PROVIDER; END; -- Grant full control on database to privacera_policysync@example.com user GRANT CONTROL ON DATABASE::${YOUR_DATABASE} TO [privacera_policysync@example.com];
Access Control on Local Database Users
Create a Privacera 'service' user in the master database to be used by Privacera for the Policy access control synchronization. For this example, we'll assume the name is 'privacera_policysync' but set the value appropriately for your domain(s). Keep note of the username and password as we'll use both later.
IF NOT EXISTS (SELECT name FROM sys.sql_logins WHERE name = 'privacera_policysync') BEGIN CREATE LOGIN [privacera_policysync] WITH PASSWORD = '${PASSWORD}' END; IF DATABASE_PRINCIPAL_ID('privacera_policysync') IS NULL BEGIN CREATE USER [privacera_policysync] FROM LOGIN [privacera_policysync]; END; EXEC sp_addrolemember [loginmanager], [privacera_policysync];
For each targeted database:
Log on to the target database with an Admin role account.
Execute the following:
IF DATABASE_PRINCIPAL_ID('privacera_policysync') IS NULL BEGIN CREATE USER [privacera_policysync] FROM LOGIN [privacera_policysync]; END; -- Grant full control on database to privacera_policysync user GRANT CONTROL ON DATABASE::${YOUR_DATABASE} TO [privacera_policysync];
Access Control on Azure AD and Local Database Users
Confirm the Microsoft SQL Serveris configured to work with Azure AD Users.
In your Azure AD, create a Privacera 'service' user to be used by Privacera for the Policy access control synchronization. For this example, we'll assume the name is 'privacera_policysync@example.com' but set the value appropriately for your domain(s). Keep note of the username and password as we'll use both later.
Create a Privacera 'service' user in the master database to be used by Privacera for the Policy access control synchronization. For this example, we'll assume the name is 'privacera_policysync@example.com' but set the value appropriately for your domain(s). Keep note of the username and password as we'll use both later.
IF DATABASE_PRINCIPAL_ID('privacera_policysync@example.com') IS NULL BEGIN CREATE USER [privacera_policysync@example.com] FROM EXTERNAL PROVIDER; END; EXEC sp_addrolemember [loginmanager], [privacera_policysync@example.com];
For each targeted database:
Log on to the target database with an Admin role account.
Execute the following:
IF DATABASE_PRINCIPAL_ID('privacera_policysync@example.com') IS NULL BEGIN CREATE USER [privacera_policysync@example.com] FROM EXTERNAL PROVIDER; END; -- Grant full control on database to privacera_policysync@example.com user GRANT CONTROL ON DATABASE::${YOUR_DATABASE} TO [privacera_policysync@example.com];
3) Create or Identify an ADLS Gen2 storage used to store Microsoft SQL Server Audits
See Configure Microsoft SQL server for database synapse audits.
Using information from that article obtain the Audit storage URL. This will be used in the Privacera Microsoft SQL Server PolicySync configuration.
4) Create an MS SQL server in AWS RDS to store MSSQL Server Audits
Consult the following article SQL Server Audit.
Using information from that article obtain the Audit storage URL. This will be used in the Privacera Microsoft SQL Server PolicySync configuration.
These Microsoft SQL connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC properties and then examine the ADVANCED properties to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default | Allowable values |
JDBC configuration properties | ||||
BASIC | CONNECTOR_MSSQL_JDBC_URL | This property is used to set jdbc url which can be used to connect to Mssql server. JDBC URL should follow below convention jdbc:sqlserver://<MSSQL_SERVER_HOST>:<MSSQL_SERVER_PORT> Example :- jdbc:sqlserver://example.database.windows.net:1433 | ||
BASIC | CONNECTOR_MSSQL_JDBC_USERNAME | This property is used to set jdbc Username to be used to make connection to MSSQL. | ||
BASIC | CONNECTOR_MSSQL_JDBC_PASSWORD | This property is used to set jdbc username password to be used to make connection to MSSQL. | ||
BASIC | CONNECTOR_MSSQL_MASTER_DB | This property is used to set jdbc master database to be used to make initial connection to Mssql. | master | |
BASIC | CONNECTOR_MSSQL_AUTHENTICATION_TYPE | If MSSQL_JDBC_USERNAME is a 'local user', set value as below: MSSQL_AUTHENTICATION_TYPE: "SqlPassword" If MSSQL_JDBC_USERNAME is an Azure AD user, then set as below: MSSQL_AUTHENTICATION_TYPE: "ActiveDirectoryPassword" | SqlPassword | SqlPassword/ActiveDirectoryPassword |
BASIC | CONNECTOR_MSSQL_DEFAULT_USER_PASSWORD | This property is used to set password to every new user created by policysync in MSSQL. | ||
BASIC | CONNECTOR_MSSQL_OWNER_ROLE | This property is used to set ownership for all the resources managed by policysync. The specified role will become owner for all managed resources and will have full control on those resources.We support changing owners of database, schema, tables and views. Note :- If owner role is kept as blank, then ownership will not change and users who creates table/view or any other object he will be owner of those objects and policysync won't be able to do access control on that object | ||
Resources management | ||||
ADVANCED | CONNECTOR_MSSQL_MANAGE_DATABASE_LIST | This property is used to set database name for which access control should be managed by policysync. The ignore database list has precedence over manage database list. Eg. testdb1 Note: For mssql connector we support only 1 database at a time for access control, providing the multiple databases list here will not work, value for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_MSSQL_MANAGE_SCHEMA_LIST | This property is used to set list of comma separated schema names/wildcards for schema names of database to be managed by policysync. Not specifying this property indicates manage all schemas. Schemas should be specified in format of <database>.<schema> Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_MSSQL_MANAGE_TABLE_LIST | This property is used to set list of comma separated tables names/wildcards for table names of the managed schema to be managed by policysync. Not specifying this property indicates manage all tables. tables should be specified in format of <database>.<schema>.<table> Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_MSSQL_IGNORE_DATABASE_LIST | This property is used to set comma separated database names which access control you don't want to be managed by policysync. If you don't want to ignore any database then you can skip specifying this property. This supports wildcards as well. This has precedence over manage database list. Eg. testdb1,testdb2,sales_db* Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_MSSQL_IGNORE_SCHEMA_LIST | This property is used to set comma separated schema fqdn which access control you don't want to be managed by policysync. If you don't want to ignore any schema then you can skip specifying this property. This supports wildcards as well. This has precedence over manage schema list. Eg. testdb1.schema1,testdb2.schema2,sales_db*.sales* Note: values for this property are case-sensitive. | ||
Users/Groups/Roles management | ||||
ADVANCED | CONNECTOR_MSSQL_USER_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_MSSQL_USER_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_MSSQL_GROUP_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a group name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_MSSQL_GROUP_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified group name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_MSSQL_ROLE_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a role name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_MSSQL_ROLE_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified role name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_MSSQL_USER_NAME_PERSIST_CASE_SENSITIVITY | After loading user from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_GROUP_NAME_PERSIST_CASE_SENSITIVITY | After loading group from Ranger API's all are converted into lowercase, but in some cases, you would need to have the groups in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_ROLE_NAME_PERSIST_CASE_SENSITIVITY | After loading role from Ranger API's all are converted into lowercase, but in some cases, you would need to have the roles in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | true/false |
CONNECTOR_MSSQL_USER_NAME_CASE_CONVERSION | This property only applicable if USER NAME PERSIST CASE SENSITIVITY is set to false. Managed users name would be treated as lowercase by default. If the value is set to "upper" then the user name would be treated as uppercase. If the value is set to "none" then the user name case is preserved. | lower | none, lower, upper | |
ADVANCED | CONNECTOR_MSSQL_MANAGE_USERS | This property controls whether policysync should manage the membership between user and user role. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_MANAGE_GROUPS | This property controls whether we should create role in MSSQL for groups fetched from ranger. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_MANAGE_ROLES | This property controls whether we should create role in MSSQL for roles fetched from ranger. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_MANAGE_USER_LIST | This property is used to set comma separated user names which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_MSSQL_MANAGE_GROUP_LIST | This property is used to set comma separated group names which access control should be managed by policysync. If you want to manage all group then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedence over manage group list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_MSSQL_MANAGE_ROLE_LIST | This property is used to set comma separated role names which access control should be managed by policysync. If you want to manage all role then you can skip specifying this property. This supports wildcards as well. The ignore role list has precedence over manage role list. Eg. role1,role2,dev_role* | ||
ADVANCED | CONNECTOR_MSSQL_IGNORE_USER_LIST | This property is used to set comma separated user names which access control you don't want to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_MSSQL_IGNORE_GROUP_LIST | This property is used to set comma separated group names which access control you don't want to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedence over manage groups list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_MSSQL_IGNORE_ROLE_LIST | This property is used to set comma separated role names which access control you don't want to be managed by policysync. If you don't want to ignore any roles then you can skip specifying this property. This supports wildcards as well. This has precedence over manage roles list. Eg. role1,role2,dev_role* | ||
ADVANCED | CONNECTOR_MSSQL_USER_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in MSSQL for user from ranger. For example if you have user named john in ranger and you have defined prefix as test_user_ then the role which we create for john in Mssql will have name test_user_john | priv_user_ | |
ADVANCED | CONNECTOR_MSSQL_GROUP_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in MSSQL for group from ranger. For example if you have group named dev in ranger and you have defined prefix as test_group_ then the role which we create for dev in Mssql will have name test_group_dev | priv_group_ | |
ADVANCED | CONNECTOR_MSSQL_ROLE_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in MSSQL for role from ranger. For example if you have role named finance in ranger and you have defined prefix as test_role_ then the role which we create for finance in Mssql will have name test_role_finance | priv_role_ | |
ADVANCED | CONNECTOR_MSSQL_USE_NATIVE_PUBLIC_GROUP | Set this property to true, if you want PolicySync to use mssql native public group for access grants whenever there is policy created referring to public group inside it. | true | true/false |
ADVANCED | CONNECTOR_MSSQL_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belongs the the groups defined in manage groups list property. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_MANAGE_USER_FILTERBY_ROLE | Set this property to true, if you want to manage only the users who belongs the the roles defined in manage roles list property. | false | true/false |
Access control management | ||||
ADVANCED | CONNECTOR_MSSQL_ENABLE_ROW_FILTER | Set this property to true, if you want to enable native tr filter functionality. This is not recommended to use, since the native tr filters can only be created on tables, they can't be created on views. | true | true/false |
ADVANCED | CONNECTOR_MSSQL_ENABLE_VIEW_BASED_MASKING | Set this property to true, if you want to enable secure view based masking in Mssql policysync. Note :- Mssql don't support native masking yet, thus recommended to use view based masking. | true | true/false |
ADVANCED | CONNECTOR_MSSQL_ENABLE_VIEW_BASED_ROW_FILTER | Set this property to true, if you want to enable secure view based tr filter in Mssql policysync. Note :- Mssql support native tr filters, but due to its some limitations we recommended to use view based tr filter. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_SECURE_VIEW_CREATE_FOR_ALL | Set this property to true, if you want to create secure view for all tables as well all view which were created by end users. This will create secure view for resource regardless whether there any masking/tr filter policy exists in ranger. | false | true/false |
ADVANCED | CONNECTOR_MSSQL_MASKED_NUMBER_VALUE | This property is used to specify the default masking value for numeric columns | 0 | |
ADVANCED | CONNECTOR_MSSQL_MASKED_TEXT_VALUE | This property is used to specify the default masking value for text/string columns | <MASKED>' | |
ADVANCED | CONNECTOR_MSSQL_SECURE_VIEW_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | ||
ADVANCED | CONNECTOR_MSSQL_SECURE_VIEW_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | _secure | |
ADVANCED | CONNECTOR_MSSQL_SECURE_VIEW_SCHEMA_NAME_PREFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} For {view_schema_name} refer to variable MSSQL_SECURE_VIEW_SCHEMA_NAME | ||
ADVANCED | CONNECTOR_MSSQL_SECURE_VIEW_SCHEMA_NAME_POSTFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} For {view_schema_name} refer to variable Mssql_SECURE_VIEW_SCHEMA_NAME | ||
BASIC | CONNECTOR_MSSQL_GRANT_UPDATES | This property controls whether actual grant/revoke and create/update/delete queries for user/group/role should be run on Mssql. | true | true/false |
CONNECTOR_MSSQL_GRANT_UPDATES_MAX_RETRY_ATTEMPTS | This property is used to set max retry attempts to be made for granting or revoking the access in case if any failure due to database connection errors. | 2 | ||
ADVANCED | CONNECTOR_MSSQL_ENABLE_DATA_ADMIN | This property is used to enable data admin feature, with data admin feature enabled you can create all the policies on table/native view and by default respective grants will be made on secure view of table table or native view. And this secure view will have tr filter and masking capability as well. In case if you need permission on table then you can select the permission you want plus dataadmin in the policy, In this case that permissions will be granted on both, the table/native view and its secure view as well | true | true/false |
Access audits management | ||||
BASIC | CONNECTOR_MSSQL_AUDIT_ENABLE | This property is used to enable access audit fetching from Mssql | false | |
BASIC-CONDITIONAL | CONNECTOR_MSSQL_AUDIT_STORAGE_URL | If this parameter is left empty or blank, Privacera Platform will target all databases attached to the MSSQL Server. If one or more database names are listed (comma separated values), only those databases will be controlled by Privacera Platform. | ||
ADVANCED | CONNECTOR_MSSQL_AUDIT_EXCLUDED_USERS | This property is used to set the list of users whose access audits we want to ignore. It takes list of comma separated users. | CONNECTOR_MSSQL_JDBC_USERNAME |
This topic covers how you can configure PostgreSQL PolicySync access control using Privacera Manager. Privacera supports the following PostgreSQL implementations:
Amazon RDS PostgreSQL
Amazon Aurora in PostgreSQL mode
Google Cloud PostgreSQL
PostgreSQL
Generalized approach for implementing PolicySync
To help you reach compliance, Privacera PolicySync distributes your defined access management policies to the third-party datasources you connect to Privacera.
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: postgres
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
postgres
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above.
Prerequisites
Create a database in PostgreSQL and get the database name and its URL:
On Amazon RDS, see Creating a PostgreSQL DB instance.
On Google Cloud Platform, see the documentation for your PostgreSQL implementation:
Create a database user granting all privileges to fully access the database, and then get the user credentials to connect to the database.
If you choose to enable audits for PolicySync, ensure the following prerequisites are met:
On AWS, see Configure AWS RDS PostgreSQL instance for access audits. If you are using multiple AWS accounts, see Access cross-account SQS queue for PostgreSQL audits on PrivaceraCloud.
On GCP, see Accessing PostgreSQL Audits in GCP.
Optional Basic Authentication for PolicySync
To optionally enable basic authenticate for PolicySync to Google Cloud PostgreSQL you can create a JSON file in your connector instance subdirectory.
The name of the file must be XXX.json
.
An example of the contents of XXX.json
.:
{ "type": "service_account", "project_id": "your_project_id", "private_key_id": "autogenerated_value", "private_key": "-----BEGIN PRIVATE KEY-----autogenerated_value-----END PRIVATE KEY-----\n", "client_email": "autogenerated_value", "client_id": "autogenerated_value", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/autogenerated_value" }
These PostgreSQL connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC properties and then examine the ADVANCED properties to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default Value | Allowable values |
JDBC configuration properties | ||||
BASIC | CONNECTOR_POSTGRES_JDBC_URL | This property is used to set jdbc jdbc url which can be used to connect to postgres server. JDBC URL should follow below convention jdbc:postgresql://<POSTGRES_SERVER_HOST>:<POSTGRES_SERVER_PORT> Example :- jdbc:postgresql://testdb.cxwi0ttzd22i.us-east-1.rds.amazonaws.com:5432 | ||
BASIC | CONNECTOR_POSTGRES_JDBC_USERNAME | This property is used to set jdbc Username to be used to make connection to postgres. | ||
BASIC | CONNECTOR_POSTGRES_JDBC_PASSWORD | This property is used to set jdbc user's password to be used to make connection to postgres. | ||
BASIC | CONNECTOR_POSTGRES_JDBC_DB | This property is used to set jdbc database to be used to make initial connection to postgres. | ||
BASIC | CONNECTOR_POSTGRES_DEFAULT_USER_PASSWORD | This property is used to set password to every new user creation in postgres by policysync. | ||
BASIC | CONNECTOR_POSTGRES_OWNER_ROLE | This property is used to set ownership for all the resources managed by policysync. The specified role will become owner for all managed resources and will have full control on those resources.We support changing owners of database, schema, tables and views. Note :- If owner role is kept as blank, then ownership will not change and users who creates table/view or any other object he will be owner of those objects and policysync won't be able to do access control on that object | ||
Resources management | ||||
BASIC | CONNECTOR_POSTGRES_MANAGE_DATABASE_LIST | This property is used to set comma separated database names which access control should be managed by policysync. If you want to manage all databases then you can skip specifying this property. This supports wildcards as well. The ignore database list has precedance over manage database list. Eg. testdb1,testdb2,sales_db* NOTE: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_POSTGRES_MANAGE_SCHEMA_LIST | This property is used to set comma separated schema Fqdn which access control should be managed by policysync. If you want to manage all schemas then you can skip specifying this property. This supports wildcards as well. The ignore schema list has precedance over manage schema list. Eg. testdb1.schema1,testdb2.schema2,sales_db*.sales* NOTE: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_POSTGRES_MANAGE_TABLE_LIST | This property is used to set comma separated table/view Fqdn which access control should be managed by policysync. If you want to manage all tables/views then you can skip specifying this property. This supports wildcards as well. The ignore table list has precedance over manage table list. Eg. testdb1.schema1.table1,testdb2.schema2.view2,sales_db*.sales*.* NOTE: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_POSTGRES_IGNORE_DATABASE_LIST | This property is used to set comma separated database names which access control you don't want to be managed by policysync. If you don't want to ignore any database then you can skip specifying this property. This supports wildcards as well. This has precedance over manage database list. Eg. testdb1,testdb2,sales_db* NOTE: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_POSTGRES_IGNORE_SCHEMA_LIST | This property is used to set comma separated schema Fqdn which access control you don't want to be managed by policysync. If you don't want to ignore any schema then you can skip specifying this property. This supports wildcards as well. This has precedance over manage schema list. Eg. testdb1.schema1,testdb2.schema2,sales_db*.sales* NOTE: values for this property are case-sensitive. | ||
Users/Groups/Roles management | ||||
ADVANCED | CONNECTOR_POSTGRES_USER_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\[\\]!\\-\\/\\\\{}] | |
ADVANCED | CONNECTOR_POSTGRES_USER_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_POSTGRES_GROUP_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a group name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\[\\]!\\-\\/\\\\{}] | |
ADVANCED | CONNECTOR_POSTGRES_GROUP_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified group name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_POSTGRES_ROLE_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a role name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\[\\]!\\-\\/\\\\{}] | |
ADVANCED | CONNECTOR_POSTGRES_ROLE_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified role name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_POSTGRES_USER_NAME_PERSIST_CASE_SENSITIVITY | After loading user from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | true/false |
ADVANCED | CONNECTOR_POSTGRES_GROUP_NAME_PERSIST_CASE_SENSITIVITY | After loading group from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | true/false |
ADVANCED | CONNECTOR_POSTGRES_ROLE_NAME_PERSIST_CASE_SENSITIVITY | After loading role from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | true/false |
ADVANCED | CONNECTOR_POSTGRES_CREATE_USER | This property controls whether we should create user in postgres for users fecthed from ranger. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_CREATE_USER_ROLE | This property controls whether we should create role over the end user in postgres for users fecthed from ranger. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_USERS | This property controls whether policysync should manage the membership between user and user role. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_GROUPS | This property controls whether we should create role in postgres for groups fecthed from ranger. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_GROUP_MEMBERS | This property controls whether we should update the members of groups in Postgres for groups fetched from ranger. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_ROLES | This property controls whether we should create role in postgres for roles fecthed from ranger. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_ROLE_MEMBERS | This property controls whether we should update the members of roles in Postgres for roles fetched from ranger. For example,, if CONNECTOR_POSTGRES_MANAGE_ROLES is set to true, but CONNECTOR_POSTGRES_MANAGE_ROLE_MEMBERS is set to false, then PolicySync will create roles, but it won’t add or remove members from those roles. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_USER_LIST | This property is used to set comma separated user names which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedance over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_POSTGRES_MANAGE_GROUP_LIST | This property is used to set comma separated group names which access control should be managed by policysync. If you want to manage all group then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedance over manage group list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_POSTGRES_MANAGE_ROLE_LIST | This property is used to set comma separated role names which access control should be managed by policysync. If you want to manage all role then you can skip specifying this property. This supports wildcards as well. The ignore role list has precedance over manage role list. Eg. role1,role2,dev_role* | ||
ADVANCED | CONNECTOR_POSTGRES_IGNORE_USER_LIST | This property is used to set comma separated user names which access control you don't want to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedance over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_POSTGRES_IGNORE_GROUP_LIST | This property is used to set comma separated group names which access control you don't want to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedance over manage groups list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_POSTGRES_IGNORE_ROLE_LIST | This property is used to set comma separated role names which access control you don't want to be managed by policysync. If you don't want to ignore any roles then you can skip specifying this property. This supports wildcards as well. This has precedance over manage roles list. Eg. role1,role2,dev_role* | ||
ADVANCED | CONNECTOR_POSTGRES_USER_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in postgres for user from ranger. For example, if you have user named john in ranger and you have defined prefix as test_user_ then the role which we create for john in postgres will have name test_user_john | priv_user_ | |
ADVANCED | CONNECTOR_POSTGRES_GROUP_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in postgres for group from ranger. For example, if you have group named dev in ranger and you have defined prefix as test_group_ then the role which we create for dev in postgres will have name test_group_dev | priv_group_ | |
ADVANCED | CONNECTOR_POSTGRES_ROLE_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in postgres for role from ranger. For example, if you have role named finance in ranger and you have defined prefix as test_role_ then the role which we create for finance in postgres will have name test_role_finance | priv_role_ | |
ADVANCED | CONNECTOR_POSTGRES_USE_NATIVE_PUBLIC_GROUP | Set this property to true, if you want PolicySync to use porstgres native public group for access grants whenever there is policy created referring to public group inside it. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belongs the the groups defined in manage groups list property. | false | true/false |
ADVANCED | CONNECTOR_POSTGRES_MANAGE_USER_FILTERBY_ROLE | Set this property to true, if you want to manage only the users who belongs the roles defined in manage roles list property. | false | true/false |
Access control management | ||||
ADVANCED | CONNECTOR_POSTGRES_ENABLE_ROW_FILTER | Set this property to true, if you want to enable native tr filter functionality. This is not recommened to use, since the native tr filters can only be created on tables, they can't be created on views. | false | true/false |
ADVANCED | CONNECTOR_POSTGRES_ENABLE_VIEW_BASED_MASKING | Set this property to true, if you want to enable secure view based masking in postgres policysync. Note :- Postgres don't support native masking yet, thus recommended to use view based masking. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_ENABLE_VIEW_BASED_ROW_FILTER | Set this property to true, if you want to enable secure view based tr filter in postgres policysync. Note :- Postgres support native tr filters, but due to its some limitations we recommened to use view based tr filter. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_SECURE_VIEW_CREATE_FOR_ALL | Set this property to true, if you want to create secure view for all tables as well all view which were created by end users. This will create secure view for resource regardless whether there any masking/tr filter policy exists in ranger. | true | true/false |
ADVANCED | CONNECTOR_POSTGRES_MASKED_NUMBER_VALUE | This property is used to specify the default masking value for numeric columns | 0 | |
ADVANCED | CONNECTOR_POSTGRES_MASKED_TEXT_VALUE | This property is used to specify the default masking value for text/string columns | <MASKED>' | |
ADVANCED | CONNECTOR_POSTGRES_SECURE_VIEW_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | ||
ADVANCED | CONNECTOR_POSTGRES_SECURE_VIEW_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | _secure | |
ADVANCED | CONNECTOR_POSTGRES_SECURE_VIEW_SCHEMA_NAME_PREFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} For {view_schema_name} refer to variable CONNECTOR_POSTGRES_SECURE_VIEW_SCHEMA_NAME | ||
ADVANCED | CONNECTOR_POSTGRES_SECURE_VIEW_DATABASE_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same database name as the table database name. If you want to change the secure view database name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view database name will be in this format : {prefix}{view_database_name}{postfix} For {view_database_name} refer to variable CONNECTOR_POSTGRES_SECURE_VIEW_DATABASE_NAME | ||
ADVANCED | CONNECTOR_POSTGRES_SECURE_VIEW_SCHEMA_NAME_POSTFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} For {view_schema_name} refer to variable POSTGRES_SECURE_VIEW_SCHEMA_NAME | ||
ADVANCED | CONNECTOR_POSTGRES_SECURE_VIEW_DATABASE_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same database name as the table database name. If you want to change the secure view database name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view database name will be in this format : {prefix}{view_database_name}{postfix} For {view_schema_name} refer to variable POSTGRES_SECURE_VIEW_DATABASE_NAME | ||
BASIC | CONNECTOR_POSTGRES_GRANT_UPDATES | This property controls whether actual grant/revoke and create/update/delete queries for user/group/role should be run on postgres. | true | true/false |
CONNECTOR_POSTGRES_GRANT_UPDATES_MAX_RETRY_ATTEMPTS | This property is used to set max retry attemps to be made for granting or revoking the access in case if any failure due to database connection errors. | 2 | ||
ADVANCED | CONNECTOR_POSTGRES_ENABLE_DATA_ADMIN | This propery is used to enable data admin feature, with data admin feature enabled you can create all the policies on table/native view and by default repspective grants will be made on secure view of table or native view. This secure view willl have tr filter and masking capability as well. In case if you need permission on table then you can select the permission you want plus dataadmin in the policy, in this case that permissions will be granted on both, the table/native view and its secure view as well. | true | true/false |
Access audits management | ||||
BASIC | CONNECTOR_POSTGRES_AUDIT_ENABLE | This property is used to enable access audit fetching from postgres. | false | true/false |
ADVANCED | CONNECTOR_POSTGRES_AUDIT_EXCLUDED_USERS | This property is used to set the list of users whose access audits we want to ignore. It takes list of comma separated users. | ||
BASIC | CONNECTOR_POSTGRES_AUDIT_SOURCE | This property is used to set the mode through which we should be loading access audits, this depends on the your Postgres server deployment, if you are using AWS RDS Postgres then you need to set this value to sqs, and in case if you are using GCP Postgres then you need to set this to gcp_pgaudit. | sqs | sqs/gcp_pgaudit |
ADVANCED | CONNECTOR_POSTGRES_AUDIT_ENABLE_RESOURCE_FILTER | This property is used to filter access audit by managed resources (database,schema list) NOTE: Policysync is using sql parser to extract resourceName to decide if it's manage or not and there is chance sql query pareser can break in case of complex query and it will end up without logging that audit. | FALSE | TRUE/FALSE |
BASIC-CONDITIONAL | CONNECTOR_POSTGRES_AWS_ACCESS_KEY | This property is used to set the aws access key which will be used to created iam client in order to access sqs queue to get access audits. This should be used only if your deployment machine don't have IAM role associated with it with required permissions | ||
BASIC-CONDITIONAL | CONNECTOR_POSTGRES_AWS_SECRET_KEY | This property is used to set the aws secret access key which will be used to created iam client in order to access sqs queue to get access audits. This should be used only if your deployment machine don't have IAM role associated with it with required permissions | ||
BASIC-CONDITIONAL | CONNECTOR_POSTGRES_AWS_REGION | This property is used to set the aws region in which sqs queue resides in. | us-east-1 | |
BASIC-CONDITIONAL | CONNECTOR_POSTGRES_AWS_SQS_QUEUE_NAME | This property is used to set aws sqs queue name from which we need to get access audits. | ||
BASIC-CONDITIONAL | CONNECTOR_POSTGRES_GCP_AUDIT_SOURCE_INSTANCE_ID | This property is used to set the instance id of gcp cloudsql postgres server which will be used to get the access audits. This instance id value needs to be in the format project_id:db_instance_id. For example, demo-project:postgres-demo-server |
This section covers how to enable configure Privacera Power BI connector for workspace fine-grained access-control in Power BI running in Azure. You can set permissions in a Privacera policy depending on the workspace roles : Admin, Member, Contributor, Viewer. Only users and groups from the Azure Active Directory are allowed in Azure Power BI.
Generalized approach for implementing PolicySync
To help you reach compliance, Privacera PolicySync distributes your defined access management policies to the third-party datasources you connect to Privacera.
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: powerbi
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
powerbi
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above and in the example in Required basic PolicySync topology: always at least one connector instance, replace postgres
with the above.
Prerequisites
Ensure that the following prerequisites are met:
Create a service principal and application secret for the Power BI, and get the following information from Azure Portal. For more information, refer the Microsoft Azure documentation.
Application (client) ID
Directory (tenant) ID
Client Secret
Create a group to assign your created Power BI application to it. This is required because the Power BI Admin API allows only the service principal to be an Azure AD Group.
Follow the steps in the link given above, and configure the following to create a group and add Power BI as a member:
On the New Group dialog, select
security
in the Group type, and then add the required group details.Click Create.
On the +Add members dialog, select your Power BI application.
Configure Power BI Tenant to allow Power BI service principals to read the REST API.
Follow the steps in the link given above and configure the following:
In the Developer settings, enable Allow service principals to use Power BI APIs.
Select Specific security groups (Recommended), and then add the Power BI group you created above.
In the Admin API Settings, enable Allow service principals to use read-only Power BI admin APIs (Preview). For more information, see the Microsoft Azure documentation - click here.
Select Specific security groups, and then add the Power BI group you created above.
Enable Privacera UserSync for AAD to pull groups attribute ID via the
AZURE_AD_ATTRIBUTE_GROUPNAME
property described in AAD UserSync connector properties.
These Power BI connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC properties and then examine the ADVANCED properties to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default | Allowable values |
Connection configuration properties | ||||
BASIC | CONNECTOR_POWER_BI_USERNAME | Username for authentication with Power BI. For authentication either username/password or client secret is needed | ||
BASIC | CONNECTOR_POWER_BI_PASSWORD | Password for authentication with Power BI. For authentication either username/password or client secret is needed | ||
BASIC | CONNECTOR_POWER_BI_TENANT_ID | Tenant Id is needed for authentication. To get the value for this property, Go to Azure portal > Azure Active Directory > Properties > Tenant ID | ||
BASIC | CONNECTOR_POWER_BI_CLIENT_ID | Client Id is needed For authentication. To get the value for this property, Go to Azure portal > Azure Active Directory > Properties > Client (Application) ID | ||
BASIC | CONNECTOR_POWER_BI_CLIENT_SECRET | Client Secret for authentication with Power BI. | ||
Resources management | ||||
BASIC | CONNECTOR_POWER_BI_MANAGE_WORKSPACE_LIST | Add the names of the workspaces to be managed. Only these workspaces will be provided with access control in a Power BI policy. Regular expression can be used for example, demo* (This will manage all the workspaces named as demo1,demo2 .etc). Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_POWER_BI_IGNORE_WORKSPACE_LIST | Add the names of the workspaces to be ignored. These workspaces will not be provided with access control in a Power BI policy. Note: values for this property are case-sensitive. | ||
Users/Groups/Roles management | ||||
ADVANCED | CONNECTOR_POWER_BI_USER_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [^a-zA-Z0-9@.\\\\s] | |
ADVANCED | CONNECTOR_POWER_BI_USER_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_POWER_BI_GROUP_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a group name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [^a-zA-Z0-9@.\\\\s] | |
ADVANCED | CONNECTOR_POWER_BI_GROUP_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified group name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_POWER_BI_USER_NAME_PERSIST_CASE_SENSITIVITY | After loading users from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_POWER_BI_GROUP_NAME_PERSIST_CASE_SENSITIVITY | After loading groups from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_POWER_BI_MANAGE_USER_LIST | This property is used to set comma separated user names which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_POWER_BI_MANAGE_GROUP_LIST | This property is used to set comma separated group names which access control should be managed by policysync. If you want to manage all groups then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedence over manage group list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_POWER_BI_IGNORE_USER_LIST | This property is used to set comma separated user names which access control you don't want to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_POWER_BI_IGNORE_GROUP_LIST | This property is used to set comma separated group names which access control you don't want to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedence over manage groups list. Eg. group1,group2,dev_group* | ||
CONNECTOR_POWER_BI_USER_FILTER_WITH_EMAIL | Set this property to true, if you want to manage only the users who contain the email field not blank. | false | ||
ADVANCED | CONNECTOR_POWER_BI_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belong to the groups defined in manage groups list property. | false | |
Access control management | ||||
BASIC | CONNECTOR_POWER_BI_GRANT_UPDATES | This property controls whether actual grant/revoke and create/update/delete queries for user/group/role should be run on power bi. | true | |
Access audits management | ||||
BASIC | CONNECTOR_POWER_BI_ENABLE_AUDIT | This property is used to enable access audit fetching from power bi. | false |
This topic details how to configure PolicySync for Redshift and .
Generalized approach for implementing PolicySync
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: redshift
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
redshift
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above and in the example in Required basic PolicySync topology: always at least one connector instance, replace postgres
with the above.
Redshift Spectrum configuration and security considerations
Redshift Spectrum configuration is similar to Redshift configuration.
Privacera supports access control for Redshift Spectrum only on the following:
Create Database
Usage Schema
Prerequisites
The following prerequisites must be met to use Redshift Spectrum :
You will require an Amazon Redshift cluster and a SQL client connected to the cluster.
The AWS Region in which the Amazon Redshift cluster and Amazon S3 bucket are located must be the same.
Set-up in AWS for Redshift Spectrum
Redshift Spectrum supports the creation of external tables in a Redshift cluster. To configure external tables in Redshift Spectrum, see the following AWS documentation:
Important security considerations for external tables and schemas
Caution
Be advised that row-level filter and column masking via secure views on EXTERNAL SCHEMA
gives a user direct access to the EXTERNAL TABLE
. If a user queries the original external table, row-level filter and column masking are not applied.
Redshift does not natively support access control lists (ACLs) on EXTERNAL TABLES
. To restrict access to the data. You must set USAGE
schema permission on an associated EXTERNAL SCHEMA
.
On an EXTERNAL TABLE
, Privacera supports row-level filter and column masking to a limited extent. Privacera cannot manage external tables. By default, Privacera manages permissions for external schemas only at the schema level.
Because Redshift views inside external schemas cannot be created, instead of creating a table, Privacera creates a secure view with the name of the schema with a default postfix
_secure
. For example, if the original view is namedCUSTOMER
, Privacera creates a secure view namedCUSTOMER_secure.
To
GRANT
access to the secure view, Privacera must grantUSAGE
permission to the source schema because the secure view schema is separated from theEXTERNAL SCHEMA
. As a result, permission is granted to the original source table.Only
SELECT
permission to theEXTERNAL TABLE
is supported.DataAdmin
permission is ineffective becauseUSAGE
permission toEXTERNAL SCHEMA
allows direct access toEXTERNAL TABLE
.
Enable EXTERNAL SCHEMA in Privacera
Note
Because of security concerns for EXTERNAL SCHEMA
, Privacera does not recommend enabling row-level filter and column masking. Be sure you understand the Important security considerations for external tables and schemas.
Property | Description | Default Value | Example |
---|---|---|---|
| Set this property to |
|
|
The values of the following properties must be left blank:
CONNECTOR_REDSHIFT_SECURE_VIEW_NAME_PREFIX: "" CONNECTOR_REDSHIFT_SECURE_VIEW_NAME_POSTFIX: ""
The values of the following properties must be set:
CONNECTOR_REDSHIFT_SECURE_VIEW_SCHEMA_NAME_PREFIX: "" CONNECTOR_REDSHIFT_SECURE_VIEW_SCHEMA_NAME_POSTFIX: "_secure"
These Redshift and Redshift Spectrum connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC properties and then examine the ADVANCED properties to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default Value | Allowable values |
JDBC configuration properties | ||||
BASIC | CONNECTOR_REDSHIFT_JDBC_URL | This property is used to set jdbc jdbc url which can be used to connect to redshift server. JDBC URL should follow below convention jdbc:redshift://<REDSHIFT_SERVER_HOST>:<REDSHIFT_SERVER_PORT> Example :- jdbc:redshift://dev-redshift.xxxxxxxxxxxx.us-east-1.redshift.amazonaws.com:5439 | ||
BASIC | CONNECTOR_REDSHIFT_JDBC_USERNAME | This property is used to set jdbc Username to be used to make connection to redshift. | ||
BASIC | CONNECTOR_REDSHIFT_JDBC_PASSWORD | This property is used to set jdbc username password to be used to make connection to redshift. | ||
BASIC | CONNECTOR_REDSHIFT_JDBC_DB | This property is used to set jdbc database to be used to make initial connection to redshift. | ||
BASIC | CONNECTOR_REDSHIFT_DEFAULT_USER_PASSWORD | This property is used to set password which will be used for every new user creation by policysync. | ||
BASIC | CONNECTOR_REDSHIFT_OWNER_ROLE | This property is used to set ownership for all the resources managed by policysync. The specified role will become owner for all managed resources and will have full control on those resources.We support changing owners of database, schema, tables and views. Note :- If owner role is kept as blank, then ownership will not change and users who creates table/view or any other object he will be owner of those objects and policysync won't be able to do access control on that object | ||
Resources management | ||||
BASIC | CONNECTOR_REDSHIFT_MANAGE_DATABASE_LIST | This property is used to set comma separated database names which access control should be managed by policysync. If you want to manage all databases then you can skip specifying this property. This supports wildcards as well. The ignore database list has precedence over manage database list. Eg. testdb1,testdb2,sales_db* In V1, if you want to manage all databases you have to set this property to blank, this is property behaviour change from V1 to V2. Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_SCHEMA_LIST | This property is used to set comma separated schema Fqdn which access control should be managed by policysync. If you want to manage all schemas then you can skip specifying this property. This supports wildcards as well. The ignore schema list has precedence over manage schema list. Eg. testdb1.schema1,testdb2.schema2,sales_db*.sales* In V1, if you want to manage all schemas you have to set this property to blank, this is property behaviour change from V1 to V2. Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_TABLE_LIST | This property is used to set comma separated table/view Fqdn which access control should be managed by policysync. If you want to manage all tables/views then you can skip specifying this property. This supports wildcards as well. The ignore table list has precedence over manage table list. Eg. testdb1.schema1.table1,testdb2.schema2.view2,sales_db*.sales*.* In V1, if you want to manage all tables/views you have to set this property to blank, this is property behaviour change from V1 to V2. Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_REDSHIFT_IGNORE_DATABASE_LIST | This property is used to set comma separated database names which access control you don't want to be managed by policysync. If you don't want to ignore any database then you can skip specifying this property. This supports wildcards as well. This has precedence over manage database list. Eg. testdb1,testdb2,sales_db* Note: values for this property are case-sensitive. | ||
ADVANCED | CONNECTOR_REDSHIFT_IGNORE_SCHEMA_LIST | This property is used to set comma separated schema fqdn which access control you don't want to be managed by policysync. If you don't want to ignore any schema then you can skip specifying this property. This supports wildcards as well. This has precedence over manage schema list. Eg. testdb1.schema1,testdb2.schema2,sales_db*.sales* Note: values for this property are case-sensitive. | ||
Users/Groups/Roles management | ||||
ADVANCED | CONNECTOR_REDSHIFT_USER_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\[\\]!\\-\\/\\\\{}] | |
ADVANCED | CONNECTOR_REDSHIFT_USER_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_REDSHIFT_GROUP_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a group name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\[\\]!\\-\\/\\\\{}] | |
ADVANCED | CONNECTOR_REDSHIFT_GROUP_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified group name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_REDSHIFT_ROLE_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a role name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\[\\]!\\-\\/\\\\{}] | |
ADVANCED | CONNECTOR_REDSHIFT_ROLE_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified role name regex property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_REDSHIFT_USER_NAME_PERSIST_CASE_SENSITIVITY | After loading user from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_REDSHIFT_GROUP_NAME_PERSIST_CASE_SENSITIVITY | After loading group from Ranger API's all are converted into lowercase, but in some cases, you would need to have the groups in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_REDSHIFT_ROLE_NAME_PERSIST_CASE_SENSITIVITY | After loading role from Ranger API's all are converted into lowercase, but in some cases, you would need to have the roles in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | false | |
ADVANCED | CONNECTOR_REDSHIFT_ENABLE_CASE_SENSITIVE_IDENTIFIER | By default the redshift converts all the resources to lower case, to persist the case we have a property to set on each and every connection. If you follow the same please set this value as true. | false | |
ADVANCED | CONNECTOR_REDSHIFT_ENABLE_CASE_SENSITIVE_IDENTIFIER_QUERY | If CONNECTOR_REDSHIFT_ENABLE_CASE_SENSITIVE_IDENTIFIER is set to true the query will be fired at first in each and every connection. | SET enable_case_sensitive_identifier=true; | |
ADVANCED | CONNECTOR_REDSHIFT_CREATE_USER | This property controls whether we should create user in redshift for users fetched from ranger. | true | |
ADVANCED | CONNECTOR_REDSHIFT_CREATE_USER_ROLE | This property controls whether we should create role over the end user in redshift for users fetched from ranger. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_USERS | This property controls whether policysync should manage the membership between user and user role. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_GROUPS | This property controls whether we should create role in redshift for groups fetched from ranger. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_GROUP_MEMBERS | This property controls whether we should update the members of groups in Redshift for groups fetched from ranger. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_ROLES | This property controls whether we should create role in redshift for roles fetched from ranger. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_ROLE_MEMBERS | This property controls whether we should update the members of roles in Redshift for roles fetched from ranger. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_USER_LIST | This property is used to set comma separated user names which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedence over manage users list. Eg. user1,user2,dev_user* In V1, if you want to manage all users you have to set this property to blank, this is property behaviour change from V1 to V2." | ||
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_GROUP_LIST | This property is used to set comma separated group names which access control should be managed by policysync. If you want to manage all group then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedence over manage group list. Eg. group1,group2,dev_group* In V1, if you want to manage all group you have to set this property to blank, this is property behaviour change from V1 to V2." | ||
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_ROLE_LIST | This property is used to set comma separated role names which access control should be managed by policysync. If you want to manage all role then you can skip specifying this property. This supports wildcards as well. The ignore role list has precedence over manage role list. Eg. role1,role2,dev_role* In V1, if you want to manage all roles you have to set this property to blank, this is property behaviour change from V1 to V2." | ||
ADVANCED | CONNECTOR_REDSHIFT_IGNORE_USER_LIST | This property is used to set comma separated user names which access control you don't want to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedence over manage users list. Eg. user1,user2,dev_user* | ||
ADVANCED | CONNECTOR_REDSHIFT_IGNORE_GROUP_LIST | This property is used to set comma separated group names which access control you don't want to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedence over manage groups list. Eg. group1,group2,dev_group* | ||
ADVANCED | CONNECTOR_REDSHIFT_IGNORE_ROLE_LIST | This property is used to set comma separated role names which access control you don't want to be managed by policysync. If you don't want to ignore any roles then you can skip specifying this property. This supports wildcards as well. This has precedence over manage roles list. Eg. role1,role2,dev_role* | ||
ADVANCED | CONNECTOR_REDSHIFT_USER_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in redshift for user from ranger. For example if you have user named john in ranger and you have defined prefix as test_user_ then the role which we create for john in redshift will have name test_user_john | priv_user_ | |
ADVANCED | CONNECTOR_REDSHIFT_GROUP_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in redshift for group from ranger. For example if you have group named dev in ranger and you have defined prefix as test_group_ then the role which we create for dev in redshift will have name test_group_dev | priv_group_ | |
ADVANCED | CONNECTOR_REDSHIFT_ROLE_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in redshift for role from ranger. For example if you have role named finance in ranger and you have defined prefix as test_role_ then the role which we create for finance in redshift will have name test_role_finance | priv_role_ | |
ADVANCED | CONNECTOR_REDSHIFT_USE_NATIVE_PUBLIC_GROUP | Set this property to true, if you want PolicySync to use redshift native public group for access grants whenever there is policy created referring to public group inside it. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belongs the the groups defined in manage groups list property. | false | |
ADVANCED | CONNECTOR_REDSHIFT_MANAGE_USER_FILTERBY_ROLE | Set this property to true, if you want to manage only the users who belongs the the roles defined in manage roles list property. | false | |
Access control management | ||||
ADVANCED | CONNECTOR_REDSHIFT_ENABLE_VIEW_BASED_MASKING | Set this property to true, if you want to enable secure view based masking in postgres policysync. Note :- Redshift don't support native masking yet, thus recommended to use view based masking. | true | |
ADVANCED | CONNECTOR_REDSHIFT_ENABLE_VIEW_BASED_ROW_FILTER | Set this property to true, if you want to enable secure view based tr filter in redshift policysync. Note :- Redshift support native tr filters, but due to its some limitations we recommended to use view based tr filter. | true | |
ADVANCED | CONNECTOR_REDSHIFT_SECURE_VIEW_CREATE_FOR_ALL | Set this property to true, if you want to create secure view for all tables as well all view which were created by end users. This will create secure view for resource regardless whether there any masking/tr filter policy exists in ranger. | true | |
ADVANCED | CONNECTOR_REDSHIFT_MASKED_NUMBER_VALUE | This property is used to specify the default masking value for numeric columns | 0 | |
ADVANCED | CONNECTOR_REDSHIFT_MASKED_TEXT_VALUE | This property is used to specify the default masking value for text/string columns | <MASKED>' | |
ADVANCED | CONNECTOR_REDSHIFT_SECURE_VIEW_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | ||
ADVANCED | CONNECTOR_REDSHIFT_SECURE_VIEW_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | _secure | |
ADVANCED | CONNECTOR_REDSHIFT_SECURE_VIEW_SCHEMA_NAME_PREFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} | ||
ADVANCED | CONNECTOR_REDSHIFT_SECURE_VIEW_SCHEMA_NAME_POSTFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} | ||
BASIC | CONNECTOR_REDSHIFT_GRANT_UPDATES | This property controls whether actual grant/revoke and create/update/delete queries for user/group/role should be run on redshift. | false | |
ADVANCED | CONNECTOR_REDSHIFT_ENABLE_DATA_ADMIN | This property is used to enable data admin feature, with data admin feature enabled you can create all the policies on table/native view and by default respective grants will be maid on secure view of table table or native view. And this secure view will have tr filter and masking capability as well. In case if you need permission on table then you can select the permission you want plus dataadmin in the policy, In this case that permissions will be granted on both, the table/native view and its secure view as well | true | |
Access audits management | ||||
BASIC | CONNECTOR_REDSHIFT_AUDIT_ENABLE | This property is used to enable access audit fetching from redshift | false | |
ADVANCED | CONNECTOR_REDSHIFT_AUDIT_EXCLUDED_USERS | This property is used to set the list of users whose access audits we want to ignore. It takes list of comma separated users. | ||
ADVANCED | CONNECTOR_REDSHIFT_AUDIT_INITIAL_PULL_MINUTES | When the audits are enabled for the first time, the value will decide the number of minutes we need to pull the access audits from the database, default value is 30 mins | 30 |
Before configuring Snowflake with Privacera Manager, you must first manually create the Snowflake warehouse, database, users, and roles required by PolicySync. All of this can be accomplished by manually executing SQL queries.
Note
Log in to Snowflake as a user with ACCOUNTADMIN privileges.
Creating PolicySync role
The PRIVACERA_POLICYSYNC_ROLE
role, which we will create in this step, will be used in the SNOWFLAKE_ROLE_TO_USE
property when configuring Snowflake with Privacera Manager.
Drop a role.
DROP ROLE IF EXISTS "PRIVACERA_POLICYSYNC_ROLE";
Create a role.
CREATE ROLE IF NOT EXISTS "PRIVACERA_POLICYSYNC_ROLE";
Grant this role permission to users to create/update/delete roles.
GRANT ROLE USERADMIN TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role, allowing them to provide grants/revokes privileges on user/roles to create warehouse/database on account.
GRANT ROLE SYSADMIN TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role so that it can manage grants for snowflake resources.
GRANT MANAGE GRANTS ON ACCOUNT TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role so that it can create native Masking policies.
GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role so that it can create native row filter policies.
GRANT APPLY ROW ACCESS POLICY ON ACCOUNT TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Creating a warehouse
The PRIVACERA_POLICYSYNC_WH
warehouse, which we will create in this step, will be used in the SNOWFLAKE_WAREHOUSE_TO_USE
property when configuring Snowflake with Privacera Manager.
Create a warehouse for PolicySync. Change the warehouse size according to deployment.
CREATE WAREHOUSE IF NOT EXISTS "PRIVACERA_POLICYSYNC_WH" WITH WAREHOUSE_SIZE='XSMALL'WAREHOUSE_TYPE='STANDARD'AUTO_SUSPEND=600AUTO_RESUME= TRUE MIN_CLUSTER_COUNT=1MAX_CLUSTER_COUNT=1SCALING_POLICY='ECONOMY';
Granting role permission to read access audits
To get read access audit permission on the Snowflake database, follow the steps below.
Grant warehouse usage access so we can query the snowflake database and get the Access Audits.
GRANT USAGE ON WAREHOUSE "PRIVACERA_POLICYSYNC_WH" TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant our role
PRIVACERA_POLICYSYNC_ROLE
to read Access Audits in the snowflake database.GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Creating database for Privacera UDFs
The database name PRIVACERA_DB
will be used in the SNOWFLAKE_JDBC_DB
property when configuring Snowflake with Privacera Manager.
This step is optional. If you already have the database and want to use it, you can skip this step.
CREATE DATABASE IF NOT EXISTS "PRIVACERA_DB";
Grant our role
PRIVACERA_POLICYSYNC_ROLE
database access so that we can create UDFs in the database.GRANT ALL ON DATABASE "PRIVACERA_DB" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"; GRANT ALL ON ALL SCHEMAS IN DATABASE "PRIVACERA_DB" TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Creating user
The user which we will create in this step will be used in the SNOWFLAKE_JDBC_USERNAME
and SNOWFLAKE_JDBC_PASSWORD
properties when configuring Snowflake with Privacera Manager.
Create a user
CREATE USER IF NOT EXISTS "PRIVACERA_POLICYSYNC_USER"PASSWORD='<PLEASE_CHANGE>'MUST_CHANGE_PASSWORD=FALSE DEFAULT_WAREHOUSE="PRIVACERA_POLICYSYNC_WH"DEFAULT_ROLE="PRIVACERA_POLICYSYNC_ROLE";
Grant the user the
PRIVACERA_POLICYSYNC_ROLE
role.GRANT ROLE "PRIVACERA_POLICYSYNC_ROLE" TO USER "PRIVACERA_POLICYSYNC_USER";
Creating owner role
By configuring the following property in vars.policysync.snowflake.yml
, PolicySync can take ownership of all objects managed by it. PolicySync requires this in order to create row-filtering and column-Masking policies.
SNOWFLAKE_OWNER_ROLE:"PRIVACERA_POLICYSYNC_ROLE"
Note
If PolicySync is not configured to take ownership of all objects managed by PolicySync, keep the property value blank.
SNOWFLAKE_OWNER_ROLE:""
Masking and row level filtering
To run the Masking and Row Level Filter, the following permissions must be granted to each database managed by PolicySync. <DATABASE_NAME>
must be replaced with the specific value.
GRANT ALL ON DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"; GRANT ALL ON ALL SCHEMAS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"; GRANT ALL ON FUTURE SCHEMAS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON ALL TABLES IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON FUTURE TABLES IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON ALL VIEWS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON FUTURE VIEWS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"
Using reduced permissions for existing PolicySync
If Privacera PolicySync is currently configured with ACCOUNTADMIN privileges, the steps below must be completed as an ACCOUNTADMIN in order for PolicySync to work with the reduced permissions specified in the previous sections.
Drop UDFs.
DROP FUNCTION IF EXISTS "<DATABASE_NAME>"."PUBLIC".ThrowColumnAccessException(string);
Note
For PolicySync versions 4.7 or earlier,
<DATABASE_NAME>
must be replaced with the value provided in configurationjdbc.db
.For PolicySync versions 5.0 or later:
<DATABASE_NAME>
must be replaced with the value provided in configurationranger.policysync.connector.snowflake.masking.functions.db.name
.
Drop row level filter access policies.
DROP ROW ACCESS POLICY IF EXISTS "<DATABASE_NAME>"."<SCHEMA_NAME>"."<ROW_ACCESS_POLICY_NAME>";
Note
For PolicySync version 4.7:
Row Level Filter access policies must be deleted in all databases and schemas managed by PolicySync.
The following is the format of a Row Level Filter access policy name: :
{database}_{schema}_{table}_row_filter_policy
.For example,
"db1_sch1_tbl1_row_filter_policy"
For PolicySync versions 5.0 or later:
If PolicySync is configured to create Row Level Filter access policies in a specific database and schema (see below), Row Level Filter access policies must be deleted from the specified database and schema.
ranger.policysync.connector.snowflake.row.filter.policy.db.name
ranger.policysync.connector.snowflake.row.filter.policy.schema.name
Or else, Row Level Filter access policies in all databases and schemas managed by PolicySync must be deleted.
The following is the format of a Row Level Filter access policy name: :
{database}{separator}{schema}{separator}{table}
.For example,
"db1_PRIV_sch1_PRIV_tbl1"
.
Use the following command to list Row Level Filter access policies:
SHOW ROW ACCESS POLICIES;
Drop masking policies.
DROP MASKING POLICY IF EXISTS "<DATABASE_NAME>"."<SCHEMA_NAME>"."<MASKING_POLICY_NAME>";
Note
For PolicySync versions 4.7 or earlier:
Masking policies must be deleted in all databases and schemas managed by PolicySync.
The following is the format of a Masking policy name:
{table}{separator}{column}
.For example,
"tbl1_priv_col1"
For PolicySync versions 5.0 or later:
If PolicySync is configured to create Masking policies in a specific database and schema (see below), Masking policies must be deleted from the specified database and schema.
ranger.policysync.connector.snowflake.masking.policy.db.name
ranger.policysync.connector.snowflake.masking.policy.schema.name
Or else, Masking policies in all databases and schemas managed by PolicySync must be deleted.
The following is the format of a Masking policy name:
{database}{separator}{schema}{separator}{table}{separator}{column}
.For example,
"db1_PRIV_sch1_PRIV_tbl1_PRIV_col1"
.
Use the following command to list all masking policies:
SHOW MASKING POLICIES;
This topic covers how to configure Snowflake PolicySync access control using Privacera Manager
Before configuring Snowflake with Privacera Manager, you must first manually create the Snowflake warehouse, database, users, and roles required by PolicySync. All of this can be accomplished by manually executing SQL queries.
Note
Log in to Snowflake as a user with ACCOUNTADMIN privileges.
Creating PolicySync role
The PRIVACERA_POLICYSYNC_ROLE
role, which we will create in this step, will be used in the SNOWFLAKE_ROLE_TO_USE
property when configuring Snowflake with Privacera Manager.
Drop a role.
DROP ROLE IF EXISTS "PRIVACERA_POLICYSYNC_ROLE";
Create a role.
CREATE ROLE IF NOT EXISTS "PRIVACERA_POLICYSYNC_ROLE";
Grant this role permission to users to create/update/delete roles.
GRANT ROLE USERADMIN TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role, allowing them to provide grants/revokes privileges on user/roles to create warehouse/database on account.
GRANT ROLE SYSADMIN TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role so that it can manage grants for snowflake resources.
GRANT MANAGE GRANTS ON ACCOUNT TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role so that it can create native Masking policies.
GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant this permission to the role so that it can create native row filter policies.
GRANT APPLY ROW ACCESS POLICY ON ACCOUNT TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Creating a warehouse
The PRIVACERA_POLICYSYNC_WH
warehouse, which we will create in this step, will be used in the SNOWFLAKE_WAREHOUSE_TO_USE
property when configuring Snowflake with Privacera Manager.
Create a warehouse for PolicySync. Change the warehouse size according to deployment.
CREATE WAREHOUSE IF NOT EXISTS "PRIVACERA_POLICYSYNC_WH" WITH WAREHOUSE_SIZE='XSMALL'WAREHOUSE_TYPE='STANDARD'AUTO_SUSPEND=600AUTO_RESUME= TRUE MIN_CLUSTER_COUNT=1MAX_CLUSTER_COUNT=1SCALING_POLICY='ECONOMY';
Granting role permission to read access audits
To get read access audit permission on the Snowflake database, follow the steps below.
Grant warehouse usage access so we can query the snowflake database and get the Access Audits.
GRANT USAGE ON WAREHOUSE "PRIVACERA_POLICYSYNC_WH" TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Grant our role
PRIVACERA_POLICYSYNC_ROLE
to read Access Audits in the snowflake database.GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Creating database for Privacera UDFs
The database name PRIVACERA_DB
will be used in the SNOWFLAKE_JDBC_DB
property when configuring Snowflake with Privacera Manager.
This step is optional. If you already have the database and want to use it, you can skip this step.
CREATE DATABASE IF NOT EXISTS "PRIVACERA_DB";
Grant our role
PRIVACERA_POLICYSYNC_ROLE
database access so that we can create UDFs in the database.GRANT ALL ON DATABASE "PRIVACERA_DB" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"; GRANT ALL ON ALL SCHEMAS IN DATABASE "PRIVACERA_DB" TO ROLE "PRIVACERA_POLICYSYNC_ROLE";
Creating user
The user which we will create in this step will be used in the SNOWFLAKE_JDBC_USERNAME
and SNOWFLAKE_JDBC_PASSWORD
properties when configuring Snowflake with Privacera Manager.
Create a user
CREATE USER IF NOT EXISTS "PRIVACERA_POLICYSYNC_USER"PASSWORD='<PLEASE_CHANGE>'MUST_CHANGE_PASSWORD=FALSE DEFAULT_WAREHOUSE="PRIVACERA_POLICYSYNC_WH"DEFAULT_ROLE="PRIVACERA_POLICYSYNC_ROLE";
Grant the user the
PRIVACERA_POLICYSYNC_ROLE
role.GRANT ROLE "PRIVACERA_POLICYSYNC_ROLE" TO USER "PRIVACERA_POLICYSYNC_USER";
Creating owner role
By configuring the following property in vars.policysync.snowflake.yml
, PolicySync can take ownership of all objects managed by it. PolicySync requires this in order to create row-filtering and column-Masking policies.
SNOWFLAKE_OWNER_ROLE:"PRIVACERA_POLICYSYNC_ROLE"
Note
If PolicySync is not configured to take ownership of all objects managed by PolicySync, keep the property value blank.
SNOWFLAKE_OWNER_ROLE:""
Masking and row level filtering
To run the Masking and Row Level Filter, the following permissions must be granted to each database managed by PolicySync. <DATABASE_NAME>
must be replaced with the specific value.
GRANT ALL ON DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"; GRANT ALL ON ALL SCHEMAS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"; GRANT ALL ON FUTURE SCHEMAS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON ALL TABLES IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON FUTURE TABLES IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON ALL VIEWS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE" GRANT ALL ON FUTURE VIEWS IN DATABASE "<DATABASE_NAME>" TO ROLE "PRIVACERA_POLICYSYNC_ROLE"
Generalized approach for implementing PolicySync
Use this generalized approach for implementing PolicySync.
Understand how PolicySync works and how it is configured. See PolicySync design and configuration.
Decide which PolicySync topology best suits your needs:
Create the required, basic PolicySync configuration. See Required basic PolicySync topology: always at least one connector instance
Examine the BASIC and ADVANCED properties, decide which features you want to implement, and set the necessary values in the YAML property file.
Connector name: snowflake
When you create the connector as detailed in PolicySync design and configuration, use the following reserved word for the name of the connector:
snowflake
In formal syntax shown in Connector instance directory/file structure replace <ConnectorName>
with the above and in the example in Required basic PolicySync topology: always at least one connector instance, replace postgres
with the above.
Optional Basic Authentication for PolicySync
To optionally enable basic authenticate for PolicySync to Snowflake you can create a JSON file in your connector instance subdirectory.
The name of the file must be XXX.json
.
An example of the contents of XXX.json
.:
{ "type": "service_account", "project_id": "your_project_id", "private_key_id": "autogenerated_value", "private_key": "-----BEGIN PRIVATE KEY-----autogenerated_value-----END PRIVATE KEY-----\n", "client_email": "autogenerated_value", "client_id": "autogenerated_value", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/autogenerated_value" }
These Snowflake connector properties can be set for PolicySync in Privacera Platform.
The properties are grouped by general function, such as JDBC connection properties, properties for user, group, and role management, and other functions.
The properties are also categorized as BASIC or ADVANCED:
BASIC pertains to the most fundamental aspects of the connector, such as authentication.
ADVANCED indicates additional features beyond the BASICs, such as row-filtering or group member handling.
Start by setting the BASIC properties and then examine the ADVANCED properties to determine which of these features you might want to enable.
For a general process to migrate values from old YAML files to the new YAML files, see Migration to PolicySync v2 on Privacera Platform 7.2.
Category | Property name | Description | Default | Allowable values |
JDBC configuration properties | ||||
BASIC | CONNECTOR_SNOWFLAKE_JDBC_URL | This property is used to set the JDBC URL, which can be used to connect to the Snowflake server. The JDBC URL should be formatted as follows: jdbc:snowflake://testsnowflake.snowflakecomputing.com/?warehouse=<WAREHOUSE_TO_USE>&role=<ROLE_TO_USE> Example :- jdbc:snowflake://testsnowflake.snowflakecomputing.com/?warehouse=PRIVACERA_POLICYSYNC_WH&role=PRIVACERA_SYNC_ROLE | ||
BASIC | CONNECTOR_SNOWFLAKE_JDBC_USERNAME | This property is used to specify the JDBC username that will be used to connect to Snowflake. | ||
BASIC | CONNECTOR_SNOWFLAKE_JDBC_PASSWORD | This property is used to specify the JDBC username password that will be used to connect to Snowflake. | ||
BASIC | CONNECTOR_SNOWFLAKE_WAREHOUSE_TO_USE | This property is used to specify which JDBC warehouse will be used to establish a connection in order to run SQL queries on Snowflake. | ||
BASIC | CONNECTOR_SNOWFLAKE_ROLE_TO_USE | This property is used to specify the Snowflake role that will be used to run SQL queries on Snowflake. | ||
BASIC | CONNECTOR_SNOWFLAKE_OWNER_ROLE | This property is used to specify who owns all of the resources managed by policysync. The specified role will become the owner of all managed resources and will have complete control over those resources. We support changing the owner of a database, schema, tables, and views.Generally value of this should be same as SNOWFLAKE_ROLE_TO_USE property value to be used to execute queries. NOTE: If the owner role is left blank, ownership will not change, and users who create tables/views or other objects will be the owner of those objects, and policysync will not be able to control access to those objects. | "" | |
BASIC | CONNECTOR_SNOWFLAKE_MANAGE_WAREHOUSE_LIST | This property is used to specify the names of comma-separated warehouses for which policysync should manage access control. If you want to manage all warehouses, you can skip this property. This also works with wildcards. The ignore warehouses list takes precedence over the manage warehouses list. For example, testdb1warehouse, testdb2warehouse, sales dbwarehouse*. **NOTE: values for this property are case-sensitive. | "" | |
BASIC | CONNECTOR_SNOWFLAKE_MANAGE_DATABASE_LIST | This property is used to specify comma-separated database names for which policysync should manage 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* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_SCHEMA_LIST | This property is used to set comma separated schema Fqdn which access control should be managed by policysync. If you want to manage all schemas then you can skip specifying this property. This supports wildcards as well. The ignore schema list has precedence over manage schema list. Eg. testdb1.schema1,testdb2.schema2,sales_db*.sales* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_TABLE_LIST | This property is used to set comma separated table/view Fqdn which access control should be managed by policysync. If you want to manage all tables/views then you can skip specifying this property. This supports wildcards as well. The ignore table list has precedence over manage table list. Eg. testdb1.schema1.table1,testdb2.schema2.view2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_STREAM_LIST | This property is used to set comma separated streams Fqdn which access control should be managed by policysync. If you want to manage all streams then you can skip specifying this property. This supports wildcards as well. The ignore streams list has precedence over manage streams list. Eg. testdb1.schema1.streams1,testdb2.schema2.streams2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_FUNCTION_LIST | This property is used to set comma separated functions Fqdn which access control should be managed by policysync. If you want to manage all functions then you can skip specifying this property. This supports wildcards as well. The ignore functions list has precedence over manage functions list. Eg. testdb1.schema1.functions1,testdb2.schema2.functions2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_PROCEDURE_LIST | This property is used to set comma separated procedures Fqdn which access control should be managed by policysync. If you want to manage all procedures then you can skip specifying this property. This supports wildcards as well. The ignore procedures list has precedence over manage procedures list. Eg. testdb1.schema1.procedures1,testdb2.schema2.procedures2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_SEQUENCE_LIST | This property is used to set comma separated sequences Fqdn which access control should be managed by policysync. If you want to manage all sequences then you can skip specifying this property. This supports wildcards as well. The ignore sequences list has precedence over manage sequences list. Eg. testdb1.schema1.sequence1,testdb2.schema2.sequence2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_FILE_FORMAT_LIST | This property is used to set comma separated FileFormats Fqdn which access control should be managed by policysync. If you want to manage all FileFormats then you can skip specifying this property. This supports wildcards as well. The ignore FileFormats list has precedence over manage FileFormats list. Eg. testdb1.schema1.FileFormat1,testdb2.schema2.FileFormat2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_PIPE_LIST | This property is used to set comma separated pipes Fqdn which access control should be managed by policysync. If you want to manage all pipes then you can skip specifying this property. This supports wildcards as well. The ignore pipes list has precedence over manage pipes list. Eg. testdb1.schema1.pipe1,testdb2.pipe2.FileFormat2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_EXTERNAL_STAGE_LIST | This property is used to set comma separated ExternalStage Fqdn which access control should be managed by policysync. If you want to manage all ExternalStage then you can skip specifying this property. This supports wildcards as well. The ignore ExternalStage list has precedence over manage ExternalStage list. Eg. testdb1.schema1.ExternalStage1,testdb2.ExternalStage2.FileFormat2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_INTERNAL_STAGE_LIST | This property is used to set comma separated InternalStage Fqdn which access control should be managed by policysync. If you want to manage all InternalStage then you can skip specifying this property. This supports wildcards as well. The ignore InternalStage list has precedence over manage InternalStage list. Eg. testdb1.schema1.InternalStage1,testdb2.InternalStage2.FileFormat2,sales_db*.sales*.* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_IGNORE_WAREHOUSE_LIST | This property is used to set comma separated warehouse names which access control you don't want to be managed by policysync. If you don't want to ignore any warehouse then you can skip specifying this property. This supports wildcards as well. This has precedence over manage warehouse list. Eg. testdb1warehouse,testdb2warehouse,sales_dbwarehouse* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_IGNORE_DATABASE_LIST | This property is used to set comma separated database names which access control you don't want to be managed by policysync. If you don't want to ignore any database then you can skip specifying this property. This supports wildcards as well. This has precedence over manage database list. Eg. testdb1,testdb2,sales_db* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_IGNORE_SCHEMA_LIST | This property is used to set comma separated schema fqdn which access control you don't want to be managed by policysync. If you don't want to ignore any schema then you can skip specifying this property. This supports wildcards as well. This has precedence over manage schema list. Eg. testdb1.schema1,testdb2.schema2,sales_db*.sales* **NOTE: values for this property are case-sensitive. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_CREATE_USER | This property controls whether we should create user in snowflake for users fetched from portal. | ||
ADVANCED | CONNECTOR_SNOWFLAKE_CREATE_USER_ROLE | This property controls whether we should create role over the end user in snowflake for users fetched from portal. | {{ SNOWFLAKE_ENTITY_ROLE_PREFIX }}user_ | |
ADVANCED | CONNECTOR_SNOWFLAKE_USER_LOGIN_NAME_USE_EMAIL | This property controls whether email id should be used as login name while creating new user in snowflake. | {{ SNOWFLAKE_ENTITY_ROLE_PREFIX }}group_ | |
BASIC | CONNECTOR_SNOWFLAKE_DEFAULT_USER_PASSWORD | This property is used to specify the password that will be used by any new user created by PolicySync in Snowflake. | {{ SNOWFLAKE_ENTITY_ROLE_PREFIX }}role_ | |
ADVANCED | CONNECTOR_SNOWFLAKE_USER_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in snowflake for user from ranger. For example if you have user named john in ranger and you have defined prefix as test_user_ then the role which we create for john in snowflake will have name test_user_john | {{ SNOWFLAKE_ENTITY_ROLE_POSTFIX }} | |
ADVANCED | CONNECTOR_SNOWFLAKE_GROUP_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in snowflake for group from ranger. For example if you have group named dev in ranger and you have defined prefix as test_group_ then the role which we create for dev in snowflake will have name test_group_dev | {{ SNOWFLAKE_ENTITY_ROLE_POSTFIX }} | |
ADVANCED | CONNECTOR_SNOWFLAKE_ROLE_ROLE_PREFIX | This property is used to set a prefix for role which we will be creating in snowflake for role from ranger. For example if you have role named finance in ranger and you have defined prefix as test_role_ then the role which we create for finance in snowflake will have name test_role_finance | {{ SNOWFLAKE_ENTITY_ROLE_POSTFIX }} | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_USERS | This property controls whether policysync should manage the membership between user and user role. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_GROUPS | This property controls whether we should create role in snowflake for groups fetched from ranger. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_ROLES | This property controls whether we should create role in snowflake for roles fetched from ranger. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_USER_LIST | This property is used to set comma separated user names which access control should be managed by policysync. If you want to manage all users then you can skip specifying this property. This supports wildcards as well. The ignore users list has precedence over manage users list. Eg. user1,user2,dev_user* | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_GROUP_LIST | This property is used to set comma separated group names which access control should be managed by policysync. If you want to manage all group then you can skip specifying this property. This supports wildcards as well. The ignore group list has precedence over manage group list. Eg. group1,group2,dev_group* | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_ROLE_LIST | This property is used to set comma separated role names which access control should be managed by policysync. If you want to manage all role then you can skip specifying this property. This supports wildcards as well. The ignore role list has precedence over manage role list. Eg. role1,role2,dev_role* | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_IGNORE_USER_LIST | This property is used to set comma separated user names which access control you don't want to be managed by policysync. If you don't want to ignore any users then you can skip specifying this property. This supports wildcards as well. This has precedence over manage users list. Eg. user1,user2,dev_user* | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_SNOWFLAKE_IGNORE_GROUP_LIST | This property is used to set comma separated group names which access control you don't want to be managed by policysync. If you don't want to ignore any groups then you can skip specifying this property. This supports wildcards as well. This has precedence over manage groups list. Eg. group1,group2,dev_group* | _ | |
ADVANCED | CONNECTOR_SNOWFLAKE_IGNORE_ROLE_LIST | This property is used to set comma separated role names which access control you don't want to be managed by policysync. If you don't want to ignore any roles then you can skip specifying this property. This supports wildcards as well. This has precedence over manage roles list. Eg. role1,role2,dev_role* | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_SNOWFLAKE_USER_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a user name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_SNOWFLAKE_USER_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified user name regex property. If kept blank, no find and replace operation is performed. | [~`$&+:;=?@#|'<>.^*()_%\\\\[\\\\]!\\\\-\\\\/\\\\\\\\{}] | |
ADVANCED | CONNECTOR_SNOWFLAKE_GROUP_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a group name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | _ | |
ADVANCED | CONNECTOR_SNOWFLAKE_GROUP_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified group name regex property. If kept blank, no find and replace operation is performed. | false | true/false |
ADVANCED | CONNECTOR_SNOWFLAKE_ROLE_NAME_REPLACE_FROM_REGEX | This takes the regular expression as input and finds the matching characters in a role name and replaces them with the characters specified in property. If kept blank, no find and replace operation is performed. | false | true/false |
ADVANCED | CONNECTOR_SNOWFLAKE_ROLE_NAME_REPLACE_TO_STRING | The value specified in this property is used to replace the characters found by the regex specified role name regex property. If kept blank, no find and replace operation is performed. | false | true/false |
ADVANCED | CONNECTOR_SNOWFLAKE_USER_NAME_PERSIST_CASE_SENSITIVITY | After loading user from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | lower | none, lower, upper |
ADVANCED | CONNECTOR_SNOWFLAKE_GROUP_NAME_PERSIST_CASE_SENSITIVITY | After loading group from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | lower | none, lower, upper |
ADVANCED | CONNECTOR_SNOWFLAKE_ROLE_NAME_PERSIST_CASE_SENSITIVITY | After loading role from Ranger API's all are converted into lowercase, but in some cases, you would need to have the users in the same case as they are in Ranger. When setting this value to true, it will maintain the case sensitivity of names as they are in Ranger. | lower | none, lower, upper |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_USER_FILTERBY_GROUP | Set this property to true, if you want to manage only the users who belongs to the groups defined in manage groups list property. | false | true/false |
ADVANCED | CONNECTOR_SNOWFLAKE_MANAGE_USER_FILTERBY_ROLE | Set this property to true, if you want to manage only the users who belongs to the roles defined in manage roles list property. | false | true/false |
BASIC | CONNECTOR_SNOWFLAKE_GRANT_UPDATES | This property controls whether actual grant/revoke and create/update/delete queries for user/group/role should be run on snowflake. | false | true/false |
ADVANCED | CONNECTOR_SNOWFLAKE_ENABLE_COLUMN_ACCESS_EXCEPTION | This property controls whether to show access denied exception when user doesn't have access some column of table and trying to access that column. In order to set this property value to true, you should also have enable.masking property value as false. | PUBLIC | |
ADVANCED | CONNECTOR_SNOWFLAKE_ENABLE_MASKING | This property controls whether to enable native masking policy creation functionality in policysync. | {database}{separator}{schema}{separator}{table} | |
ADVANCED | CONNECTOR_SNOWFLAKE_MASKING_POLICY_DB_NAME | This property is used to set the database name in which policysync should create custom masking policies | ||
ADVANCED | CONNECTOR_SNOWFLAKE_MASKING_POLICY_SCHEMA_NAME | This property is used to set the schema name in which policysync should create all native masking policies, if this is kept as blank then it will consider the resource schema as masking policy schema | TRUE | |
BASIC | CONNECTOR_SNOWFLAKE_MASKING_POLICY_DB_NAME | This property is used to set the database name in which policysync should create custom masking functions | PUBLIC | |
ADVANCED | CONNECTOR_SNOWFLAKE_ENABLE_ROW_FILTER | This property controls whether to enable native tr filter policy creation functionality in policysync. | {database}{separator}{schema}{separator}{table} | |
ADVANCED | CONNECTOR_SNOWFLAKE_ROW_FILTER_POLICY_DB_NAME | This property is used to set the database name in which policysync should create all native tr filter policies, if this is kept as blank then it will consider the resource database as tr filter policy database | FALSE | |
ADVANCED | CONNECTOR_SNOWFLAKE_ROW_FILTER_POLICY_SCHEMA_NAME | This property is used to set the schema name in which policysync should create all native tr filter policies, if this is kept as blank then it will consider the resource schema as tr filter policy schema | FALSE | |
ADVANCED | CONNECTOR_SNOWFLAKE_ENABLE_VIEW_BASED_ROW_FILTER | Set this property to true, if you want to enable secure view based tr filter in postgres policysync. Note :- Postgres support native tr filters, but due to its some limitations we recommended to use view based tr filter. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_ENABLE_VIEW_BASED_MASKING | Set this property to true, if you want to enable secure view based masking in postgres policysync. Note :- Postgres don't support native masking yet, thus recommended to use view based masking. | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_SECURE_VIEW_SCHEMA_NAME_PREFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} For {view_schema_name} refer to variable POSTGRES_SECURE_VIEW_SCHEMA_NAME | _SECURE | |
ADVANCED | CONNECTOR_SNOWFLAKE_SECURE_VIEW_SCHEMA_NAME_POSTFIX | By default view-based tr 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 and postfix, that can be done with these properties. After prefix and postfix is specified the view schema name will be in this format : {prefix}{view_schema_name}{postfix} For {view_schema_name} refer to variable POSTGRES_SECURE_VIEW_SCHEMA_NAME | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_SECURE_VIEW_NAME_PREFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | "" | |
ADVANCED | CONNECTOR_SNOWFLAKE_SECURE_VIEW_NAME_POSTFIX | By default view-based tr filter and masking related secure views have the same name as the table name with postfixed by _secure. If you want to change the secure view name prefix and postfix, that can be done with these properties. After prefix and postfix is specified the view name will be in this format : {prefix}{table_name}{postfix} | FALSE | |
ADVANCED | CONNECTOR_SNOWFLAKE_SECURE_VIEW_CREATE_FOR_ALL | Set this property to true, if you want to create secure view for all tables as well all view which were created by end users. This will create secure view for resource regardless whether there any masking/tr filter policy exists in ranger. | ||
ADVANCED | CONNECTOR_SNOWFLAKE_MASKED_NUMBER_VALUE | This property is used to set the value of the masked column of datatype number | public | |
ADVANCED | CONNECTOR_SNOWFLAKE_MASKED_TEXT_VALUE | This property is used to set the value of the masked column of datatype text | load_md - Load the users from the snowflake using metadata queries | |
BASIC | CONNECTOR_SNOWFLAKE_AUDIT_ENABLE | This property enables access audits | PRIVACERA_ACCESS_LOGS_DB | |
BASIC | CONNECTOR_SNOWFLAKE_ENABLE_AUDIT_SOURCE_SIMPLE | This property is used to fetch simple access audits queried on DB | 60 | |
BASIC | CONNECTOR_SNOWFLAKE_ENABLE_AUDIT_SOURCE_ADVANCE | This property is used to fetch advance access audits queried on DB | 420 |