Home > Blog > Why Container Security Isn’t Enough

Why Container Security Isn’t Enough

Why Container Security Isn’t Enough

How is it 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) which ensure services and replication across the network node occurs appropriately.

Before we get too far along in container security, let’s breakdown what a container is and does. We want to understand how the above security does not fully protect data or systems.

Simply stated a container is 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. 

Pods

A group of one or more containers that are created, scheduled and deployed together on the same node.

Labels

The key-value tags assigned to identify Pods, services, and replication controllers.

Services

Group of Pods acting as a load balancer to direct traffic to running containers.

Replication Controllers

Framework responsible for ensuring that a specific number of Pod replicas are scheduled and running at any given time.

(source: https://caylent.com/containers-kubernetes-docker-swarm-amazon-ecs/)

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 the 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:

Containers are not agile.  Access to the container is access to both container software and code.  Visibility to who has access to what within the container is not transparent.  Unauthorized installs, abnormal login attempts/failures, key file changes are all examples of insider threats. 

Change Management:

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 managing the container by the DevOps team.  Such as not updating to use current AMI instance or current versions of orchestration tools such as AWS Internet of Things (IoT) GreenGrass core.

Network Management: 

The Pods are residing on 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: 

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 have common security gaps in using container security platforms.  

  • Last year Docker Hub removed 17 Docker images because they contained cryptocurrency miners. Do you know where your container images are coming from?
  • AWS EC2 or Kubernetes-related products such as Aqua, Twistlock, Stackrox, Docker are susceptible to vulnerabilities. Amazon posted a notice on vulnerabilities found on open-source container management systems.  Their February 13, 2019 alert pointed out vulnerabilities on Linux, ECS, Amazon Kubernetes (EKS), AWS Fargate, and more.  (source: https://aws.amazon.com/security/security-bulletins/AWS-2019-002/). 

Mange Container Complexity

Container orchestration relies heavily on your infrastructure.  How does your solution integrate with cloud/on-premise solution?  Are you buying more toolsets to get things done?

  • When applications are mapped to a container IP, the application may change containers causing obsolescence of IP maps.
  • Mis configuring 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.

Consistency in Patch Management

As the AWS CVE security notice points out, patch management is still required to ensure containers are running the latest versions 

Security Mitigation

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).
  • Patching 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.
Share this with your network
FacebookTwitterLinkedInShare