Snowflake RSA Private Key Format Issues When Stored as DataHub Secrets – DataHub Customer Support Portal

Area: Ingestion Issues

Sub-Area: Snowflake Connector — Key Pair Authentication

Issue

When configuring Snowflake ingestion to use RSA key pair authentication, storing the private key as a DataHub secret can cause ingestion to fail with a PEM loading error, even though the same key works when pasted directly into the recipe. The root cause is that the secret value contains literal \n escape sequences (backslash followed by the letter n) instead of actual newline characters. Python's cryptography library requires properly formatted PEM data with real newlines to deserialize the key. Additionally, using the update operation on an existing secret — rather than deleting and recreating it — can silently reintroduce escaped newlines due to a known bug in the updateSecret GraphQL mutation present in certain DataHub versions.

Error Messages

datahub.ingestion.run.pipeline.PipelineInitError: Failed to configure the source (snowflake): Failed to connect to snowflake instance: Unable to load PEM file.
Caught exception while attempting to fetch secrets from DataHub. Secret names: ['<your-secret-name>']
Secret '<your-secret-name>' not found in secret stores or environment, using empty string

You Might Be Asking

Why does Snowflake key pair authentication work when I paste the private key directly into the recipe but fail when I load it from a DataHub secret?
Why does recreating the secret fix the issue when updating it does not?
What PEM format (PKCS#8 vs. PKCS#1) does the Snowflake connector require?
Why does the remote executor fail to load a secret that works fine in the embedded executor?

Solution

Verify the PEM format is PKCS#8.
The private key header must read -----BEGIN PRIVATE KEY-----. If it reads -----BEGIN RSA PRIVATE KEY----- (PKCS#1), convert it to PKCS#8 first using the following command:
```
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt \
  -in rsa_key_pkcs1.pem \
  -out rsa_key_pkcs8.pem
```
Delete the existing secret — do not update it.
Navigate to Settings > Secrets in the DataHub UI and delete the secret containing the private key. Do not use the edit/update operation, as certain DataHub versions contain a bug in the updateSecret GraphQL mutation that re-escapes newlines in the stored value, silently corrupting the key.
Recreate the secret with actual newlines.
Create a new secret with the same name. When pasting the private key value, use the full multiline PEM block with real newline characters, not \n escape sequences. The value stored in the secret must look like this:
```
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC7...
(remaining base64-encoded key content)
...rest of key...
-----END PRIVATE KEY-----
```
Do not store the key in single-line format:
```
# INCORRECT — do not use this format
-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBg...\n-----END PRIVATE KEY-----
```

Ensure authentication_type is explicitly set in the recipe.

Without this field, the key pair authentication branch is never entered. Add or confirm the following in your ingestion recipe:

source:
  type: snowflake
  config:
    authentication_type: KEY_PAIR_AUTHENTICATOR
    username: <your-snowflake-username>
    account_id: <your-snowflake-account>
    role: <your-role>
    warehouse: <your-warehouse>
    private_key: ${YOUR_SECRET_NAME}
    # Do NOT include a 'password' field when using KEY_PAIR_AUTHENTICATOR

Remove any conflicting password field.
If both a password and a private_key are present in the recipe when using KEY_PAIR_AUTHENTICATOR, it can cause authentication conflicts. Remove the password field entirely when using key pair authentication.
Re-run the ingestion and verify.
After recreating the secret with proper formatting, trigger the ingestion pipeline again. If the remote executor is still failing to resolve the secret (with a "not found" error), confirm that the secret name referenced in the recipe exactly matches the name used when the secret was created, including case sensitivity.

Additional Notes

The Snowflake connector uses Python's cryptography library (load_pem_private_key()) to parse the private key. This library strictly requires properly formatted PEM data with real newline characters. DataHub's internal secret handling code does include a normalization step that attempts to convert literal \n strings to real newlines, but double-escaping (e.g., \\n stored at the database level) or corruption introduced by the updateSecret GraphQL mutation can defeat this normalization. A bug fix for the updateSecret mutation was merged into DataHub OSS (PR #15442); deployments running versions that predate this fix should always delete and recreate secrets rather than updating them to avoid silent corruption. If the embedded executor succeeds but the remote executor fails, also verify that the remote executor version has access to the DataHub Secrets Manager and that network/permissions allow it to retrieve secrets at runtime.

Issue

Error Messages

You Might Be Asking

Solution

Additional Notes

Related Documentation