Use these CCSK practice questions to prep for the exam

Containers

In Chapter 7, I mentioned that containers could help address portability but that this technology relies on more than just source code and that all components need to be properly secured. This section covers the various components of a container system and the high-level security recommendations from the CSA. Note that although container technology is fairly mature, it is a rapidly evolving technology.

You know that containers are a compute virtualization technology and that they differ from virtual machines in that only the application and required dependencies are bundled in a container, which is then run in an isolated user space on a shared kernel. Containers can run directly on a physical server (even a laptop), or they can run in a virtual machine.

Container systems always have the following components:

• Container. This is the execution environment itself. The container provides code running inside a restricted environment with access only to the processes and capabilities defined in the container configuration via a configuration file (covered later in this chapter). While a VM is a full abstraction of an operating system, a container is a constrained place to run segregated processes while still utilizing the kernel and other capabilities of the base OS.
• Engine. Also referred to as the container runtime, this is the environment on top of which a container is run. A very popular example of a container runtime is Docker Engine. This isn't to say it's the only container runtime, but it is arguably the first container runtime (as we know containers today) and it is the most well-known.
• Orchestration and scheduling controller. Container orchestration deals with managing the lifecycle of containers. Orchestration deals with items such as provisioning and deployment of containers, scaling, movement of containers, and container health monitoring. When a container needs to be deployed, the orchestration tool schedules the deployment and identifies an appropriate system to run the container on. It knows how to deploy and manage containers based on a configuration file that tells the orchestration software where to find the container image (repository) and configuration items such as networking, mounting of storage space, and where to store container logs. Examples of container orchestration and scheduling tools include Kubernetes and Docker Swarm.
• Image repository. This is where all of the images and code that can be deployed as containers are stored. Docker Hub is a popular example of a container image repository. Image repositories can be public or private.

Keeping all of these elements in mind, I hope you can appreciate how there may be some proprietary dependencies in place that make portability a bit more difficult than you may have expected. For example, what about moving a container from Windows to Linux runtimes (and vice versa)? What if you presently use Kubernetes as the orchestration and scheduling service and then decide to use a cloud provider's orchestration service instead? Are the runtimes backward-compatible? As I said, a container can help with portability, but it isn't a guaranteed magic bullet for portability.

Container Definitions Backgrounder

As you know, containers are built and managed according to a definition file you create. The definition file is passed to a service (daemon) to build an image so it is properly allocated resources and other configuration settings are implemented.

Following is a list of some of the available options in configuration files used by Amazon Elastic Container Service (Amazon ECS) to build and manage containers:

• Name. The name of the container
• Image. The name of the image in the repository that should be used to build the container
• Memory. The amount of memory to be allocated to the container
• Port mappings. The required network ports for the container
• Protocol. The required network protocol (TCP or UDP)
• Health checks. Monitors the health of the container; if the container is unreachable, it is removed and replaced
• CPU. The required CPU capacity of the container
• Working directory. The directory in the container where commands are run
• Secrets. Credential storage location outside of the container
• DNS servers. A list of DNS servers for the container to use
• Mount points. Supplies data volumes
• Log configuration. Where the container should store logs
• User. The username to use in the container; the "privileged" user can run everything as root (administrator)

Now you should have a pretty good idea of how containers are built and how the orchestration and scheduling service launches and maintains containers. Again, you won't be tested on any of these items.

Container Security Recommendations

As I mentioned, container technology is maturing, but many products out there have their own security requirements. Following is a list of security recommendations from the CSA as to general security best practices that you should consider when deploying container technology internally or within a cloud environment:

• Securing the underlying infrastructure. Security always begins in the container, and in a cloud environment, this is the provider's responsibility. Just as the provider is responsible for security of the physical infrastructure and the hypervisors in a virtual machine world, the provider is responsible for the physical infrastructure and the container platform hosting consumer containers.
• Securing the orchestration and scheduling service. You know that orchestration and scheduling are critical components of container deployments and management. CSA Guidance refers to this as the "management plane" for containers.
• Securing the image repository. The image repository for containers can be considered in the same way as images for virtual machines. Images need to be stored in a secure location, and appropriate access controls should be configured to ensure that only approved access is granted to modify images or configuration files.
• Securing the tasks/code in the container. Containers hold software code. Weak application security will be weak regardless of whether it is run in a container or on a VM. Weak security isn't limited to the code in the container; it can also apply to the definition files you read about in the "Container Definitions Backgrounder." Appropriate network ports, file storage, secrets, and other settings can increase security of the container environment and therefore the application as a whole.

A final takeaway for security of a container environment is that tools will offer varying degrees of security. At a bare minimum, all products should have strong access controls and authentication capabilities. They should also support secure configurations that isolate file system, process, and network access.

CCSK practice questions

About the author

Graham Thompson

Graham Thompson is the founder and CTO of Intrinsec Security, a cloud security consulting and training organization that serves enterprises and governments across North America. He is a security professional with more than 25 years of experience in areas such as systems engineering, technical architecture, vulnerability assessment and a variety of management roles. He has built successful multimillion-dollar security solutions for leading enterprises and government agencies.

Since 2010, Thompson has dedicated himself to cloud security. He has architected and assessed cloud security solutions for government agencies and Fortune 500 financial, telecom and retail companies across North America. He is a CSA and (ISC)² authorized trainer of CCSK, Certified Information Systems Security Professional (CISSP) and Certified Cloud Security Professional (CCSP), a course he helped develop as a subject matter expert.

In addition to his CSA and (ISC)² certifications, Thompson has obtained multiple certifications, including Amazon, ISACA (Certified Information Systems Auditor), Microsoft (Microsoft Certified Solutions Expert), Cisco, Symantec, Fortinet, SANS and others. He attended McGill University in Montreal and has been an adjunct professor for multiple security courses at Algonquin College in Ottawa.