- Platform Release 6.5
- Privacera Platform Installation
- Privacera Platform User Guide
- Privacera Discovery User Guide
- Privacera Encryption Guide
- Privacera Access Management User Guide
- AWS User Guide
- Overview of Privacera on AWS
- Configure policies for AWS services
- Using Athena with data access server
- Using DynamoDB with data access server
- Databricks access manager policy
- Accessing Kinesis with data access server
- Accessing Firehose with Data Access Server
- EMR user guide
- AWS S3 bucket encryption
- Getting started with Minio
- Plugins
- How to Get Support
- Coordinated Vulnerability Disclosure (CVD) Program of Privacera
- Shared Security Model
- Privacera Platform documentation changelog
Encryption with PEG REST API
Privacera Encryption REST API
PEG API endpoint
For Privacera Platform, by default, the PEG API endpoint is:
https://<privacera_hostname>:6869/api/peg/public
Check with your installation team for the value of <privacera_hostname>
and if they have changed this default port.
PEG REST API encryption endpoints
The PEG REST API consists of the following endpoints:
/authenticate
- Generates a token to be used with subsequent/protect
and/unprotect
endpoints./getSchemes
- Returns the names of Privacera-supplied and user-defined encryption schemes./protect
- Encrypts the data./unprotect
- Decrypts the data.
PEG REST API authentication methods on Privacera Platform
There are two ways to authenticate the PEG REST API:
Basic authentication with username and password.
An authentication token.
Basic PEG REST API authentication
A Portal user needs to have the ROLE_ENCRYPTION_ALL
or ROLE_ENCRYPTION_READ
role to authenticate to the PEG REST API via basic authentication.
For basic authentication, you pass your username and password credentials in the <username>:<password>
argument directly on the /protect
or /unprotect
endpoint. For an example of this argument, see Common PEG REST API fields.
If you are a privileged user, you can also make calls on another user's behalf.
For details on assigning roles, see User Management.
PEG REST API authentication token
The PEG REST API authentication token can be created in two ways:
In the Privacera Portal.
With the
/authenticate
REST API endpoint.
The token must be included in the HTTP header of subsequent endpoints.
The token has a configurable validity period. See Add Keytab Expiry Date.
Generate PEG REST API authentication token in Privacera Portal
You can generate the PEG REST API authentication token in Privacera Portal.
The token is a combination of an <AccessKey
and a SecretKey>
delimited by a colon (:): <AccessKey
:SecretKey>
. The authentication token is required in the header of the /protect
or /unprotect
endpoints in the following form:
X-API-KEY:<AccessKey>:<SecretKey>
To generate the token, do the following:
Log in to the Privacera Portal.
From the navigation menu, select Launch Pad > Privacera Token.
Click Generate Token and generate a new token after you enter the expiration details, etc.
An Access Key and a Secret Key are generated.
Store the Access Key and Secret Key credentials safely.
Get PEG REST API authentication token using the /authenticate endpoint
The PEG REST API authentication token is generated using the /authenticate
endpoint.
To generate the token, use the /authenticate
endpoint with basic authentication user credentials to authenticate the end-user. PEG is integrated with the Privacera Portal. For definitions of <service_user>
and <application_user>
, see Common PEG REST API fields.
curl -u <service_user>:<password> \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --data-raw '"user":"<application_user>"' \ https://<privacera_hostname>:6869/api/peg/public/authenticate
If the authentication is successful, PEG returns the colon-delimited token <AccessKey>:<SecretKey>
.
Subsequent calls to /protect
and /unprotect
endpoints must include the X-API-KEY
header with the token.
X-API-KEY:<token_from_authenticate>;
Note
If you are testing with a self-signed certificate, to bypass the certificate validation check, add the curl -k
option.
Common PEG REST API fields
This example of the /protect
endpoint illustrates some common fields of the PEG REST API on the Privacera Platform.
Instead of basic authentication, this example uses token authentication with an X-API-KEY:<token_from_authenticate>
. If you want basic authentication, remove the token line in this example and replace it with -u <service_user>:<password>
.
curl \ --request 'POST https://<privacera_hostname>:6869/api/peg/public/protect' --header "X-API-KEY:<token_from_authenticate>" \ --header "Accept: application/json" \ --header 'Content-Type: application/json' \ --data-raw '{"schemelist":["<encryption_scheme>,..."], \ "datalist":[["<data_to_encrypt>",...]], \ "maskSchemelist": ["<masking_scheme>",...], \ "maskDatalist": [[data_to_mask,...], \ "user":"<application_user>"}'
The following table displays common PEG REST API fields with descriptions of each:
Line | Description |
---|---|
| The If this anatomy showed basic authentication, it would use the
|
| List of <encryption_schemes>. |
| One or more <encryption_schemes> to encrypt or decrypt data in |
| List of data elements, one for each scheme in the |
| A data element to be encrypted with |
| List of |
| One or more <masking_schemes> to mask the data in |
| List of data elements for masking, with at least one for each masking scheme in |
| The PEG API endpoint and default port for Privacera Platform. |
| The application user or end-user that connects to a service, such as Snowflake, UDF, or ODBC application. |
| Not shown here, the
|
Construct the datalist for the /protect endpoint
Suppose you want to encrypt two database fields tagged with Privacera metadata PERSON_NAME
and EMAIL
. The value of your API datalist
to encrypt can be constructed by doing the following:
Extract from the database the unencrypted values of the tagged fields.
Format a JSON array of those values.
Make an API
/protect
request to encrypt the values in that array.Reformat the returned JSON array of the encrypted values to update the fields in your database.
Deconstruct the response from the /unprotect endpoint
Suppose you want to decrypt two database fields tagged with Privacera metadata PERSON_NAME
and EMAIL
. The value of your API datalist
to decrypt can be constructed by doing the following:
Extract from the database the encrypted values of the tagged fields.
Format a JSON array of those values.
Make an API
/unprotect
request to decrypt the values in that array.Reformat the returned JSON array of the decrypted values to update the fields in your database.
Example data transformation with the /unprotect endpoint and presentation scheme
This example shows some original input data, its representation when encrypted, and its obfuscated result after decryption with /unprotect
and an optional presentation scheme.
Original value:
sally@gmail.com
Encrypted value:
xy12zb@1mno2.rtz
Value after decryption and presentation scheme. The domain portion has been obfuscated:
sally@ymxof.1dg
Example PEG API endpoints
Most of the examples do not show the full curl
command and the required authentication. They show only the JSON bodies of the requests and responses. For authentication options, see ??? or the example of ???.
/authenticate
As required for /authenticate
, this example uses basic authentication to retrieve a token that is used in the other examples.
curl \ -u <service_user>:<password> \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --data-raw '"user":"<application_user>"' \ https://privacera.com:6869/api/peg/public/authenticate
Response
{"token":"bWtpc2VyOjE6MTYxNzIyMTk4Njg2Mjo4NjM5OTEzOA==:U3AcayrrQW3eecXjocH8ArJNqDr1GmJAM92Fa/f8T/YxJitKuCqw/CIB7Lm9Szqk", "tokenid":1, "tokenExpiry":"2021-04-01T12:19:30Z", "tokenName":"service_user", tokenStatus":"ENABLED", userName":"application_user"}
/protect with encryption scheme
The two elements in the input datalist
array are encrypted with the encryption schemes PERSON_NAME
and EMAIL
.
--data-raw '{"schemelist":["PERSON_NAME", "EMAIL"], "datalist": [["Mark", "Jonathan","Christopher"], ["mark@example.com", "jonathan@test.com", "christopher@google.com"]], "user":"jimmybob@BigCo.com"}'
Response
"datalist":[["WjM5", "5vpJF9zT", "1EbplEYVBjy"], ["i0bD@WKbMYpr.CvE", "?9aqS8zV@YUym.hkd", "d501shhJEO&@YpvfOc.VYH"]], "data":"", "responseStatus:"SUCCESS"}
/protect with masking scheme
The element in the input maskDataList
array is masked by the masking scheme MASKING_SCHEME
.
--data-raw '{ "maskSchemelist": [ "MASKING_SCHEME" ], "maskDatalist": [ [ "",null,"12-12-2012","12/12/2025T09:01:02" ] "user":"<application_user>"}'
Response
{ "datalist":[], "data":"", "maskDatalist": [ ["**-**-****","**/**/*******:**:**"], ["*****@*****.***","",null] ],"responseStatus":"SUCCESS" } ]
/protect with both encryption and masking schemes
The element in the input datalist
array is encrypted with the encryption scheme SYSTEM_EMAIL
and at the same time the data in the input maskDataList
is masked with the masking scheme MASKING_SCHEME
.
--data-raw '{"schemelist":["SYSTEM_EMAIL"], \ "datalist":[ ["sally@gmail.com"] ], \ "maskSchemelist":["DATE_MASKING_SCHEME"], \ "maskDatalist":[ ["",null,"12-12-2012","12/12/2025T09:01:02"] ], \ "user":"padmin" }'
Response
{ "datalist": [ [ "mNM-^@RUWqb.qRK" ] ], "data": "", "maskDatalist": [ [ "", null, "**-**-****", "**/**/*******:**:**" ] ], "responseStatus": "SUCCESS" }
/unprotect without presentation scheme
The two elements in the input datalist
array are decrypted with the encryption schemes PERSON_NAME
and EMAIL
.
--data-raw '{"schemelist":["PERSON_NAME", "EMAIL"], "datalist": [["WjM5","5vpJF9zT", "1EbplEYVBjy"], ["i0bD@WKbMYpr.CvE", "?9aqS8zV@YUym.hkd", "d501shhJEO&@YpvfOc.VYH"]], "user":"<application_user>"}'
Response
{"datalist": [["Mark", "Jonathan","Christopher"], ["mark@example.com", "jonathan@test.com", "christopher@google.com"]], "data":"", "responseStatus":"SUCCESS"}
/unprotect with presentation scheme
The input in the datalist
array is decrypted with the encryption scheme EMAIL2
and then obfuscated with the presentation scheme EMAIL2_P
.
--data-raw '{"datalist":[["8283a@QhbpH.yOs","5fGP@RyZBO.UZE"]], "schemelist":["EMAIL2"], "presentationSchemelist":["EMAIL2_P"] "user":"jimmybob@BigCo.com"}'
/unprotect with masking scheme
Masking schemes must not be used with /unprotect
, which returns an error because the masked data cannot be unmasked.
REST API response partial success on bulk operations
For bulk operations, in which multiple data elements are included in the datalist
JSON array of the /protect
or /unprotect
request, if an error is encountered in processing one of those elements, the endpoint returns the response as "Partial Success" but does not fail the entire batch.
Audit details for PEG REST API accesses
Privacera records access to the PEG REST API encryption keys and schemes. For details, see Audit.
Make encryption API calls on behalf of another user
Calling the encryption REST API for somebody else is sometimes called user impersonation.
If you have been granted privileged user status by the account administrator, you can make REST API calls on behalf of other users.
In this case, you pass your own username and password on the /protect
or /unprotect
endpoint and include the username of that other user as the value of the user:
field. That other user's password is not required.
In the following example, user <privileged_user>
includes his own password and specifies user:<username_being_impersonated>
to make the call to /protect
on behalf of that user:
curl -k -u <privileged_user>:<privileged_user_password -H "Accept: application/json" \ -d '{"schemelist":["TEST_EMAIL_NEW_30_6"], \ "datalist":[["sally@gmail.com"]], \ "user":"<username_being_impersonated>"}' \ -H 'Content-Type: application/json' <peg_server_URL_or_API_endpoint>api/peg/public/protect;
Data services, such as Databricks or Trino, can also take advantage of the privileged user as the service user, allowing the data service to run /protect
and /unprotect
on behalf of other users of the data service.
Troubleshoot REST API Issues on Privacera Platform
No Permission/Access Denied on REST API Requests on Kubernetes
On PEG REST API endpoints, if you get an "unauthorized" response or permission denied errors, check the following:
Make sure the user has been given the proper permission for Apache Ranger policies. See Set User Access in Ranger KMS.
Verify that Apache Ranger policies are being downloaded properly to the PEG pod. Log into the server and check the PEG pod in your namespace for the presence of the file
peg_privacera_peg_roles.json
with the following example commands:
# Get a Bash shell as root on the PEG pod kubectl exec -it peg-6df5fb4b68-n78gl -n t-16153315220081 bash cd /tmp/policycache/ ls -al total 4 drwxr-xr-x 2 root root 42 Apr 28 17:29 . drwxrwxrwt 1 root root 160 Apr 28 17:29 .. -rw-r--r-- 1 root root 112 Apr 28 17:29 peg_privacera_peg_roles.json