Cinchy Secrets Manager
This page outlines the Cinchy Secrets Manager, added to the platform in v5.7.
Overview
The Cinchy platform provides a built-in solution for securely storing secrets known as the Cinchy Secrets Table. Built with adherence to Cinchy’s Universal Access Controls, this table functions as a key vault similar to services like Azure Key Vault or AWS Secrets Manager. It allows you to store sensitive data that's accessible only to specific user groups with authorized access.
Within the Connections UI, you can use variables stored in this table, which then resolve as secrets. This approach ensures careful handling of confidential information. Some common use cases include:
Including them in a connection string.
Using them in REST Headers, URLs, or the request body.
Configuring the Listener via the Listener Config table.
Cinchy has also introduced a new API endpoint for retrieving your stored secrets.
Creating a secret
To create a secret in Cinchy:
Navigate to the [Cinchy].[Secrets] table on your platform (see Image 1).
Provide the following details for your secret:
Field | Description | Example |
---|---|---|
Secret Source | The location where the secret is stored. This field supports only 'Cinchy' as a source. | Cinchy |
Domain | The domain name of the location where the secret is stored. | QA |
Name | The identifier for your secret. | Password |
Secret Value | The actual secret content. | YourSecretValueHere |
Description | A brief explanation of the secret's purpose. | This secret contains the password for logging into the QA environment. |
Read Groups | A list of User Groups with read access to the secret. These groups can access the secret via the API, table, Connections UI, or CQL. | GroupA, GroupB |
Write Groups | A list of User Groups with write access to configure the secret. | GroupC, GroupD |
Call a secret via API
Cinchy has a new API endpoint designed for retrieving secrets. By utilizing the endpoint provided below, you can specify the <base-url>
, <secret-name>
, and <domain-name>
to retrieve the desired secret.
This endpoint functions seamlessly with Cinchy’s Personal Access Token capability, along with Access Tokens obtained from your Identity Provider (IDP).
Blank Example:
Populated Example:
The example below uses ExampleSecret
as a secretName and Sandbox
as the domain:
The API response will be in the following format:
Use a secret as a connections variable
You can use secrets stored in the Cinchy Secrets table as variables for your data syncs, wherever you use a variable. For instance, you can incorporate them within a connection string, an access key ID, or within a REST Source or Destination in the Header.
To use a Secret within Connections:
In the Connections UI, navigate to Info > Variables.
Under the Variables section, select Secret.
Enter the name of your variable.
Under the Value dropdown, select the secret you want to assign from the Secrets table.
Use a secret in real-time syncs
You can also use your Cinchy Secrets when configuring your Listener for real-time syncs.
To use a secret in real-time syncs:
When configuring your sync, navigate to the Info Tab > Variables.
Under the Variables section, choose Secret.
Input the name of your variable.
Under the Value dropdown, choose the secret you intend to assign from the Secrets table.
Go to the Source tab.
Within the Listener section, input the secret variables as values for the relevant property in your Topic or Connection Attribute fields.
For example:
Use a secret in the Listener Config table
You can also add a secret that's attached to a variable to the Topic or Connection Attributes in the Listener Config table.
Open the Listener Config table.
Select the row that corresponds to your data sync.
Select the Topic or Connection Attribute cell you want to change.
Replace the value for a property with the variable assigned to a secret.
For example, in the JSON code below, the Connection Attribute property connectionString
is replaced with the @connectionString
variable defined in the data sync.
Listener Config parameters
The following table provides an overview of which parameters you can use as secrets for each event connector type.
Event Connector Type | Topic | Connection Attributes | Value as Parameter/Secrets |
---|---|---|---|
Cinchy CDC | tableGuid | No | |
filter | Yes | ||
messageKeyExpression | Yes | ||
batchSize | No | ||
Salesforce Push Topic | Name | Yes | |
Id | Yes | ||
Query | Yes | ||
InstanceAuthUrl | Yes | ||
GrantType | Yes | ||
ClientId | Yes | ||
ClientSecret | Yes | ||
UserName | Yes | ||
Password | Yes | ||
ApiVersion | No | ||
MongoDB Event | database | Yes | |
collection | Yes | ||
pipelineStage | Yes | ||
connectionString | Yes | ||
Data Polling | FromClause | Yes | |
CursorColumn | Yes | ||
FilterCondition | Yes | ||
CursorColumnDataType | Yes | ||
Columns | Yes | ||
BatchSize | No | ||
Delay | No | ||
databaseType | Yes | ||
connectionString | Yes | ||
Kafka Topic | topicName | Yes | |
bootstrapServers | Yes | ||
Salesforce Platform Event | Name | Yes | |
InstanceAuthUrl | Yes | ||
GrantType | Yes | ||
ClientId | Yes | ||
ClientSecret | Yes | ||
UserName | Yes | ||
Password | Yes | ||
ApiVersion | No | ||
Amazon SQS | deleteMessages | No | |
awsRegion | No | ||
awsAccessKey | Yes | ||
awsSecret | Yes | ||
queueUrl | Yes |
Last updated