To say that application architectures are evolving quickly is an understatement. In the age of cloud, mobile apps and back-end services can simply never go down. Developers are increasingly turning to scalable, resilient micro-service architectures based on Docker containers as a preferred way of building applications.
Stats from the last DockerCon 2017 event in Austin shine a light on the pace of change. Today there are more than 14M Docker hosts and more than 900K Docker apps. In just the last three years there has been a 77,000% increase in Docker job listings and a 390,000% increase in Docker image pulls. Payments are often a feature of cloud-delivered application services including mobile apps, online gaming, and new types of interactive voice-activated services. As a result, developers of payment-enabled applications are getting swept up in this enormous shift.
The Case for containerized applications
Among the reasons that developers favor containers is that they promote modular design, code reuse, unit testing and lend predictability to application deployments. If my application needs a database, key-value store, and a web-tier, rather than deploy hardware or a VM, I can simply pull Docker images of MariaDB, Redis or NGINX, add my application logic and publish my own derived Docker containers to my favorite registry. I can rapidly wire together these containers into an application comprised of multiple service tiers using a lightweight YAML (yet-another markup language) specification and publish a complex, multi-tier application to a containerized orchestration environment in seconds. The explosion of interest Docker and containers has ushered in a revolution in how applications are built and deployed. Today there are dozens of container management platforms supporting these types of applications including Kubernetes, Docker Swarm, Amazon ECS, Azure Container Service, Google Container Engine, Mesos Marathon and more.
Payment applications pose unique challenges
In this brave new world, containerized services are ephemeral, can scale up and down dynamically, and are placed on Docker hosts based on run-time conditioners by sophisticated schedulers. Application administrators often lack visibility to what VMs their services are executing on not to mention the cloud or physical host. These environments pose unique challenges for both Docker users and assessors when it comes to PCI DSS compliance. A discussion of securing Dockerized applications is too big a topic to address here, but a challenge that developers invariably face is how to securely make secrets like payment API credentials available to application logic inside a Docker container.
Enter Secret Management
This challenge of managing secrets is not unique to payments. Secret Management solutions have existed for years for Software Configuration Management (SCM) tools like Puppet, Chef, and Ansible. What makes Secret Management challenging for containerized applications are issues of scale, the breadth of public cloud providers and the sheer rapidity with applications evolve.
To explain the issue, imagine we have a cloud-resident component in a Docker container that needs to call one of Vantiv’s end points on behalf of a merchant. The challenge is how to get the credentials to the application securely. The credentials can’t reside in the Docker image itself, or they would be visible to anyone, and all instances of the application would share the same credentials. Similarly, they can’t reside in a YAML specification that is accessible to anyone on GitHub. We might have the idea of encrypting the credential and passing it to the container, but then the question becomes how do we distribute and protect the key needed to decrypt the payload holding the credential? If we attempt to pass the key across an encrypted channel, we still have the problem of passing additional keys needed to secure the channel. It’s a challenging problem. Dan Somerfield of ThoughtWorks describes this “bootstrapping” problem generically in his talk titled Turtles All the Way Down. What’s needed is a secure way to pass payment credentials in a fashion that is cloud provider agnostic.
Securing Payment Credentials in Containerized Applications
Because Docker containers are all in the rage in cloud deployments right now, I wanted to look at this problem in the context of Docker. As with so many areas of technology, there is not a single solution for secret management; there are literally dozens (partial list here). In the world of container orchestration frameworks, however, industry consolidation is taking place and leaders are starting to emerge. Kubernetes (open-sourced by Google) is enjoying considerable enthusiasm followed by Docker Swarm, followed by the big cloud providers with their container management and secret management solutions. (Google’s GKE uses Kubernetes, formerly known as Google Borg). If you learn the approach used by Kubernetes, the good news is that you can address a large number of container orchestration frameworks and cloud services that use Kubernetes as their foundation (list here).
For developers or operations folks who want to get their feet wet with Kubernetes secret management, I’ve developed an end-to-end example showing how secret-management in Kubernetes can be used to pass payment credentials used by Vantiv’s eCommerce platform securely. You can find this example in our Vantiv Labs area in Vantiv O.N.E.
If you’re interested in learning more about securely managing payment credentials in Kubernetes, check out the explanation and example here. I’d love to get feedback and learn how developers are managing secrets in your applications.