Configuring Privacera PolicySync Connectors¶

This guide explains the common configuration settings for Privacera PolicySync connectors. Understanding these settings is essential for ensuring the connectors work correctly and are set up optimally.

Important: While this guide covers common settings, each connector type (e.g., Snowflake, Databricks) has specific properties. Always refer to the documentation for the individual connector you are configuring for complete details.

You can configure PolicySync connectors using different methods depending on your Privacera deployment:

Overview of Common Configuration Areas¶

Most PolicySync connectors share the following categories of configuration settings. The sections below explain each area in more detail. Remember to check the specific connector's documentation for settings unique to that connector.

Connection Details¶

Each PolicySync connector needs configuration details to securely connect and authenticate to the target data service it manages. Common methods include:

• JDBC Connection String: Often used with a username/password or an authentication token.
• IAM Roles: Used by some cloud connectors (e.g., AWS Lake Formation) for authentication based on assigned cloud roles.

Refer to the specific connector's documentation for the exact connection parameters required.

You should provision a dedicated service user account for the connector within the target data service. Ensure this account has the required privileges to manage policies (create, modify, delete). Using a service account rather than a personal administrator account is recommended as it helps avoid confusion when investigating issues.

Policy Enforcement Scope¶

These settings define what the connector manages: which data resources and which users/groups/roles (principals).

Managed Resources List¶

This configuration specifies the exact data resources (like databases, schemas, tables, views) the connector is responsible for managing policies on. You define this scope using include/exclude patterns:

• Include Patterns: Define which resources the connector should manage. You can start with a small set and expand later.
• Exclude Patterns: Define specific resources the connector should ignore. This is useful for system tables, temporary resources, or resources the connector lacks permissions to manage.
• Manage All: You can configure the connector to manage all compatible resources discovered in the target data service.

The connector loads metadata only for the managed resources and applies Privacera policies to them.

Managed Principals for Policy Enforcement¶

Privacera policies are defined using Privacera users, groups, and roles (collectively called "principals"). The PolicySync connector translates these policies into commands (like GRANT/REVOKE or security policies) that the target system understands, applying them to corresponding principals within that target system.

For every Privacera user, group and role, a corresponding principal in the target system is used for assigning the grants. Most connectors create a group or role in the target system for every Privacera user, group or role using the mapping rules.

• Filtering Principals: You can configure the connector to only consider a subset of Privacera principals for policy enforcement. Use include/exclude patterns for users, groups, or roles.
  • Use Case: This is helpful if you want to exclude certain application or service users from being managed by the connector.
• Filtering Users by Membership: You can further refine user scope by telling the connector to only manage users who belong to specific managed groups or roles. Set one of these properties to true:
  • CONNECTOR_<TYPE>_MANAGE_USER_FILTERBY_GROUP=true
  • CONNECTOR_<TYPE>_MANAGE_USER_FILTERBY_ROLE=true
  • (If both are set to true, filtering by group takes precedence).
• Principal Mapping Rules: Privacera principals might have names or characters not supported by the target data service. Mapping rules automatically translate Privacera principal names into valid names for the target system.
  • Character Replacement: Replace unsupported characters (e.g., - becomes _).
  • Prefixing: Add a prefix (e.g., priv_role_) to easily identify principals managed by Privacera within the target system.
  • Example: A Privacera role PROD-DATA-ANALYST might be mapped to a target system group named priv_role_prod_data_analyst.

Managed Principals in Target Service¶

You can optionally configure the PolicySync connector to automatically create and manage the necessary users, groups, or roles directly in the target data service, based on the mapped Privacera principals.

• Enabled: The connector uses the mapping rules and prefix settings to create/manage principals (e.g., creates the priv_role_prod_data_analyst group in the target) and manage memberships (e.g., adds target users to this group).
• Disabled: If you disable this feature, you are responsible for manually creating the required users, groups, or roles (with the correctly mapped names) in the target data service and managing their memberships.

For organizations using multiple PolicySync connectors, we recommend disabling the connector's automatic creation and management of users, groups, or roles in the target data service. Typically, enterprises prefer to manage identity provisioning through their own established processes or central systems.

Fine-Grained Access Control Methods (Column/Row Level)¶

For implementing column-level and row-level security policies, PolicySync connectors typically offer two approaches:

1. Native Security Features: Utilizes the target data service's built-in capabilities (like row access policies, column masking). Recommended if supported by the connector and target data service, as it's often more performant and integrated.
2. Privacera Secure Views: The connector creates secure views in the target data service to enforce the policies. This is used when native features are unavailable or not chosen.

Refer to the specific connector's documentation to see which methods it supports. For more on secure views, see About Secure Views.

Synchronization Intervals¶

These settings control how often the PolicySync connector performs various background tasks to keep Privacera and the target data service synchronized. Setting appropriate intervals balances policy timeliness with performance and resource consumption (e.g., warehouse compute).

Resource Sync Interval¶

• What it does: CONNECTOR_<TYPE>_RESOURCE_SYNC_INTERVAL defines how often the connector checks the target data service for new or modified managed resources (e.g., a new table matching the include patterns). When changes are detected, the connector evaluates and applies the relevant Privacera policies (e.g., issues GRANTs).
• Considerations: A shorter interval means faster detection and policy application for new resources, but increases frequency of checks and potential compute usage on the target data service.
• Event-Based Alternative: Some connectors support event-driven updates (via API calls to the Ops-server) instead of, or in addition to, polling intervals, allowing for near real-time updates upon resource changes. Check connector documentation.

Principal Sync Interval¶

• What it does: CONNECTOR_<TYPE>_PRINCIPAL_SYNC_INTERVAL sets how often the connector checks the target data service for the status of its principals (users, groups, roles).
• Purpose: Helps detect inconsistencies. For example, if a group managed by the connector was accidentally deleted in the target data service, this sync can detect the deletion and (if configured to manage principals) re-create it.
• Recommendation: This check is usually less critical to run frequently; intervals like once per day are often sufficient.

Permission Reconciliation Sync Interval¶

• What it does: CONNECTOR_<TYPE>_PERMISSION_SYNC_INTERVAL configures how often the connector performs a full reconciliation, checking the actual permissions on all managed resources in the target data service against the expected permissions defined by Privacera policies.
• Purpose: Corrects any "permission drift" where manual changes or other issues have made the target data service inconsistent with Privacera policies.
• Considerations: This can be a resource-intensive operation, especially with many resources.
• Recommendation: Set this interval relatively high (e.g., once a day or even once a week) unless specific needs require more frequent reconciliation.

Audit Retrieval Interval¶

• What it does: CONNECTOR_<TYPE>_AUDIT_SYNC_INTERVAL sets how often the connector fetches access audit logs from the target data service and sends them to Privacera's audit store.
• Excluding Users: You can configure a list of users (e.g., service accounts) whose audit records should not be collected. It is highly recommended to exclude the service principal used by the PolicySync connector itself, as its actions are usually operational and not relevant user activity audits.

Recovery Mode¶

Recovery mode is an automatic protection mechanism that optimizes RocksDB rebuilding. It does this by deferring permission grants until they are required, reducing startup time during initial resource loading.

How Recovery Mode Works¶

Recovery mode automatically activates when the RocksDB database folder is missing (for example, during a fresh start or after cleanup).

The process includes the following phases:

1. Start Recovery Mode - Automatically activates when the RocksDB directory does not exist.
2. Resource Loading - Loads all managed resources and creates changelog entries, but skips permission grants
3. Permission Loading - Load permission from the service and performs grants/revokes only for resources with deltas (changes)
4. Exit Recovery Mode - Automatically exits after completing both resource and permission loading cycles

Why skip grants during resource loading? Granting permissions for all resources during initial load is time-consuming. By deferring grants until permission loading, the connector only performs grants where deltas are detected, significantly improving startup time.

When Recovery Mode Does NOT Activate¶

Recovery mode does not activate when any on-demand-only mode is enabled, even if the RocksDB directory is empty.

• SYNC_RESOURCE_ONDEMAND_ONLY_ENABLE=true
• SYNC_SERVICEPOLICY_ONDEMAND_ONLY_ENABLE=true

In on-demand only mode, there is no scheduled loading process, so Recovery Mode's optimization is not needed.

Monitoring Recovery Mode¶

You can identify recovery mode activity in the connector logs. [CONNECTOR_NAME] represents the name of your connector.

Connector Logs:

1
2
3

[CONNECTOR_NAME]: Connector will operate in RECOVERY MODE
[CONNECTOR_NAME]: Recovery mode STARTED - RocksDB folder does not exist
[CONNECTOR_NAME]: Recovery mode DISABLED - returned to normal operation

Grafana Dashboards: Recovery mode metrics and phase information are available in Grafana panels for real-time monitoring.

Migrating Existing Permissions¶

Critical Step: Before enabling active policy enforcement by the PolicySync connector on a target data service that already has users and permissions configured natively:

1. Identify Existing Permissions: Determine the permissions currently granted directly within the target data service.
2. Translate to Privacera Policies: Replicate these permissions as policies within Privacera Ranger. Ensure users, groups, roles, resources, and access levels match.
3. Verify Policies: Confirm the Privacera policies accurately reflect the necessary access.

Why this is crucial: If you enable the connector to enforce policies before migrating existing permissions, the connector may interpret the lack of corresponding Privacera policies as intent to revoke those native permissions. This can cause service disruptions by removing access users currently rely on.

• Assistance: Migrating complex permission schemes may require custom scripting. Contact Privacera professional services or support for guidance and assistance.

Recommended Onboarding Process¶

To safely introduce a PolicySync connector and minimize risk, follow these steps:

1. Start Small: Configure the Managed Resources List to include only a limited, non-critical subset of resources initially (e.g., a specific test schema or database).
2. Observe Mode (Disable Enforcement): Configure the connector to synchronize but not actively enforce policies initially. This often involves setting a specific property (like CONNECTOR_<TYPE>_GRANT_UPDATES to false - check the specific connector's documentation for the exact property name) to disable GRANT/REVOKE actions or policy creation.
3. Monitor: Run the connector in this observe/read-only mode. Check the connector logs and potentially the Privacera audits/reports to verify:
   • It connects successfully.
   • It correctly identifies the intended managed resources and principals.
   • It calculates the expected permissions based on your Privacera policies without applying them.
4. Gradual Enforcement: Once confident the connector behaves as expected in observe mode:
   • Enable policy enforcement (e.g., set CONNECTOR_<TYPE>_GRANT_UPDATES to true).
   • Monitor the target system and connector logs closely.
5. Expand Scope: Gradually increase the scope by adding more resources to the Managed Resources List, monitoring carefully after each expansion.

Privately Signed SSL Configuration¶

When your environment uses privately signed SSL certificates, additional configuration is required to ensure secure communication between PolicySync connectors and the Ops Server. This section guides you through the necessary setup steps.

Configuration Steps¶

On-Demand Sync Backpressure Control¶

During event spikes in on-demand sync, connectors may download and queue all events from the Ops Server, which can lead to increased memory usage and impact the performance of the RocksDB store. This behavior also slows down connector restarts, as all queued events must be reloaded into memory.

To mitigate this, the below properties limit the number of on-demand tasks retrieved from the Ops Server. This mechanism helps prevent excessive memory consumption and ensures stable connector performance during periods of high event volume.

• ChangeLog Queue Threshold: Specifies the maximum number of change logs that can be queued before task fetching is paused. Serves as a backpressure control mechanism to prevent system overload. The default value is 100.
• On Demand Task Batch Size: Defines the maximum number of on-demand tasks to fetch in a single batch. Task fetching stops once this limit is reached, regardless of pagination settings. The default value is 50
• On Demand Task Page Size: Determines the number of tasks to fetch per page when pagination is enabled. If set to 0 or a value greater than the batch size, pagination is effectively disabled. The default value is 0 (pagination is disabled by default). When enabled, tasks are fetched page by page and processed in parallel until the batch size limit is reached.

Policy Validity Evaluation¶

Policy Validity Evaluation enables PolicySync connectors to automatically evaluate and enforce time-based validity periods defined in Privacera policies. When enabled, the connector periodically checks policy validity periods and automatically grants or revokes access based on the specified time ranges.

A Policy Validity Period allows a policy author to define when a policy is active. This feature is typically used to schedule resource accessibility for a specific timeframe, such as:

• From 2025-01-31 16:07:27 to 2026-04-30 16:10:30

The following properties control the automatic evaluation of policy validity periods by PolicySync connectors:

• Policy Validity Evaluation Sync Enable: Enables or disables automatic evaluation of policy validity periods by the PolicySync connector. When set to true, the connector periodically checks all managed policies and applies or revokes access based on the current time. The default value is false.

• Policy Validity Evaluation Sync Interval Minutes: Specifies the interval (in minutes) at which the connector evaluates policy validity periods. Default value is 60 minutes.

Validation Steps:

To validate policy validity configuration:

• Create a new Resource Policy (Access, Tag, or Row-Level Filter).
• Click ADD VALIDITY PERIOD from the top-right corner.
• Under Policy Validity Period, specify:
  • Start Time
  • End Time
  • Time zone
• Click SAVE.

• Save the policy.

Strict Row Filter Role Matching Evaluation¶

This configuration controls whether strict role matching evaluation should be enabled for row filter policies across all connectors that support row-level filtering.

CONNECTOR__STRICT_ROW_FILTER_ROLE_MATCHING_EVALUATION_ENABLED¶

Default Value: "false"

Description: When enabled, the connector will perform strict role-matching evaluation for row filter policies. By default, the connector uses the first row filter item, but this setting ensures comprehensive role evaluation across all applicable policy items.

Supported Connectors: This configuration is available for the following connectors:

• Snowflake (CONNECTOR_SNOWFLAKE_STRICT_ROW_FILTER_ROLE_MATCHING_EVALUATION_ENABLED)

Multiple Ranger Policy Repositories¶

Privacera connectors support multiple Ranger policy repositories, enabling you to deploy several instances of the same connector type with isolated policy management. Each instance can be configured to use its own dedicated Ranger service repository, ensuring complete policy isolation and preventing conflicts across connector instances.

Configuration Workflow¶

To configure multiple Ranger policy repositories for a connector:

1. Create service repositories in Privacera Portal (e.g., privacera_snowflake_prod, privacera_snowflake_dev).
2. Configure each connector instance to point to its own repository.
   1. Self Managed/Data Plane: Create separate connector-custom.properties files.
   2. PrivaceraCloud: Create multiple applications and set repository properties.
3. Apply and validate the changes to confirm policy isolation across instances.

Prerequisites¶

Before configuring multiple Ranger policy repositories, ensure that the required service repositories are created in your Privacera portal.

Creating a Custom Service Repository

Implementation Approaches¶

There are two primary approaches for implementing multiple Ranger policy repositories:

• Approach 1: Dedicated Security Zone (SZ) Configurations

  • Use Privacera's Security Zone functionality to create isolated policy management environments.
  • Each connector instance runs within its own dedicated security zone, ensuring complete policy isolation.

• Approach 2: Separate Ranger Service Repository Instances

  • Create multiple Ranger service repositories within the same Privacera instance.
  • Each connector instance points to its own dedicated repository, allowing independent policy control.

Configuration Steps¶

Select the configuration method that applies to your deployment model. The steps below are generic and can be applied across all connector types (e.g., Snowflake, Databricks SQL, Databricks Unity Catalog, Redshift, BigQuery).

Each connector instance must be configured to use its own dedicated Ranger service repository to ensure complete policy isolation.

Skip Duplicate Ranger Changelogs¶

This configuration controls whether the PolicySync connector should skip processing duplicate Ranger changelogs to improve performance and reduce unnecessary processing overhead. When enabled, the connector tracks and skips changelogs that are already queued or being processed, preventing redundant work.

CONNECTOR_RANGER_CHANGELOG_SKIP_DUPLICATE_ENABLE¶

Default Value: "true"

Description: When enabled, the PolicySync connector will detect and skip duplicate Ranger changelog entries (for policies, roles, tags, GDS info, and user store updates) that are already queued for processing. This optimization prevents the connector from processing the same changelog multiple times, reducing memory usage, improving performance, and speeding up connector restarts by avoiding duplicate changelog reloading.

How it works:

• The connector tracks Ranger changelogs by type and version as they are queued
• If a newer or identical changelog of the same type is already queued, subsequent changelogs are skipped
• This prevents changelog duplication during rapid policy updates or restart scenarios
• Activity logs record when changelogs are skipped for troubleshooting purposes

When to disable: In rare scenarios where you need to ensure every changelog is processed (for debugging or troubleshooting), you can disable this feature. However, it is recommended to keep this enabled in production environments.

Supported Connectors: This configuration applies to all PolicySync connectors.

Configuration Steps¶