Skip to main content

Privacera Documentation

Table of ContentsTable of Contents

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

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:

  1. Decide which connector to a third-party datasource to create the unique policy repository for. In this example, we work with PostgreSQL.

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

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

  1. As administrator, go to Access Management > Resource Policies.

  2. Locate the third-party connector already available. In this example, the single shared repository for PostgreSQL is shown:

    PolicySync_postgres_1.png

  3. From the three vertical dots on the upper right, select Add Service:

    PolicySync_postgres_3.png

  4. Enter the Service Name. Follow your naming convention described in 2. In this example, privacera_postgres_prod_instance.

  5. Under Select Tag Service, choose privacera_tag.

    PolicySync_postgres_4.png

  6. Click Save.

    The new repository has been created.

    PolicySync_postgres_4a.png

  7. Repeat these steps for as many other policy repositories you want.

In this example, the three separate repositories are ready:

PolicySync_postgres_2.png

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