Easily Overlooked Container Security Risks
May 3, 2019
Easily Overlooked Container Security Risks
Some of the best designed container systems are still susceptible to major security breach. Even those with container security systems fall prey to their own poor planning. How is it that cloud container security is not ensuring data integrity or preventing data compromise?
What is Container Security?
Container security has familiar controls such as:
- Access to build/update container software, code, deployment.
- Operating system security including patches and operating systems.
- Container labels (see table below for container definitions) that ensure services and replication across the network node occurs appropriately.
Before we get too far along in container security, let’s break down what a container is and does. We want to understand how the above security does not fully protect data or systems.
What is a container?
Simply stated a container is a software that packages code (and all the code dependencies) so the application runs quickly and reliably from one computing environment. The container image becomes a container at runtime. The table below outlines the container components that make up the functionality of platform performance.
A group of one or more containers that are created, scheduled and deployed together on the same node.
The key-value tags assigned to identify Pods, services, and replication controllers.
Group of Pods acting as a load balancer to direct traffic to running containers.
Framework responsible for ensuring that a specific number of Pod replicas are scheduled and running at any given time.
Notice we have layers of functionality in container management. We have a security requirement at the Operating System (OS) level, the network level, the container level, and there is the replication controller (also known as orchestration).
So how is it that container security is not enough protection? Because of how the management of each layer is often handled by separate functions in the IT organization. DevOps has great agility in cloud applications. Here is where we see the security exposure on containers and underlying infrastructure.
Access Administration Security Risks
Containers are not agile. Access to the container is access to both container software and code. Authorizations within the container are not transparent.
Insider threats come from any number of sources:
- Unauthorized installs
- Abnormal login attempts/failures
- Key file changes
This is just the beginning.
Change Management Security Risks
Orchestration tools have full permissions across all containers/Pods. Changes made to container 1 replicate to all containers in a Pod on the same node. Replication of an error or vulnerability may occur rapidly. DevOps can create new services without mapping to container boundaries or segregated access controls.
- Kubernetes (also known as K8) is designed to orchestrate platform and tool building and works well with container tools such as Docker.
- Amazon’s own native container set-up Elastic Compute Cloud (EC2) is designed to orchestrate build, distribution, and running containers.
Security may not be included in the DevOps team’s management plan. As a result, containers may never be updated to use current AMI instance or current versions of orchestration tools such as AWS Internet of Things (IoT) GreenGrass core.
Network Management Security Risks
The Pods are part of a cloud network. Cloud network security has the same dependency as on-premise security for patch and upgrade management. If the operating systems are not updated with current patches and supported versions, an exploit is feasible.
Vulnerability runC allows malicious containers to overwrite the host runC binary, gain root-level code execution on the host. If the latest patch has not been applied, like on-premise systems, the exposure may be exploited.
Container Security Platform Risks
The container security settings are designed for efficiency, not preventing vulnerability exploits. The design and management of containers require additional configuration and oversight to reduce exposures.
Across container orchestration tools, we see common security gaps in using container security platforms. Docker Hub has found cryptocurrency miners in numerous images. Amazon posted a notice on vulnerabilities found on open-source container management systems.
AWS EC2 or Kubernetes-related products are susceptible vulnerabilities. This includes
Manage Container Complexity Risks
Container orchestration relies heavily on your infrastructure.
- When applications are mapped to a container IP, the application may change containers causing obsolescence of IP maps.
- Misconfiguring based on the OS. SELinux containers are difficult to set up correctly as they were designed to run on servers. DevOps may set it up for functionality, but not security as that is outside their expertise.
- New services are launched without security management, gaps in namespace, provisioning, mapping and so forth.
How does your solution integrate with cloud/on-premise solution? Are you buying more toolsets to get things done?
How To Mitigate Container Security Risks
Review your current orchestration tool configuration settings and be sure to refresh internal policies and procedures for patch management to include container infrastructure components.
- Know that out of the box vendor software is not inherently secure (K8 API listens on port 8080 with no security checks).
- Benchmarking security maturity (system access & users, patching & vulnerability mgt, infrastructure control plane, networking, runtime & services).
- Patch and vulnerability management.
- Deploy defense in depth-use tools to protect K8 clusters from exposure to the open internet (NGINX for example). Helps engineers not have to manually provision namespaces each time developers launch a new service.