Given that more enterprises now realize the value of application containerization and the pace at which enterprise technologies continue migrating to the cloud, one would assume that cloud and containers would go together like Fred and Ginger. After all, it seems like a logical fit: the cloud enables users to abstract the substrate on which their applications run, while a containerization strategy built on Docker or rkt containers enables users to create portable, self-contained bundles within which applications can operate.
In practice, while both concepts are powerful and flexible on their own, using them together occurs less often than one might think. This is the case for a few reasons, not the least among them being security considerations.
For example, RedHat's Daniel Walsh spoke at DockerCon in 2014 and outlined ways in which the segmentation models employed under containerization are different -- and thereby potentially more porous in some circumstances -- compared to OS virtualization. He noted that the segmentation models have multi-tenant implications that call for careful evaluation by security professionals when considering a production container in the cloud deployment. It's not that organizations can't employ such a strategy or that some aren't doing exactly that -- just that the additional scrutiny from security teams can slow organizations down.
Over time, as organizations have become more comfortable using containers in general, as practitioners have become more familiar with the security model and as containerization technology providers have worked to shore up segmentation models, container use in the cloud is starting to expand. As it does, organizations must find a way to manage containerized applications at scale -- i.e., orchestration. Some of the container orchestration options can also provide security benefits -- while also adding new requirements for them to be used securely.
Cloud container orchestration
Most security practitioners are already familiar with orchestration in the context of virtualization technologies. These are the technologies that enable large-scale management -- deployment, assembly, positioning -- and they also govern the interactions of virtualized OS images at scale. Container orchestration is very similar.
Instead of attempting to control the deployment and behavior of each container individually -- an approach that does not scale well -- technologies like Docker Swarm or Google's Kubernetes can be used to set behavior for groups of entities called nodes, which are the physical or virtual substrate on which containers run, and pods, management units consisting of one or more containers and their shared resources.
By setting behavior standards and defining how containers should operate and interact in aggregate, enterprises can control -- and rapidly change -- the behavior of the system as a whole. Businesses can control the various elements within the system that govern application behavior without getting bogged down in the minutiae of the implementation details or managing each container individually.
Container orchestration affects security; in particular, when used directly as part of a security strategy, it can help build better, more secure applications. Because it's possible to assign specific pods to specific nodes, and because the parameters of how nodes operate are customizable, enterprises can build architectures in which certain pods run in the cloud and others do not.
Users can also assign a security policy to pods, enabling everything from authentication, enhanced logging, and network or resource isolation. It's also possible to leverage the features of Security-Enhanced Linux and AppArmor as part of that strategy.
In capable hands, this can offer both power and versatility to security teams, and has the additional benefit of enabling application security strategies that might not otherwise be available. This approach can be used to define how control applications behave in response to specific security concerns, especially when a response to a specific threat scenario is not defined by the application directly.
Obtaining this flexibility and getting to a reasonable degree of confidence and assurance does require some legwork. It requires not only a general understanding of the containerization security model, but also how Kubernetes itself works -- and this knowledge should inform the technical security strategy. It's also important to understand what specific constraints apply to the use of Kubernetes with particular cloud providers or sets of providers.
While the Kubernetes page provides helpful guidance on how to set up orchestration with various cloud providers, including which features are natively available and provider-specific tools to help, it can also make things more complicated. And, while robust application security practices, like threat modeling, can help to make decisions about how to apply security and use orchestration features to the best effect, it is worth noting that many organizations aren't as disciplined with application security as they are about the lower levels of the stack.
Container orchestration in the cloud is a useful topic for security practitioners to start learning about now so that they can be ahead of the curve when their organizations begin adopting it more fully. If your organization makes heavy use of either the cloud or containers, doing this legwork now is time well spent.