Security in Containers and Cloud

In many security circles, one of the topics getting got a lot of attention is container and micro services security. The people working on containers explain that there are three areas that they've considered when looking at security. The intrinsic security of the Kernel and its support for namespaces and C-groups. The community feels that attacking a process within Linux is difficult because of SELinux. Also, most vulnerabilities come from loopholes created by users in the way they do container configuration. The focus on the container is not where the primary issue lies because containers are now being deployed in multiples (Pods) to be able to distribute the workload across multiple systems.  We need a whole new paradigm created for the application-centric cloud that deals with security well beyond what container groups are looking at.

The claim that each container gets a network stack is excellent; it's when you have multiple containers that a whole new paradigm is needed. We need a whole new concept that defines the basic mechanisms for providing secure messages between containers. The Open Container Project needs to use a base mechanism and define additional primitives so that the extensions to the container's plug-ins provide security tokens.  To enable the issuance and dissemination of credentials between containers within a container pod to enable secure communications between two containers or multiple containers. We need a new method to create a mechanism for dealing with methods of issuing, reviewing, and validating security.  The container needs a plugin as a broker for these relationships.  The VLAN or web service framework attempts to describe the services so that they can achieve their security goals.

The goals of security include enabling trusted exchanges between containers.  This trust is created through an exchange and brokering of trust security tokens in the protocol agnostic way, enabling it to issue, renew, and validate the security of the application.  It needs to exist in an extremely lightweight order to make all the containers support scale.  Building a container or a micro service, the author will explicitly describe the security procedures for the service.  Every security protocol in the new standard must be applied to ensure specific profiles and message exchanges. 

In the new container applications, a trust engine can conceptually evaluate the related security aspects of the containers' messages to each service. It must grant a token of trust that can be exchanged based on the type of service. The container using trust must be willing to rely on a broker to execute a set of actions. The broker must have scope giving direct trust to multiple containers. When containers are micro services, there has to be direct brokering and trust.

So, the key is to create a token security framework within a plug-in that permits the use of tokens to ensure that the recipient container has a secure exchange. It is very hard to define a framework that deals with specific actions and very specific contexts. It is also critical that the framework deals with contacts within time

A classic example of this type of security brokering is when a container comes from a service such as Google, and the container call for that service or container ensures that the service creates a secure path. Both containers invest in the security of the exchange. As we moved to online payments within containers and micro services, this will become more and more critical. Sources need authentication and may require additional validation to get acceptance. This area is nascent in its creation and will grow over time but cannot be an inhibitor to the creation of applications in a composable manner to be used the application-centric cloud.