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.
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.
Intel’s Nick Weaver Discusses Orchestration
Listen to all TNS podcasts on Simplecast.
Docker and Intel are sponsors of InApps Technology.
Feature image via Pixabay.
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
