How to set up key-pair authentication in Data Factory using a private key inside Key Vault

For Azure Data Factory’s Snowflake V2 linked service with key-pair authentication, the private key must be provided in a very specific format, and when using Azure Key Vault the multi-line PEM must be preserved exactly.

Key points for the correct format:

1. Use a PKCS#8 RSA private key in PEM format (.p8 file)
   • For mapping data flows, the recommendation is to generate a new RSA private key using the PKCS#8 standard in PEM format (.p8 file).
   • Example generation (from the referenced guidance) uses OpenSSL to produce rsa_key.p8.
2. Preserve the exact PEM content when storing in Key Vault
   • The private key file includes newline characters (\n) and must remain a valid PEM when retrieved by Data Factory.
   • When storing the key as a secret, do not flatten or reformat the PEM; it must keep:
     • The -----BEGIN ... PRIVATE KEY----- header line
     • All internal lines with their original line breaks
     • The -----END ... PRIVATE KEY----- footer line
   • If the secret is created via a UI that converts line breaks to spaces, the PEM becomes malformed and Snowflake returns Failed to parse PEM block containing the private key.
3. How to store the key correctly in Key Vault
   • Use CLI or another method that preserves multi-line content when creating the secret.
   • A similar pattern is documented for Purview + Snowflake, where the private key must be stored via Azure CLI or Cloud Shell because the Azure Portal text box corrupts the PEM by removing line breaks.
   • Example (from the Purview guidance, but the same principle applies to Data Factory):
     • View the private key file:

              cat rsa_key.p8
       

     • Store it as a secret using Azure CLI with --file to preserve multi-line format:

              az keyvault secret set \
                --vault-name <your-keyvault-name> \
                --name <your-secret-name> \
                --file rsa_key.p8
       

4. Referencing the Key Vault secret in the linked service
   • In the Snowflake V2 linked service, the privateKey property is an Azure Key Vault secret reference (SecretBase) for key-pair auth.
   • Ensure the linked service’s privateKey property points to that Key Vault secret (not an inline string), so Data Factory retrieves the exact PEM content.
5. When not using Key Vault (inline privateKey)
   • If the private key is embedded directly in the linked service JSON instead of Key Vault, the newline characters must be explicitly represented as \n in the string literal, as documented:
     • “Considering that the privateKey file includes newline characters (\n), it's essential to correctly format the privateKey content in its string literal form. This process involves adding \n explicitly to each newline.”
   • This requirement is for inline JSON only; when using Key Vault, store the real multi-line PEM and let ADF read it as-is.

If the error persists, the most common causes are:

• The key is not PKCS#8 PEM (for example, PKCS#1 or another format).
• The secret was created via Azure Portal and line breaks were lost.
• The header/footer lines were removed or altered.

Ensuring a valid PKCS#8 PEM and storing it via CLI/Cloud Shell into Key Vault, then referencing that secret in the privateKey property, aligns with the documented pattern and avoids the Snowflake PEM parse error.

References:

• Copy and transform data in Snowflake V2 using Azure Data Factory or Azure Synapse Analytics
• Connect to and manage Snowflake in Microsoft Purview
• SnowflakeLinkedV2ServiceTypeProperties.PrivateKey Property
• SnowflakeV2LinkedService.PrivateKey Property
• Set up your Snowflake database connection