Containers and MicroServices Introduction

This topic is based on Research Spotlight Technology Review – Container Implementation, CMS TRB Technical Topics, 23 January 2018.

Container technology is a method of virtualization and an alternative method to virtual machines for implementing virtualization. Containers provide operating system-level virtualization, which runs on a single control host and accesses a single kernel. Containers use the host OS features to create virtual instances that share the same OS kernel while a hypervisor creates VMs, each of which can run an OS and none-of-which share an OS. This can provide efficiencies over VMs because a kernel does not load for each user session and uses less memory and CPUs than VMs running the same workload.

Container Architectures

There are many options when it comes to deploying containers. Container products are shipped with multiple features and have associated tools that control the scaling and deployment / placement of containers (orchestration) within the infrastructure. (The interested reader is encouraged to read the TRB Research Spotlight paper on the Orchestration of Containers).

Development teams have implemented containers using various levels of sophistication. Some groups have deployed containers without the use of these orchestration features, opting to control deployment and scaling in a more manual fashion. Other development groups have opted for full incorporation of the tools into their DevOps and production environments.

Implementations using full container orchestration platforms typically have separate instances of these tools in each environment (development, test, production); and may also include an additional separate instance to support containerized tools to support DevOps and deployment processes. Although many of these container orchestration platforms are capable of multi-tenancy deployments, this separation helps to enforce access and deployment controls across environments. Sample Implementation of Container Management / Orchestration Components depicts a sample implementation for the production environment; other architectures are possible depending upon a project’s requirements.

Generally, the container orchestration tools handle automated provisioning, deployment, and scaling of containers across the hosts. These tools typically leverage an overlay network that is on top of CMS’s traditional zone-based network. Each of these should be configured to enforce the appropriate routing and traffic flow policies according to CMS policies and guidance. The implementation of containers and overlay networks at CMS are still required to meet CMS TRA and CMS ARS standards to ensure the required level of protection to mitigate many of new exposures introduced in the environment.

Security

Virtualization is an abstraction layer that separates that environment from the underlying physical hardware. VMs utilize individual kernels, which limits the attack surface to the hypervisor. In theory, this means vulnerabilities in a particular OS cannot be used to compromise other VMs running on the same physical host. Containers share the same kernel; therefore, extra care must be taken to avoid security issues from adjacent containers.

Business Rules and Recommended Practices

Business Rules

BR-CA-1: The CMS Zonal Architecture Must Be Preserved

The CMS Multi Zone Architecture (CMS Multi Zone Architecture) calls for the implementing a zonal architecture with at least three security challenges prior to accessing CMS data. The zones (e.g., Presentation, Application, and Data) must be on separate virtual machines (VMs) and subnets. A VM / physical host may only support one zone. An individual container is not allowed to encompass a complete application (multiple zones). The Presentation, Application, and Data Zone components must be split into separate containers and deployed onto the corresponding VM/physical host for that zone as shown in the Sample Container Implementation diagram below.

 

BR-CA-2: Lower Environments Must Be Separated from Production

Development, test, and implementation may not be implemented on a VM / physical host serving production.

BR-CA-3: The CMS TRA Zonal Hierarchy Will Be Enforced

The CMS TRA Zonal hierarchy will be enforced. Communications to the data zone requires that the other implemented zones be traversed, not allowing the Data Zone to be accessed directly. This requires Presentation-to-Application and Application-to-Data Zone communication; communication from Presentation Zone directly to Data Zone is not allowed. The traffic must be challenged in each zone and not be a pass-through component such as a load balancer.

BR-CA-4: Interfaces between the Containers Implemented in Each Zone Must Be Locked Down (Source / Destination)

Locking down the interfaces and placement of containers in the CMS TRA Zonal architecture can be accomplished using a combination of:

• AWS VPC rules and security groups
• Subnets (each zone is usually sub-netted)
• Network Access Control Lists – NACL
• Container Interface and placement rules within the orchestration software. This would include any namespace rules. With network namespaces, each collection of containers (sometimes referred to as a “pod”) gets its own IP and port range, thereby isolating pod networks from each other on the node.

BR-CA-5: Container Traffic to Non-Container or External Destinations Must Follow Existing TRA Rules

Outbound traffic must flow out through the Presentation Zone and internal communication must adhere to the CMS TRA Zonal architecture.

Recommended Practices

RP-CA-1: Force Containers to Write to Container-Specific File Systems

RP-CA-2: Implement Read-Only File Systems Whenever Possible

Docker containers are read-only. Other container systems may not be.

RP-CA-3: Run Your Containers as Non-Root Whenever Possible

Treat root within a container as if it is root outside of the container.

RP-CA-4: Create Containers with the Least Privilege Possible

Dropping privileges is important and still the best practice. Even better is to create containers with the least privilege possible. Remove all capabilities except for what is explicitly required by the container. Be aware of default privileges that are set on container creation. Containers should run as user, not root.

RP-CA-6: Use a Security Mechanism for Mandatory Access Controls

Security mechanisms such as SELinux or AppArmor enforce mandatory access controls (MAC) for every user, application, process, and file.

Related CMS ARS Security Controls include: CM-3 - Configuration Change Control.

Rationale:

Mandatory access controls provide an additional layer of security to keep containers isolated from each other and from the host. Note that the STIG for RedHat Linux requires SELinux.

RP-CA-7: Use Cgroups

Cgroups (control groups) limit, account for, and isolate the resource usage (e.g., CPU, memory, disk I/O, network) of a collection of processes. Use Cgroups to ensure your container will not be stomped on by another container on the same host. Cgroups can also be used to control pseudodevices, which are a popular attack vector.

Rationale:

RP-CA-8: Use a Secure Computing Mode Profile

A secure computing mode (seccomp) profile can be associated with a container to restrict available system calls.

RP-CA-9: Harden All Containers / Components

The containers / components should be hardened to the appropriate guidelines (CIS, DISA, etc.)

Rationale:

RP-CA-10: Validate All Third-Party Containerized Applications before Implementation

Many people / organizations are releasing containerized applications. Before implementing a third-party containerized application, it must be validated to ensure no security risks exist. Use image-scanning tools to detect known vulnerabilities and validate security controls. Use runtime container tools to scan and monitor processes for security risks.

Rationale:

RP-CA-11: Maintain the Immutability of Your Containers

Do not patch running containers; rebuild and redeploy them instead.

Rationale:

To be supplied.

Container Best Practices

The following are best practices for implementing containers:

• Containers enable a microservices approach to application design, where complex applications are split into discrete units. This reduces the complexity of managing and updating the application because a problem or change related to one part does not require an overhaul of the entire application. Segregating containers by host, by function, or even by data classification or type when possible helps to secure your infrastructure by applying specific and predictable access control rules. This approach also helps detect abnormal activities much faster, enhancing security stance against zero-day attacks.

• Test, test, test. The only way to learn if containers will work is to build test applications. That means replicating real-world use, including containerization of real workloads.

• Consider the architecture. Using containers in the cloud means more architecture and planning. The ability to limit dependencies, scale efficiently, and replicate soundly will pay dividends as the application is deployed. This includes the management of resources used, application performance, reliability, and portability.

• Container images should be tagged appropriately, perhaps including the destination environment name, within a secure image repository. This can help to ensure that images only get deployed to the appropriate environments.

• Business units at CMS should plan and develop architectures for the possible sharing of container images across projects.