Virtualization Technology News and Information
Storming the Bastion, While No-One Gets Hurt
APIs Allow DevOps access to Bastion hosts - without compromising security 

By Albert Mugisha, DevOps/Site Reliability Engineer at NetFoundry

Restricted access is vital for security. You want the bad guys kept out, but you also want the good guys to have access without making it so cumbersome that they will be tempted to try unsecure shortcuts.  As a DevOps engineer, one of my biggest problems was how to gain secure access to servers in a private zone. Servers are typically in a secure zone with access only granted from specific hosts to minimize the risks of attack. The problem is even more complex when what you need to connect to is hosted by a cloud provider - such as AWS Azure.

Traditional solutions in the marketplace involve either a VPN to setup a secure connection, or a bastion host to tunnel connections through. While they work, such solutions are typically very static, slow and manual. Static connections remain always up, even when not being used. That is not good security practice.

In many cases, such as when using a bastion host, exposing any other service other than SSH usually involves SSH tunneling which also has its own security implications - see diagram.


A different approach

I decided on a different approach:

  • What if I could spin up secure networks on demand from my client to a server behind a private zone?
  • What if I could only expose the services that I needed to ensure that my network is not accidentally exploited?
  • When no longer using the network, I want the option to spin it down until I need it again.
  • And finally, I would like to integrate this into my automation tools like Jenkins.

I found I could achieve this  virtually using NaaS (Network as a Service), Jenkins and REST APIs

Network as a Service (NaaS) is a business model for delivering wide area network services virtually. Configuring and operating routers and protocols, WAN optimization and other components, such as firewalls or software-defined WAN endpoints, becomes very complicated: Today's network software, however, is able to abstract this complication and expose REST APIs to setup just what is needed from the network.

Jenkins is an open source automation server. It is a server-based system, running in servlet containers such as Apache Tomcat. It helps to automate the non-human aspects of software development with continuous integration, and it facilitates technical aspects of continuous delivery.

High Level Design

My goal was to access an Nginx webserver sitting in a private VPC with a private address. The webserver serves as front end for sensitive data ­- restricted for internal consumption and not publicly accessible.

My solution uses a Jenkins pipeline to call REST APIs to setup a secure network to the Nginx webserver - as shown. Automation ensures that this action is repeatable, so I can spin the network up and down as needed.


The Jenkins "Pipeline" outlines the necessary steps to creating this secure network. The pipeline, written in Groovy, calls REST APIs to perform the required actions. 

1 - (Optional) User Input. This collects any variable information - the name of the network in this example. This is optional, as we can generate a network name directly from the pipeline.

2 - Login. The next step is to Login in to the REST API using credentials set up from the Console. Reference for REST API docs on authentication can be found here.

3 - Create Network. Once successfully authenticated, we can create a network with REST API calls to the Netfoundry API for the action: Create Network.  An important point: there are no app-WANs on this network yet, even after the network is created. It cannot carry traffic until an app-WAN has been added. This is an async process: you will need some method to keep checking the network status to confirm it is created, before moving to the next stage.

4 - Create Gateway. You need to create a gateway within your internal VPC with access to the Nginx web server. This Gateway acts as a proxy of the requests to the Nginx web server - allowing it to be accessed from the network created in Step 3. This is precisely why this setup can replace the bastion host. Creating the network will spin up a control plane and Transfer Nodes used for carrying traffic from point to point.

5 - Create Service. This is similar to opening up a Firewall Rule or Security Group Access. Destination IP will be your Nginx server and any local IP which will be used as an intercept IP. Reference:

6 - Create AppWAN. AppWANs define how endpoints (in this case the local software client on my laptop) are permitted to access services. Each AppWAN is managed by a software controller, enabling the administrator to benefit from the fabric without needing to manage the underlying network.

7 - Attach Service to AppWAN. Add the Service to the app-WAN created, so my network has access to Nginx webserver. The last step is to login to the console and create a client for accessing this network.

8 - (Optional) Delete Network. This optional step allows you cleanup once the network is no longer needed.  


This combination of tools allowed me to access the Nginx webserver, previously unreachable without a Bastion host. Key advantages of using the REST API's instead of a Bastion host.



About the Author


Albert Mugisha is a technology and network engineering specialist serving as a DevOps/Site reliability Engineer at NetFoundry, Charlotte North Carolina. His technology range of expertise includes AWS cloud (EC2, RDS, S3, ELB  CICD & Build Pipelines ( Jenkins, Bitbucket Pipelines, Artifactory, SOAPUI Testing); Big Data & Analytics, including Redshift & Quicksight, and ELK (Elasticsearch, Logstash, Kibana, Machine Learning); Opensource, including Graphite, Grafana, Kafka. Mugisha is Project Management Professional Certified (PMP).

Published Wednesday, August 21, 2019 7:33 AM by David Marshall
Filed under: ,
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<August 2019>