An Azure service that provides private connectivity from a virtual network to Azure platform as a service, customer-owned, or Microsoft partner services.
Hello @Parasi, Vijay (Contractor)
Azure Data Factory’s Git integration should be treated separately from its data-plane networking.
Managed Virtual Network and managed private endpoints don’t carry ADF source-control traffic to GitHub. Those features are designed primarily for Integration Runtime connectivity from pipelines to supported data stores and compute services. ADF’s Git integration is part of the authoring/control-plane experience.
For GitHub, ADF currently supports:
- GitHub.com
- GitHub Enterprise Cloud
- GitHub Enterprise Server
- Public and private repositories, provided the user has read/write repository permissions
For repositories owned by a GitHub organization, an organization administrator must authorize the Azure Data Factory application. ADF then accesses repositories on behalf of the signed-in user according to that user’s GitHub permissions.
Private Endpoint requirement
There is no documented Azure Private Endpoint that you can create between an ADF managed virtual network and GitHub.com or GitHub Enterprise Cloud for the native ADF Git integration.
Therefore, enabling private endpoints for the ADF resource and its linked services does not make the GitHub connection private, nor does it route GitHub traffic through the ADF managed virtual network.
For GitHub Enterprise Server, Microsoft documents that the server must use HTTPS and that the customer is responsible for its firewall, VPN, and network policies. Authentication uses a GitHub personal access token rather than the GitHub.com OAuth flow.
However, Microsoft doesn’t document a customer-configurable VNet injection, private endpoint, self-hosted Integration Runtime, proxy, or ExpressRoute path for the native ADF source-control service to reach an internally isolated GitHub Enterprise Server.
Recommended architecture
- If your policy allows approved public SaaS control-plane traffic, the typical design is:
- Keep ADF datasets, linked services, and Integration Runtime traffic private through managed private endpoints.
- Approve the Azure Data Factory GitHub application at the GitHub organization level.
- Restrict repository access using GitHub permissions, branch protection, OAuth application policies, secret scanning, and push protection.
- Configure Git integration only on the development factory. Promote changes to test and production through CI/CD rather than enabling Git integration on every factory. Microsoft’s ADF policy guidance also recommends Git integration only for development factories.
If your security standard requires all source-control communication to remain on private network paths, native ADF-to-GitHub integration may not meet that requirement. A practical alternative is to:
- Keep the repository in GitHub Enterprise Server.
- Use self-hosted GitHub Actions runners or another privately hosted build agent with access to the repository and Azure.
- Generate and deploy the ADF ARM templates through CI/CD using a managed identity or workload identity federation.
- Use ADF live mode or another approved repository option for authoring, depending on your governance requirements.
One important clarification: the System Assigned Managed Identity used by your ADF linked services is unrelated to GitHub authentication. GitHub.com integration uses GitHub authorization, while GitHub Enterprise Server uses a personal access token.
In summary, Private Endpoint-only access for ADF data services and native GitHub integration are separate concerns. The ADF documentation supports GitHub as a source-control provider, but it doesn’t document a private endpoint or customer-managed private networking path for that Git control-plane integration.
Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.