Contributed Content
By Chen Nisnkorn, Sr. Director, Technical Sales, Proofpoint and Meta Networks
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,” when he said, “Developers have responsibilities to enable, and in many cases operationalize, their service. Now there is a new movement to include and collaborate in a similar way with security. This is all part of the ideal approach where we shift everything left in the delivery pipeline.
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 article, I’ll discuss how DevOps teams can automate and ‘own’ secure network connectivity, thereby simplifying and accelerating a task which often slows them down. And this is by no means an isolated issue. According to a survey by the SANS Institute, “Seventy-three percent of respondents, a 30% increase from [from the prior year], are defending applications in the public cloud, and 34% expect to do so in the next 12 months. Sixty five percent are already involved in securing applications in containers (up from 28% in 2017), while 45% expect that this will increase in the next 12 months.”
With DevSecOps now on the table for most organizations, it is time to take account of one’s operating environment in order to design and/or implement a security infrastructure that not only defends critical application access, but does so in a way that is simple, efficient and cost-effective.
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.
Zero-trust secure remote access solutions offer a no-compromise alternative for DevSecOps. Advanced approaches in this area allow developers to proactively secure access to DevOps and cloud environments while building automated access policies into their 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 secure cloud networking. Many experts now recommend a global overlay network deployed over a worldwide backbone of PoPs. The distribution of PoPs and their proximity to remote users has the ability to provide an optimal user experience when remotely connecting to enterprise and cloud resources, regardless of location. The right zero-trust remote access solution would be designed around users, rather than data centers or offices. Administrators centrally define policies that precisely control the network resources users can access. Users connect once to the secure network, and from there to the targets defined by policy – whether they are in the data center, the cloud, or a branch office.
Of course, remote access policies are not limited to the admin user interface (UI). Admins 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 a secure remote access solution like a zero-trust software defined perimeter (SDP), 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 single certificate and a virtual appliance by running an automated script. The same solution/service is used for all clouds (private and public). With it, administrators define the services or subnets they want to expose and centrally define policies for access. All access is micro-segmented and fully logged and audited. The admin easily creates links to provide simple, one-click access to the consultant from her browser.
Example: Automated Access
The process can also be automated for CI using an API. Let’s take a look at how that would work on the last step in the process above, creating an “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. When the consultant visits the SSL-VPN portal, she might see a screen 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 mapped used HTTP. The zero-trust SDP solution (in this case) is providing secure access to an insecure internal resource.
Chen Nisnkorn is a full-stack technology leader with a background in R&D, Sales, SE, and CS focused on building long term relationships with customers ranging from Fortune 500 companies to start-ups. To learn more, download a detailed whitepaper on the subject.
1. SANS Institute, 2018 Secure DevOps: Fact or Fiction?, October, 2018
Dec2019, Software Magazine
