Werner Vogels’ famous quote "You Build It, You Run It," advocating shared responsibility between developers and operations is a DevOps mantra today.
More recently, John Willis took it to the next level with “You Build It, You Secure It.”
Especially with DevOps on the public cloud, security cannot be ignored. One of DevOps’ daily activities, performed endless times, is enabling secure network connectivity. In this post, I’ll discuss how DevOps teams can automate and ‘own’ secure network connectivity, thereby simplifying and accelerating a task which often slows them down.
Make Secure Access Part of the Plan
An important aspect of any cloud strategy is providing remote access that is simple, secure, and - as much as possible - automated.
This seems straightforward, yet most companies compromise on at least some of these goals. Secure remote access isn’t typically part of automated DevOps or DevSecOps processes. Instead, definitions are configured manually for each cloud provider. In other cases, automation is implemented but security is compromised.
The Meta NaaS secure remote access solution provides a no-compromise alternative for DevSecOps. It lets you proactively secure DevOps and cloud environments while building automated access policies into your CI/CD processes and production. DevOps teams get granular access to the specific applications and services they need (and nothing else) - all with minimal configuration.
Policy-Defined Access to the Data Center and the Cloud
First, a bit about our network. The Meta NaaS (Network-as-a-Service) is a global overlay network deployed over a worldwide backbone of PoPs. The distribution of PoPs and their proximity to remote users provides an optimal user experience when remotely connecting to enterprise and cloud resources, regardless of location.
Meta NaaS is built around users, rather than data centers or offices. You centrally define policies that precisely control the network resources users can access. Users connect once to the Meta NaaS, and from there to the targets you define - whether they are in the data center, the cloud, or a branch office.
Of course, remote access policies are not limited to the admin UI. You can use the API to include access policies as part of DevOps workflows, thereby automating and accelerating security, reducing risk and increasing productivity.
Example: Enabling Remote Access for a Consultant
To understand the complexity of the problem, consider a case where you want to provide a consultant with access to a Jenkins staging environment in the cloud so she can investigate an issue.
A traditional network topology using OpenVPN usually requires the following:
- Installing OpenVPN
- Setting up the certificate authority (CA) directory
- Configuring the CA variables
- Building the certificate authority
- Creating the server certificate, key, and encryption files
- Generating a client certificate and key pair
- Configuring the OpenVPN service
- Adjusting the server networking configuration
- Starting and enabling the OpenVPN service
- Creating client configuration infrastructure
- Installing the client configuration
- Defining access rules
With Meta Networks, setting up remote access is significantly easier, with nothing to install or configure on the client side:
- Instead of steps 1-9 above, install a certificate and MetaPort virtual appliance by running an automated script.
- The same solution/service is used for all clouds (private and public).
- Define the services or subnets you want to expose.
- Centrally define policies for access. All access is micro-segmented and fully logged and audited.
- Create easy links to provide simple, one-click access to the consultant from her browser.
View the video below to see how this would work: https://www.youtube.com/watch?v=DkV_oJkV5sA
Example: Automated Access
The process can also be automated for CI using our API. Let’s take a look at how that would work on the last step in the process above, creating the Easy Link.
An API call would create an access link like the one below, to the Jenkins server and enable the external consultant to access the Jenkins instance and debug.
http POST https://api.nsof.io/v1/easylinks name=Jenkins(AWS) mapped_element_id=ne-44 protocol=http domain_name=10.0.0.4
When the consultant visits the SSL-VPN portal, she might see a screen similar to the one below (which includes links to additional network resources). Clicking the Jenkins(AWS) link will take her to the server:
Note that the remote access takes place over SSL (HTTPS) despite the fact that the Jenkins server we mapped used HTTP. MetaConnect is providing secure access to an insecure internal resource.
Learn more
Learn more about Meta NaaS or Contact us for a live demo.