Application Security / Cloud Native / Containers / Data / Kubernetes / Microservices

Securing a Dockerized Service Architecture with Reverse Proxy

20 Dec 2016 9:05am, by

Rob Hirschfeld
Rob Hirschfeld is CEO and co-founder of RackN, which offers orchestration software for the container-centric data center. He has been in the cloud and infrastructure space for nearly 15 years, from working with early ESX betas to serving four terms on the OpenStack Foundation Board. As a co-founder of the Digital Rebar project, Rob creating a new generation of DevOps orchestration tools to leverage the containers and service-oriented ops. He believes that the technology of running data centers and applications on cloud is just part of the bigger story. Trained as an Industrial Engineer, he carries a passion for applying Lean and Agile process to software delivery.

Our company, RackN, has been on a multi-year transformation from a monolithic code base (OpenCrowbar) into a microservices-based platform (Digital Rebar). I’ve already posted about how we had to rethink service registration and persistence during the refactoring. In this post, I’ll talk about the changes required for our networking and service controllers including control APIs and reverse proxies.

Digital Rebar orchestrates services and configuration tasks to operate clusters on cloud and physical infrastructures.

As a microservices application, Digital Rebar is composed of multiple, independent services that work together to provide the whole experience. I previously detailed how we used Docker Compose as a service registry so that the services can find each other; however, that’s only a small part of making the architecture work. Most of the Digital Rebar services have both internal and externally exposed components.

Our services are things like DNS, DHCP, PKI and Provisioning and must expose those services in standard ways for Digital Rebar to do its job. The platform also needs to expose its own API and user interface plus internal only services like the PostgreSQL database and Consul. They also need to have control APIs so that we can manage the services based on system orchestration. The control APIs must be protected by a consistent security policy (both authentication and authorization) that spans all the APIs.

digitalrebar

Securing Services

We decided to use a reverse proxy (also Digital Rebar container) to secure the environment. A reverse proxy acts as a single gateway for all the service APIs. When requests come into the gateway, they are inspected and authenticated allowing us to provide delegated single sign-on (SSO) for users and also authorized for access based on user policy. That allows us to centralize user security so it does not become a burden on service authors.

Delegating user security to the reverse proxy created a problem: services have to trust that the inbound requests are legitimate.

If someone is able to send requests directly to the service control APIs then they can compromise the whole system. Our solution was to create an internal PKI (also exposed as a service) that generates a deployment specific trust zone. Only services inside the zone have the necessary encryption to communicate. Since no other party is given certificates, the reverse proxy becomes the exclusive system entry point.

The internal, dedicated Transport Layer Security (TLS) allows us to not worry when services move from a single system to being globally distributed.

One of the important realizations for the RackN team was that Digital Rebar services need both external ports and control APIs. This pattern keeps us from overloading a standard service like DHCP with additional control interfaces. We want to keep those services simple and strictly conforming to the standards. By having an added management API, we can provide a secure control channel. We can also use the management API as a shim if we want to use alternate services like an on-site DNS server.

Another design consideration was to focus on APIs for control instead of relying on centralized data. Since we own the services, it would be possible for them to all point to the Digital Rebar data directly for configuration information; instead, we chose to limit database access to API and engine services. This approach provides multiple benefits: fewer entry points to the database, less concern about geo-distribution of services, and simpler replacement of services because there are no assumptions about their access to internal data.

We’re proud of the architectural thinking behind Digital Rebar and also recognize that it’s a work in process. We constantly check and improve our design against actual performance and patterns that we see emerging.

I hope that our sharing inspires some ideas for your own architecture and you’ll share them with us too.

For more info on Digital Rebar, check out RackN’s extensive video tutorials page.

Docker and Intel are sponsors of The New Stack.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.