Ansible Security Cloud: no open inbound SSH ports

While enabling us to manage our environments, Ansible helps improve our agility and automation by abstracting us from infrastructure and configuration complexities.

How awesome would it be if Ansible could also liberate us from dependencies on network and security infrastructure and vulnerabilities, such as VPNs, bastions, firewall rules and SSH access obstacles?

You don’t need to read the whole post to find the headline: we are pleased to announce that you can now use Ansible without the configuration, security and networking infrastructure dependencies.   

For example, you will be able to close all your inbound SSH ports, and replace the rat’s nest of inbound firewall rules with one policy: deny-all. We are not alluding to using obscure ports, dynamic opening or port knocking – we are talking about deny-all, always. If you prefer to play before you read, you can go to the repository for a demo and quick start. 

How can we make Ansible even more powerful?

Ansible is an extremely powerful automation tool. It configures systems, deploys software, and orchestrates DevOps tasks like continuous deployments and zero downtime rolling updates. Since Ansible connects into dev, CI/CD and production environments, increasingly in GitOps paradigms, security is critical.

Ansible does a fantastic job of security on the software side. Meanwhile, Ansible users are responsible for the secure networking side, and this is where the job of operations, networking, security and development teams gets complicated:

As you see above, bastion hosts, routing and firewall rules are cumbersome and difficult to manage and automate. Ironically, this is the opposite of why we use Ansible to begin with.  We want automation rather than configuration.

It can be even worse – for example, we often need VPN clients on our Ansible machines, and to manage all of this across multiple private data center and cloud environments.  

Finally, security is a problem because the rat’s nest of firewall rules still leaves behind open inbound ports.

Simpler, more secure Ansible networking

It is time to give ops, networking, security and dev teams a new option – a platform built to enable automation and agility while enabling a simpler and more secure environment. Here are the results:

Well, that looks better! What happened to all the complexity in the first diagram – what did we eliminate?

• We eliminated open inbound ports. SSH is now opened outbound from both sides of the Ansible Security Cloud, and then bridged in the middle for bidirectional data flows.
• We eliminated the bastion hosts. The deployment is now standardized, providing multi-cloud native networking across all private data centers, clouds and edges.
• We eliminated VPN clients (for cases in which VPNs were required).
• We eliminated complex inbound firewall rules and IP address dependencies. The inbound firewall rule set is now simply “deny-all”.
• We eliminated headaches in obtaining permissions for inbound SSH access (so we can now use Ansible in use cases such as IoT remote management – which are often difficult to obtain inbound SSH access permissions into).

Eliminating all that means our lives got simpler, our deployments more secure, our mission to automate everything is now more viable, and we can use Ansible in more places with less imperial entanglements.

Sounds great, but what about the Ansible Security Cloud? Does it introduce complexity, more infrastructure or security vulnerabilities? Let’s take it for a spin.

Ansible Security Cloud – zero trust, open source based Ansible networking

Your Ansible Security Cloud is a service you control. You spin it up and down in minutes – via Ansible if you wish. Key points:

• Options: You have the option to consume Ansible Security Cloud as SaaS (hosted by NetFoundry), or you can host it yourself.  
• Open source: Your Ansible Security Cloud is enabled by OpenZiti, an open source zero trust networking platform used by development and ops teams across the planet, and leveraged by some of the world’s largest companies.
• Zero Trust: Your Ansible Security Cloud consists of on-demand, zero trust networking controllers, routers and endpoints. It is a zero trust SD-WAN overlay, controlled by you and dedicated to Ansible and any other sessions you choose to optimize.  
• Simplify: The underlying OpenZiti zero trust networking platform does much of the heavy lifting, enabling you to spin up Ansible Security Clouds in minutes. You are abstracted from the underlying infrastructure and networking but enjoy robust controls and visibility.
• Any use case: Your Ansible Security Cloud supports all protocols and use cases, and you choose what apps and sessions are allowed. It can be just Ansible if you wish. Everything is app-specific rather than network-specific, meaning you have app-level micro-segmentation, control, extensibility and flexibility.  
• Run anywhere: You extend your Ansible Security Cloud anywhere via SDKs, endpoints and routers.  The combinations of these options enable you to extend anywhere, even inside specific applications, with no agent needed. There are pre-optimized endpoints for Linux, Windows, Mac, Android, iOS and every major cloud available in each marketplace.  
• App-specific with private DNS: Your policies determine which apps and services are optimized by each endpoint.  For example, an endpoint on your Mac may optimize specific business apps but ignore Netflix. Each endpoint enforces this via a private DNS function (IP addresses can also be used). You can maintain your public DNS records if you wish, essentially, adding resiliency, and making it simple to transition.  
• Least privilege access: Your Ansible Security Cloud can only be accessed by identified, authenticated endpoints. Those endpoints can only access services according to your least privileged access policies (attribute-based access controls).
• Zero-knowledge encryption: All sessions on your Ansible Security Cloud are encrypted, and only you have access to the keys (zero-knowledge encryption).
• Your infrastructure is made dark: Your Ansible Security Cloud cannot initiate data sessions into your infrastructure. It only accepts connections which originate from your identified, authenticated, authorized endpoints.

Let’s take a look at a slightly more detailed version of your Ansible Security Cloud in a hybrid cloud networking topology:

• The three endpoints at the edges are OpenZiti zero trust networking endpoints – you’ll remember that we deploy those anywhere as software. The OpenZiti endpoint for Ansible is embedded inside Ansible!  The other two endpoints – IBM Cloud and a private cloud – can also be deployed inside a service or an application, for example, embedded in SSH or as a system daemon on the SSH host. In this case, we are showing the cloud endpoints as containers or virtual machines on the borders of each cloud.
• The three OpenZiti routers shown in the middle are just an example – you can spin up as many or few as you like (on demand, in minutes) – the minimum number is one if you wish to use the outbound-only paradigm.
• Your endpoints dynamically route according to the best available path at any point in time. Your routers form a fully resilient mesh, although you can dedicate certain routers for specific workloads (for geofencing etc. type reasons).  
• Your network controllers manage your routers, and those controllers inform endpoints of your policies (controllers and routers are just software – they can be co-resident or distributed).

And, in minutes, you programmatically spin all of that up or down – potential via an Ansible security playbook.

OpenZiti zero trust networking endpoints… inside Ansible

If you read carefully above, you noted that one of the OpenZiti zero trust networking endpoints is inside the Ansible code! Ok, that’s nice because it means we don’t need separate agents, but inquiring minds want to know how that’s possible! Let’s look inside Ansible to find out:

• You’ll likely recognize the Ansible playbooks. Playbooks are the set of scripts which Ansible will push out to its targets to help automate our workflows.  
• Paramiko is an excellent Python implementation of SSHv2 protocol (Ansible typically communicates over SSH). Ansible leverages connection plugins like Paramiko to connect to its target hosts (so Ansible can execute tasks on those hosts). Ansible ships with several of these connection plugins, and Paramiko is one of the most widely used. 
• ParamikoZ is Parmiko with zero trust networking infused. Paramikoz has OpenZiti endpoint code already built in. Here is the Ansible Collection for zero trust Paramiko.  Remember, when we discussed using OpenZiti SDKs to embed secure networking into services or applications? In this case, in less than 70 lines of code, using the open source OpenZiti Python SDK, we created a zero trust version of the Paramiko plugin (“ParamikoZ”). When ParamikoZ establishes its Ansible connections, they will be zero trust connections.  

Note: in this specific case, we used the Python SDK to embed zero trust networking into Paramiko (and hence Ansible). You can use the same Python SDK to insert zero trust networking into any Python app (or use a different SDK to insert zero trust networking into a different language). OpenZiti also has many other SDKs in other languages.

Deploying zero trust Ansible networking… and beyond

You have two options to get started with zero trust Ansible networking, eliminating your infrastructure obstacles, dependencies and vulnerabilities:

• Open source. We built a quick-start for you, that gets you up and running in minutes in a containerized environment.  You can do it now at GitHub here.  Simply clone the demo project, including the ParamikoZ plugin (Ansible Collection), a setup script, and instructions.  
• Hosted SaaS. This is free for up to 10 endpoints.  Start here.  Existing NetFoundry SaaS customers can simply swap Paramiko for ParamikoZ to add Ansible zero trust networking to your services.

The OpenZiti platform and NetFoundry SaaS can be used for any app. In fact, you can use the solutions to replace myriad bespoke solutions (VPNs, bastions, MPLS, etc.) with a single platform, consolidating and centralizing your identities, policies, visibility and controls across all users, use cases, clouds and networks

For example, we dogfood OpenZiti ourselves for other tools including SaltStack, Jenkins and our bastions. We also ‘Zitified’ Prometheus using the Go SDK. 

You use the OpenZiti SDKs to embed secure networking into any application – it will work just like the Ansible example above – choose your programming language and quick start enviro and go!  The OpenZiti open source zero trust networking platform repository is here, and you’ll find quick starts here. Talk to us in our Discourse if you have suggestions or questions on what we should work on together next.