3 min read

Accessing Azure Resources Using Point-To-Site Virtual Private Network Gateway

  • Athiththan Kathirgamasegaran
  • |
  • 26 Jul, 2022

Did you know that you can connect your on-premises resources with Azure resources through Azure Virtual Network Gateway? And did you know that Azure Virtual Network Gateway provides both site-to-site and point-to-site connection types? 

WSO2 integrates Azure Virtual Network Gateway with point-to-site connection and the Azure certificate method to connect to essential resources that are deployed in the Azure platform. However, this approach comes with a price of having to manage site reliability engineering (SRE) toil. Therefore, maintaining the certificates of developers and updating the Virtual Network Gateway (also known as VPN Gateway) should be attained.

This blog discusses how WSO2 creates the point-to-site connection with Azure resources, and how the repetitive task of adding, removing, and updating certificates on the VPN Gateway is addressed by automation.

WSO2’s approach

High-level design

WSO2 requires developers to access essential VM resources using a dedicated and secured VPN tunnel. Therefore, we deployed a dedicated hub virtual network, and configured a VPN Gateway with point-to-site enabled. We requested developers to generate a set of self-signed certificates and share them with the SRE team to update the VPN Gateway and to establish the connection. This became a repetitive task in which the SRE team had to update the VPN Gateway with each new set of generated certificates whenever a developer was onboarded. As a result, the SRE team was unable to keep track of the updates made to the VPN Gateway.

To lessen the burden of toil and overhead, and to keep track of the updates made, developers were advised to generate and commit their certificates to a dedicated private Git repository. We developed an Automation Runbook using Azure Automation resources to fetch the certificates from the mentioned repositories, and to update them in the VPN Gateway.

If you are new to Azure Automation accounts, refer to Azure Automation documentation | Microsoft Docs

We also developed a set of GitHub actions to execute the Automation Runbook when a pull request is merged to the relevant Git repositories. Once the certificates are synchronized with the VPN Gateway, developers can configure their local machines to connect to the point-to-site VPN.

Here is a high-level diagram that outlines the solution workflow.

  1. Developers who need access to the Azure VM resources from their local machine, generate the self-signed certificates and commit them to a private GitHub repository.
  2. An Automation Runbook, which is deployed in the Azure cloud, is triggered by GitHub actions.
  3. The Automation Runbook fetches all certificates that are committed to the GitHub repository and synchronizes them with the VPN Gateway.
  4. Once the sync is completed, the developer configures their local machine with the point-to-site VPN configurations.
  5. The developer connects to the VPN Gateway through the dedicated point-to-site VPN Tunnel and accesses the required Azure VM resources

A private Git repository is used to manage the certificates of our developers. This enables us to keep track of the changes that are made to the artifacts. These certificates are only public certificates, and no private keys are stored or maintained in this repository.

Implementation

Azure Automation and Runbooks provides a platform to develop PowerShell scripts to automate any monotonous tasks. Here is a sample Automation Runbook script written in PowerShell to read or fetch the certificates from the mentioned Git repository, and to update the VPN Gateway.

Refer the PowerShell Script in the following link.

The Runbook expects the following arguments - both automation variables and credentials to interact with the Git repository and VPN Gateway (automation variables are prefixed with 'av' and automation credentials are prefixed with 'ac').

  1. av-repository-org: the organization where the private Git repository belongs
  2. av-repository-name: the name of the private Git repository where the CA (root) certificates public keys are stored
  3. av-repository-branch: the branch which needs to be considered when reading the certificates from the repository
  4. av-subscription-id: the ID of the subscription where the VPN Gateway is installed in Azure
  5. av-resource-group: the name of the resource group where the VPN Gateway is installed.
  6. av-vnetgw-name: the name of the VPN Gateway
  7. ac-github-pat: the personal access token generated from GitHub (or any other source control platform) to access the Git repository

All mentioned variables and secrets need to be created under the same Automation account in order to be available for retrieval during the execution of Runbook.

(Please refer to Manage credentials in Azure Automation | Microsoft Docs, and Manage variables in Azure Automation | Microsoft Docs to configure Automation Variables and Automation Credentials)

The Runbook requires access to the VPN Gateway resource. We have enabled the managed identity for the Automation account, and have been using it to assign roles. The steps are as follows:

  • Locate the Automation account from Azure portal and select ‘Identity’ under ‘Account Settings’
  • Under the ‘System Assigned’ tab, switch ‘On the Status’ and click ‘Save’. This enables the managed identity on the Automation account
  • Next, locate the VPN Gateway resource from Azure portal and select the ‘Access Control (IAM)’ option from the left navigation panel to open up the access controls of the VPN Gateway resource
  • Click Add > Add role assignment and select the ‘Contributor’ role from the list
  • Click ‘Next’, select ‘Managed Identity’ option as the assign access, and then click ‘Select Members’
  • Locate the Automation accounts managed identity by filling in the dropdowns and clicking ‘apply’

For more information, please refer to Using a system-assigned managed identity for an Azure Automation account | Microsoft Docs

To access the GitHub repositories from the Automation Runbook, we require a personal access token (PAT) from GitHub. This can be obtained from GitHub by following the instructions in the document - Creating a personal access token - GitHub Docs.

The PowerShell script first retrieves all configured variables and secrets for the execution. It uses the provided GitHub PAT token to access the specified GitHub repository and fetch all approved certificates. Then, sign in to Azure and get all certificates that are already applied to the VPN Gateway. This performs a comparison operation and filters which certificates are to be added, updated, or removed. Finally, add, update, or remove the certificates sequentially from the VPN Gateway.

This blog doesn’t include any pipeline scripts or steps to trigger the Automation Runbook automatically once a pull request has been merged. However, you are free to create a pipeline or a GitHub action to run the Automation Runbook according to your requirements. 

Conclusion

Developers at WSO2 have the need to access essential Azure VM resources with security in mind. The WSO2 SRE team provided an approach to access all the required Azure VM resources through a dedicated point-to-site VPN Tunnel. In this blog, we have provided an example of how the WSO2 SRE team approached the requirement by looking at an overall picture, and how it is achieved by lessening the toil and overheads using Azure tools such as Azure Automation account and Azure Automation Runbook.

The WSO2 SRE team is responsible for implementing processes and best practices that enable  Asgardeo, our IDaaS solution; Choreo, our next generation iPaaS for cloud native engineering; and other cloud-based offerings to run in a reliable, scalable, and secure manner. For more information, visit the WSO2  homepageevents page or  blog.