Skip to main content

Privacera Documentation

PolicySync design and configuration on Privacera Platform

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:

PolicySync_postgres_2.png

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.

PolicySync_topology_001.png

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.

PolicySync_topology_002.png

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.

PolicySync_topology_003.png

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.

<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.

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

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.yml
The 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