Azure key vault - connect_cdc_sqdata - Latest

Connect CDC (SQData) Secure Communications Components

Product type
Software
Portfolio
Integrate
Product family
Connect
Product
Connect > Connect CDC (SQData)
Version
Latest
Language
English
Product name
Connect CDC (SQData)
Title
Connect CDC (SQData) Secure Communications Components
Copyright
2024
First publish date
2000
Last edition
2024-07-30
Last publish date
2024-07-30T19:55:16.493453

Microsoft's Azure Key Vault is becoming an increasingly popular resource for securing credentials particularly for Event Hub and other Azure cloud services. The “Secrets Management” feature of AKV is used for storing the NaCl private key used by Connect CDC SQData. See the official introduction to AKV at https://docs.microsoft.com/en-us/azure/key-vault/general/overview.

Once the NaCL key pair has been generated by %PREFIX%>UTIL , the contents of the private key file, id_nacl can be stored as a "secret" using either Microsoft's Azure Portal import process or the Azuer CLI.

Syntax:

Using the id_nacl file content from the KeyGen, use Azure CLI in a script or at the command line to specify only the private key value from the file, excluding the "-----BEGIN NACL PRIVATE KEY-----" and "-----END NACL PRIVATE KEY-----" lines.

az keyvault secret set --vault-name "<your-unique-keyvault-name>" --name "id_nacl" --value "L68x1APsG4Bhhv+gG4CYP3IdsSUX3fNSQ030RUy0T5I="

Once the NaCL Private pair has been secured in the AKV it will be referenced as required by Connect CDC SQData components using the existing method for specifying non-default identity locations:

Syntax
 --identity=azkv://<vault-name>.vault.azure.net/secrets/<secret_name>
Keyword and Parameter Description
Keyword Description
secret_name

While any name can be used for the secret, using ïd_nacl" or when several different NaCL private keys are to be stored in the AKV, a naming standard that relates to a host or application name concatinated with id_nacl may be appropriate.

Azure Key Vault (AKV) based secrets in Connect CDC SQData are supported only on Linux platforms. AKV requires an Azure Active Directory (AAD) token to be presented to retrieve secrets. SQData retrieves AAD tokens from Azure differently when running on on-prem Linux machines and when running on Azure Linux VM.
When running on-prem, to retrieve AAD, tenant_id, client_id and client_secret have to be specified in the sqdata_cloud.conf file located in the working directory. When running on Azure VM, AAD will retrieved from managed identity. Two types of managed identities are supported:
  • If client_id is specified in sqdata_cloud.conf file, then AAD token is retrieved from user managed identity
  • If none of tenant_id, client_id and client_secret is specified, then AAD token is retrieved from system managed identity.
sqdata_cloud.conf file Example
[azkv]
tenant_id=f0h2842c-8394-4tcu-bb4r-e7745dc73b3b
client_id=73495b95-9d73-4973-8318-caf355b10f54
client_secret=~WlkC~4QsdQFLg0XyEeb0923_23MpRWsC~.

Example 1:

Use the AKV to provide the NaCL Private Key for a Replicator Engine run from the Linux command line.
 sqdrpl Db2TOKAF.rpl --identity=azkv://abc_company.vault.azure.net/secrets/id_nacl

Example 2:

Use the AKV to provide the NaCL Private Key for an Apply engine named Db2TOKAF controlled by a local Engine Controller on linux. This Engine could be started using the sqdmon utility on the localhost or even a zOS batch job executing SQDMON and starting the Engine on the remote linux system since the Private Key used by the Engine is specified by the Engine Controller SQDaemon.

(in the sqdagents.cfg file)
 acl=/home/sqdata/poc/daemon/cfg/acl.cfg
 authorized_keys=home/sqdata/poc/daemon/nacl_auth_keys
 identity=azkv://abc_company.vault.azure.net/secrets/id_nacl 
 message_level=2
 message_file=../logs/daemon.log
 service=2626
[Db2TOKAF]
 type=Engine
 program=sqdata
 args=/home/sqdata/poc/engines/Db2TOKAF.prc
 working_directory=/home/sqdata/poc
 stdout_file=/home/sqdata/poc/DB2TOKAF.rpt
 stderr_file=/home/sqdata/poc/DB2TOKAF.rpt
 auto_start=N
Note: The value of any other Key pair specified in the Kafka producer and consumer configuration files can also be secured using AKV. In those cases the syntax is a similar "url" string, preceded by a keyword %secret.
Syntax
<key>=%secret(azkv://<vault-name>.vault.azure.net/secrets/<secret_name>

Example 3:

Use the AKV to provide the password for an Apply or Replicator Engine using SASL encryption referenced in the sqdata_kafka_consuamer.conf file.
 sasl.password=%secret(azkv://connect123.vault.azure.net/secrets/saslpas)