Scaling Enterprise DevOps Security With Machine Identity – Software Defined Firewall
| DevOps |
This is the third and final part of our ‘Scaling Enterprise DevOps Security with Machine Identity’ series. In case you missed the other posts, first we discussed Secrets Management, and next we reviewed SSH Management. In today’s post we are going to look at the final piece of the Enterprise DevOps security puzzle – Software Defined Firewalls.
One of the most unique and interesting challenges posed by cloud architecture is the need for granular access control to web services; especially the web services which make up the “control plane”. By control plane, I mean any application or code whose job is to manage the infrastructure and application deployment pipeline itself.
Small Scale Specific deployment zones are created and managed by ops. Inbound and outbound traffic is governed through specific rules (pipes & channels). Security oversees the configuration of the network from a security standpoint. Developers are pretty unclear about how the whole system works; mismatches between the needs and expectations of developers, ops and security are common and costly.
Large Scale Each application is deployed with a software-defined firewall (SDF). Traffic between individual application instances is governed by their own personal SDF. Access rules between applications are managed in terms of application identity (to the container level), and application authorization. Each app is managed as a service, with foreign identities being given specific privileges to make requests.
Access to control plane services must be tightly managed, because in cloud infrastructure these services literally have full control over the data and applications. These control plane services require:
- Encryption; messages and traffic must be encrypted in transit.
- User access control; management personnel must be able to invoke services in a controlled and audited way.
- “Robot” access control; interaction between services must be controlled and audited as well.
- Easy-to-use traffic authorization tools; usage of network access rules to govern control plane interactions is cumbersome, frequently breaks down, and imposes a large communication and break/fix overhead on developers and operations teams.
The typical approach to securing service access is to use network techniques like security groups, NAT, VPN, etc. Over the last two years I have helped dozens of companies to deploy and secure new control plane services, and networking configuration is always the #1 time suck.
New services can’t reach the old services; old services can’t reach each other; systems administrators make conflicting changes and break each other’s config; application deployment is slowed by broken network config. Finally, security configurations are opened up wide in order to get the damn thing to work. Sometimes they are tightened up later; sometimes they’re not.
The reason it’s such a pain is because the tools (security groups, VPN, iptables, etc) don’t map cleanly to the application architecture, troubleshooting is ad-hoc, there’s no clear reporting on what’s going wrong when connectivity can’t be established, and the access control fixes aren’t simple, granular or clear.
Again, strong machine identity and authorization offers an answer : authenticate and authorize traffic in a granular way at each service entry and exit point. So, rather than configuring network zones, and then deploying code within them and relying on the network to secure the apps, the network security is deployed as part of the application artifact.
In practice, protocol-specific authentication such as an HTTPS bearer token is required on each message. The token is issued according to the client identity (machine or person), and verified on the server side by a proxy interceptor. The authorization rules map exactly to the applications, so it’s clear how to permit or deny traffic as the deployment topology changes.
Secrets management, SSH management at scale, and software-defined firewalling are three tough problems in infrastructure management. In these three posts, I’ve attempted to describe how strong machine identity and authorization can be used to solve all three of them.
Here at Conjur, we’re best known as the company that invented secrets management for DevOps. But our mission is much bigger than that: our aim is to provide an enterprise-grade security orchestration solution to secure your DevOps infrastructure.