Apcera Offers Policy Engine For Container Deployments
The Trusted Cloud Platform from Apcera imposes policies for each container, then restricts what network traffic can reach them.
7 Ways IaaS Delivers Business Value
7 Ways IaaS Delivers Business Value (Click image for larger view and slideshow.)
Startup Apcera has introduced a new system aimed at automating security for wherever a Docker container may be running, whether on-premises or off.
The Apcera Trusted Cloud Platform, which the company officially announced June 28, attempts to impose a policy engine on top of container orchestration and management, so minimizing the possibility of human error allowing the wrong security parameters to be applied to a container as it gets deployed.
The Trusted Cloud Platform can be used for containers about to be deployed behind the firewall inside the enterprise, or outside the firewall into the public cloud.
To accomplish that, it has to impose an overlay on the data center network that allows the platform to dictate both what a given container may be connected to and when a group of containers may talk to each other. Without explicit permissions, communication access is denied. The denial keeps a container isolated from would-be intruders, explained Mark Thiele, Apcera's chief strategic officer.
Thiele was appointed to the post April 20. He was formerly the ecosystem developer for Switch SuperNap, a builder of highly-available data centers, and was the founder of Data Center Pulse, a best practices group for the data center industry.
"We start with a complete white list of what a container can do," said Thiele in an interview with InformationWeek. The white list specifies to which network segment it will be connected. All other connections are forbidden. It also specifies what other resources and other containers the workload may be tied into.
The white list serves as a guide for the formation of policies that will govern the container's behavior. The Trusted Cloud Platform imposes what both Thiele and information on the Apcera website described as a software-defined network over the data center's physical network that allows the platform's policy engine to enforce the policies as requests to access the container come up or as the container attempts to access outside resources.
In a follow-up interview, Apcera software architect Josh Ellithorpe shied away from using the term software-defined network and said the platform imposed a Layer 2 network overlay on the data center network. That overlay allows the container to be given an address that is shielded from any public view, but is mapped to a NAT address that is published as its location.
The policy engine can screen traffic as it arrives at the NAT address by looking to see whether it meets the rules of what the container may connect to before enforcing the policy, which either blocks it or allows it to pass through.
Apcera has supported continued development on the open source NATS messaging system as a cross-platform, message-oriented middleware. Written in Go, it's able to interface to different programming languages. It can be used by the platform to define a prescribed route that connects a container to its allowed resources.
Ellithorpe said operations managers have a second option within the platform that allows two or more containers to communicate with each other on the same network segment. Even then, that segment "is sandboxed," he said, from connections to other containers outside the defined group or to outside resources.
The isolation imposed by the platform is its guarantee of security. Outsiders and would-be hackers cannot send messages to containers under the platform's policy engine because they have no routable address, Ellithorpe said.
[Want to learn more about where Mark Thiele is coming from? Read In Cloud Adoption Rush, Don't Forget to Invest in IT.]
Thiele said once policies are set for a container, they will be enforced automatically until the operations manager or other authorized party changes them.
"You develop compliance-oriented policies" to make sure a container's communications are within the limits of what SOX or HIPAA-compliance requires. Thiele said the system facilitates compliance audits. It can be used to quickly establish what the rules are on a given workload and confirm that those policies are being enforced.
Thiele added that the platform is useful in refactoring existing applications for operation inside a container, which can then be moved around, its policies still enforceable from the platform's policy engine.
The policies will be enforced even if the container is put inside a virtual machine or moved off-premises and into the Amazon Web Services cloud, he said.
About the Author
You May Also Like