Connector Improvement: Enable client authentication/mTLS in Fivetran requests to Azure Functions
AnsweredThe security team at my company wants our Azure Functions to require client certificates. This is not possible within the current HTTP request format sent by Fivetran.
We are requesting that Fivetran enable an option for requests to be sent within a secure context, wherein Fivetran presents a certificate to Azure when establishing the connection.
-
Official comment
Hi Erin,
Thank you for sharing your need. Can you share any more about options that your security team would be open too? - or is mTLS certificate the only option they would consider?
I'm asking as we'll need to make the case to build this out and its not currently on our planned backlog.
I'm wondering if you have considered using our new Connector SDK offering, or if a Hybrid Deployment approach would suffice - Connector SDK will be adding support for Hybrid Deployment sometime in first half of FY25.
Please upvote this request if you also would appreciate mTLS support for our Azure Function Connector
Best regards,Alison
-
@Alison, thanks for the reply.
As long as our architecture depends on Azure Functions connectors, enabling mTLS in Fivetran requests is the only option because the security team specifically asks us to require client certificates on Azure functions.
Within the Connector SDK, I understand there is an option to use a configuration.json file to pass secrets to the connector. However, our security team requires that we setup key rotation, so all our secrets are stored in Azure Keyvault. There we run into the same issue because the Keyvault also requires access through a secure context. And the connector wouldn't have the same privileges for permissioning as native Azure resources (which benefit from managed identities).
Even if that were not an issue, unless the new Connector SDK provides persistent storage (I went through the docs and there is no mention of that), it would be impossible to move our current architecture fully into Fivetran (cutting out AZ Functions) because we depend on Azure's capability to persist function apps' storage within storage accounts.
The only other approach we see, actually, is rather than cutting out Azure Functions from the process and moving everything onto Fivetran's architecture, we move everything onto Azure Functions and cut out Fivetran. The additional development work in that case would just be handling CDC, which is one task compared to all the issues I stated above with trying to use the Connector SDK. We are happy with Fivetran's performance in this use case in all other ways, though, which is why I added this feature request.
-
Erin,
Thank you for your detailed reply - I have started the process to assess our options for adding mTLS support.
I'm also really curious to understand more about why you would need persistent storage, I'd love to understand more about how you use Azure's capability to persist function apps' storage within storage accounts. At first blush I would expect that using a more complex State() object to capture and store data between syncs would meet the need - and I'd love to understand its limitations.
Much appreciated,
Alison
Please sign in to leave a comment.
Comments
3 comments