VPN Access Request Automation with SlackBot and Terraform

Making VPN Access Request submission easier for everyone!

This article will explain how SlackBot and Terraform could become a perfect combination for solving real-life problems, such as VPN access requests from our colleagues at DKatalis to Cloud Infrastructure Engineering Team.

We will delve into the underlying problem that prompted the app’s development, system design, implementation, deployment, and the impact it brings. You will gain a better understanding of where our solution truly makes a difference.

Background and Problem Definitions

Let’s start with the background story first.

Previously, VPN access request was fulfilled by manual administration. If there was a new request, someone from Cloud Infra Team would work on this request and start to administer it by freehand. It worked, but it definitely took much time for the cloud infra engineer if there were multiple requests for just VPN access. Hence, still manual.

Then, the idea to automate the process using Terraform came up. Every request would be fulfilled by creating Terraform variables for every colleague who needs VPN access. The cloud infra engineer only would only need to write down the specification and let the Terraform pipelines work on Gitlab CI. It’s more automated now, and manual work was decreased.

So after some evolution on the VPN access workflows, we now see the obvious problem here:

• Creating Merge Requests (MR), whether by techies or non-techies, was a time-consuming process. Unless someone needs for very customize and specific VPN access request
• Non-techies still struggled to create MR by themselves as they were unfamiliar with GitLab CI. Hence, they relied on techies in their squad for assistance. But the techies also need time to work on the VPN access requests because they have their own workloads too.
• There was a policy that required cloud infra engineers on-call to create a VPN access request on behalf of nontechies who raised one. But it was still time-consuming for the on-call engineers as the frequency of requests was high, hindering them from completing high-prioritized tasks.

That’s why we need a simplified system that even non-techies can do by themselves without being overwhelmed by tech-related stuff. However, the final approval for MRs created by this system will still be in the hands of cloud infra engineers.

System Design

Before we jump to the actual implementation, take a look at how the new system differs from the legacy workflow. This way, you can get the context first before swallowing everything from technical parts.

Legacy workflow

Legacy workflows for VPN access request

Let me explain the diagram above:

• Both techies and non-techies raise the VPN access requests via the GitLab repository. Non-techies would create the MR by opening the repo and creating a new branch for the change directly from the GitLab repository page. Techies colleagues, on the other hand, would submit their requests by cloning the repo and creating the submission from their local machine.
• MR for their VPN access requests would be created and submitted to the repository page.
• Requesters shared the links in the infrastructure support Slack channel and tagged any on-call engineer who would review, approve and merge the MR once they got the notification.
• VPN access requests would be processed by Gitlab CI + Terraform, and the requester would receive their VPN access request confirmation.

Based on the explanation above, most of the actions are performed manually. As described in the previous section, it was a complicated process for both the requester (especially non-techies) and on-call engineers.

New workflow

New workflows for VPN access request

The new system simplified the system for both users, following these steps:

• Both techies and non-techies will raise the VPN access requests via Slackbot. They only need to fill out a form and receive a notification via Slack DM from SlackBot.
• MR created and submitted to the repo on behalf of the requester by Slackbot. It will also automatically post the MR in the infrastructure support channel and tag the on-call engineer.
• The on-call engineer will review, approve and merge the MR once they get the notification. Next, GitLab CI and Terraform will process the VPN access request and notify the requester.

As you can see above, most of the actions are automated by SlackBot. It should reduce efforts both for the requester and on-call engineers.

Implementation

Stacks

We use this stack to build the new workflow with SlackBot:

• Python3
• Flask Web Framework
• Slack API (Bot, Shortcut, etc.)
• GitLab API (Merge Request, CI Trigger, etc.)
• Terraform

Key Features

Implementation of the SlackBot — choosing request type

From the above picture, SlackBot will ask you first what kind of VPN request type you want to submit. Currently, there are 5 VPN request types that could be raised by the requester via the SlackBot, as mentioned in section D.1. We add some key features to the SlackBot for VPN access requests, such as:

• Create a new VPN profile

Example implementation of the SlackBot — create new VPN profile

If someone wants to create a new VPN profile. They only need to specify their e-mail, VPN group, and environment to which they want to access. Then, SlackBot generates the MR automatically and mentions any on-call engineers to review, approve and merge the MR.

• Reset VPN password

Example implementation of the SlackBot — reset VPN password

If someone wants to reset their VPN profile. They only need to submit e-mail and environment which they want to access.

• Reset VPN multi-factor authentication (MFA) / two-factor authentication (2FA)
• Change VPN group
• Delete VPN profile

Implemented workflow

Implemented workflows diagram for the new workflows by using SlackBot

Let me explain the diagram above:

• User open Slack and open shortcuts in any channels
• Find VPN Access Request shortcut, choose an action type, and fill out the form given by SlackBot. Once processed, the requester will receive a reply from SlackBot via DM.
• GitLab Runner CI processes the requests in the background on behalf of the requester. The result of this pipeline is MR for VPN access self-service repository (existing automation tool for VPN access management).
• GitLab Runner CI will send a Slack message to the infrastructure support channel containing the link to the MR and tag the on-call engineer. They will review and merge the MR depending on the request. If approved, the MR will be merged into the VPN access self-service repository.
• The on-call engineer will update the Slack post that the MR has been reviewed and merged.

It only takes a couple of minutes until the change takes effect.

Deployment

Deployment Stacks

We used these stacks to build the new VPN access request workflow with SlackBot:

• GitLab CI: to perform some automated tasks when building the project, such as linting, building Docker images and bump versions of Helm Charts.
• Docker: containerized the application so it could be deployed on any platform as long support Docker.
• Sonar Nexus: container registry for built images, from which Kubernetes will fetch them.
• Helm Charts: it provides a solution to simplify the management of Kubernetes manifests, which can be complex. We can create one template project for a specific backend application. Then, variables could vary depending on the number of environments that we have.
• ArgoCD: automatically synchronizes Helm Charts and actual deployment in Kubernetes, as you might not want to tinker with the latter directly. And it’s more secure.
• Kubernetes: a container orchestration that could manage your Docker workloads at scale.
• Istio Virtual Service: a web proxy for our workloads on Kubernetes to receive incoming HTTP requests
• Tyk API Gateway: manages incoming HTTP requests based on specific rules and restrictions. So, the payload which comes into Kubernetes will be more secure and sanitized.

Deployment Workflows

Deployment workflow master plan for Cloud Infrastructure Team SlackBot

The deployment workflow master plan will be as follows:

• Contributor/submitter makes new changes to SlackBot repository with new MR. Python Linter and Docker Linter would check the new changes. If it fails, the submitter should fix the error first.
• If the MR is approved by the reviewer, the MR will be merged into the master branch. It will run some pipelines such as Python Linter, Docker Linter, build the Docker image, push the Docker image to the container registry and bump the image version on the Helm Charts repository for this SlackBot.
• GitLab CI Trigger API will create a new MR containing bumped image version. If the MR is approved, Helm Lint will be run on the Gitlab CI pipeline for Helm Charts Repository when the new changes merge into the master branch.
• Until this point, the latest change on the Helm Charts repository will be deployed by ArgoCD to Kubernetes. ArgoCD ensures your Helm Charts will be synced as it is.

So far, we have partially implemented the master plan above, with the rest of the stuff set to be completed in the near future. Things that are not being implemented from the above diagram (yet) are:

• Docker Linter is still not available on the Gitlab CI pipeline
• Building and Push the Docker Image
• Bump image version on the Helm charts

But the deployment workflow is still applicable even though some of the flows aren’t implemented yet.

Impacts

We observed some significant impacts since March 2023 when the SlackBot was first launched, such as:

• Non-techies could raise their VPN access requests by themselves without a steep learning curve. By providing a clear SlackBot guide, everyone could use this SlackBot easily.
• Trivial VPN access requests for individual users could be made by anyone, techies or non-techies. Moreover, they only need to wait under two minutes until the MR is posted on the infrastructure support Slack channel. It’s different if they have to raise by themselves.
• The on-call engineers from Cloud Infra Team only need to click and review the MR quickly before merging it. The rest of the task has already been done by Gitlab CI until the change is reflected in the OpenVPN Access Server. Less effort is needed.
• No more creating a VPN access request MR manually for someone. Engineers can focus on infra-support tickets during their on-call schedule.

It actually really helps everyone in the office.

Next Improvements

Some improvements that we might follow up on in upcoming periods:

• Decrease the pipeline duration for processing VPN access requests. Now it’s still around 15–30 minutes.
• Facilitate bulk VPN access requests.
• Notify the requester in the Slack channel whenever the VPN access request has been applied.
• Notify the requests via Slack DM if their VPN access request has incorrect parameters.
• And others…

Conclusion

By building a SlackBot, now both non-techies and techies could raise VPN access requests easily without using Git or Gitlab CI for trivial requests. By addressing the real problems, building the SlackBot could be meaningful and useful for everyone.

Love creating solutions that make life easier for everyone? We’re hiring problem solvers with strong engineering skills like you! Join our team!