Skip to content

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:

Configuration Method Applies To Description
PrivaceraCloud Portal UX Privacera Cloud Use the web interface in PrivaceraCloud. Connectors restart automatically when you save changes.
YAML Configuration File Self-Managed & Data Plane Edit the connector's .yaml configuration file directly. You must manually restart the connector using Privacera Manager scripts after any change to this file for the settings to take effect.
Privacera Portal UI / API (New) Self-Managed (requires setup) Use the web interface or APIs in your Self-Managed environment. Most changes apply immediately without a restart (hot-loaded). Requires initial setup: A one-time bootstrap process using Privacera Manager is needed to enable this feature for connector pods.

Overview of Common Configuration Areas

These settings apply specifically to PolicySync connectors.

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.

Configuration Area Purpose
Connection Details How the connector authenticates and connects to the target data service (e.g., Snowflake, Databricks).
Managed Resources List Specifies exactly which resources (like databases, tables, schemas) this connector will manage policies for. Includes ways to include or exclude resources.
Managed Principals for Policy Enforcement Defines which Privacera users, groups, and roles the connector should create policies for. Includes filtering and mapping rules to match target system identities.
Managed Principals in Target Service Allows the connector to automatically create and manage corresponding users, groups, or roles directly within the target data service.
Fine-Grained Access Control Methods Determines whether to use the target data service's built-in security features (native) or Privacera's Secure Views for column/row-level policies.
Resource Sync Interval How often the connector checks the target data service for new or changed resources (like new tables) and applies relevant policies.
Principal Sync Interval How often the connector checks the target data service for changes in its users, groups, or roles.
Permission Sync Interval How often the connector verifies and corrects permissions on managed resources in the target data service to match Privacera policies.
Audit Retrieval Interval How often the connector fetches audit logs from the target data service.
Migrating Existing Permissions Guidance on converting permissions already set in the target data service into Privacera policies before activating the connector.
Recommended Onboarding Process Best practices for enabling a new connector safely, such as starting with limited scope and monitoring before full enforcement.

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.

Note

The Permission Reconciliation Sync Interval is specifically for periodic reconciliation to correct any "permission drift" (differences between the target service and Privacera policies). This interval does not delay the application of new or updated policies defined in Privacera. The connector applies new policy changes immediately because it frequently polls Privacera Ranger for updates.

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.

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.

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.

Comments