Databricks Unity Catalog JDBC Connection: Can properties reference Databricks Secrets

[billpchie]

I'm creating a JDBC connection in Databricks Unity Catalog to connect to Trino.

The connection requires SSL configuration, including a client keystore and truststore.

When creating the connection through the Databricks UI, I enter these as key-value pairs under the connection's additional options.

My concern is that the following properties contain sensitive passwords:

• SSLKeyStorePassword

• SSLTrustStorePassword

I have two questions:

1. Can I reference Databricks secrets in these JDBC connection properties?

For example, is there a supported way to reference a secret scope and key instead of entering the password as a literal value?

2. If secret references are not supported, how are these key-value pairs stored and protected?

After creating the Unity Catalog connection through the UI, I can no longer see the original key-value pairs.

• Are the connection properties, particularly passwords, stored securely by Databricks?

• Are passwords encrypted at rest?

• Can users with USE CONNECTION permission retrieve or view these passwords?

• Is there official Databricks documentation explaining how sensitive JDBC connection properties are stored and protected?

I have looked through the Databricks documentation for Unity Catalog JDBC connections, but I haven't found a clear explanation of secret references or the storage and security model for sensitive additional options.

[Kirankumarbs]

The working pattern in our jobs while syncing views from Postgres! We didn't put credentials in a UC connection at all. Probably, can you explain more why are creating connection directly at UC level?

ad question 1:

as per this documentation, it says to use use secret(<scope>,<key>) for credential options.

ad question 2: The UI hides them after creation.

As per the documentation, connection credentials are hidden from the querying user.

 Oficially, USE Connection users can not retrieve credentials but they can run queries through it!

--------

What we run in production instead: a Key Vault-backed secret scope, with the job config holding only the secret names. At runtime the job calls dbutils.secrets.get(scope, key) and passes the values straight into spark.read.format(jdbc).option(user, ...).option(password, ...). Secrets stay in the vault, redacted, and access is controlled by secret-scope ACLs.

[billpchie]

Hi Krankumarbs,

Thanks for the link will give it a try.

I initially tried setting up the JDBC connection using Python, and it worked. However, the main issue is that JDBC itself needs to read the certificate, but it doesn't have access to the Unity Catalog volume where the certificate is stored.

To work around this, an initial script would be required to copy the certificate to the individual nodes so that JDBC can access it locally.

I wanted to explore whether there was a better way to handle the connection, ideally through a centralized, managed solution. This would also make the overall setup cleaner and easier to maintain.

Regards
Bill

[Kirankumarbs · Accepted solution]

Hmm, The JDBC driver can only take SSLKeyStorePath and SSLTrustStorePath as plain local file paths! So,the Trino driver wants local file paths for the keystore/truststore, and whatever runs the JDBC driver can't read /Volumes!

First thing I'd check: do you need both files? The truststore only validates Trino's server cert. If that cert comes from a public CA, SSLUseSystemTrustStore=true (or leaving the truststore out) uses the JVM's default trust store. The keystore only matters if Trino is doing mutual TLS. If you're authenticating with username and password over TLS, you can drop the keystore and both SSL passwords, and the only secret left is the password, which the UC connection handles.

If you do need mTLS or a private CA, I'd keep the init script and centralize it(which is your solution/work around already). One improvement i would suggest is that put the script and the certs in a UC volume, then attach the script through a cluster policy so every cluster that talks to Trino gets the files without anyone setting it up by hand or copying to nodes!

Other than above suggestions, i haven't found a UC-native way to attach client certs to a connection yet!

If this looks good, please accept it as a Solution so others can find it easily! Thanks!

[billpchie]

Thanks Kirankumarbs, I have tested UC connection will hit the same issue, so this will be the best approach.

[Yougasundar]

Hi @billpchie,

On your first question: the CREATE CONNECTION reference says that for any option that carries a credential, you should use the secret function instead of a literal value. So create the connection in SQL instead of the UI, for example with SSLKeyStorePassword secret('my_scope', 'trino_keystore_pwd'). The docs show this pattern for user and password, so run DESCRIBE CONNECTION and one test query to confirm the driver gets the value. On your second question: the JDBC connection page says that connection credentials are hidden from the querying user, and that options defined in the connection cannot be overridden at query time. I did not find a public page about encryption at rest for connection options, so for an audit answer please ask your Databricks account team. For the truststore, there is now a managed option called userProvidedServerCertificate. Databricks adds this PEM certificate to the default Java trust store of the driver sandbox on every compute that uses the connection (serverless, or Databricks Runtime 19 and above). If the Trino driver validates against the default Java trust store, you can drop SSLTrustStorePath, SSLTrustStorePassword and the init script for that part. For the client keystore (mutual TLS), the docs show no way to attach a client certificate. If your Trino setup allows it, password or OAuth authentication over TLS avoids the keystore. JDBC connections also support OAuth machine-to-machine (Beta), which passes only a short-lived token to the driver.

Docs: https://docs.databricks.com/aws/en/connect/jdbc-connection