search

vmware / vic

vSphere Integrated Containers Engine is a container runtime for vSphere.
http://vmware.github.io/vic
Other
640 stars 173 forks source link

Engine should not allow ContainerVMs to run if their vulnerability degree exceeds the project threshold #4562

Open keramix opened 7 years ago

keramix commented 7 years ago

User Stories

As a VIC Admin, I should be able to prevent developers from deploying containers in production environments if the container images have vulnerabilities that exceed the maximum allowable threshold set in the project preferences/policies.

Details

Admiral Users will be able to set vulnerability scanning preferences/policies when they create a project. Based on the outcomes of #4554, a VCH might be responsible for enforcing policies related to allowing/preventing running containers if they meet a certain a vulnerability criteria.

Acceptance Criteria

docker run should not pursue if it is based on an image with vulnerabilities that exceed the allowable threshold set in the project preferences. Otherwise, docker run should presume normally

hickeng commented 7 years ago

@akshayl @karthik-narayan @mdubya66 I have real concerns about this - the user story I can get behind, but I think enforcing it conceptually at docker run is flawed. My concern is focused around event sequences such as:

  1. deploy app into production - images are pulled to some docker hosts.
  2. new vulnerabilities are found in an image that's part of the app and the project threshold is now violated.

In a very, very static environment this isn't necessarily a problem, however container orchestration isn't engineered in that way and it doesn't account for outages:

a. host goes down - containers should come up on another host but one does not because it violates threshold - production app is now broken b. orchestration rebalances containers - cannot start one container on a new host because it violates threshold - production app is now broken c. orchestration rebalances containers - cannot pull image to new host because it violates threshold ....

This needs some very careful planning for possible scenarios and desired behaviours before anything automatic is implemented.

karthik-narayan commented 7 years ago

@hickeng I agree that these are very valid concerns and most customers are guaranteed to hit one or more of these.

The question is, can these be addressed in time for 1.2?

akshayl commented 7 years ago

What are some alternative ways to enforce the requirement? Is it possible to differentiate between "first run" and "rerun" due to rebalancing / reorchestration?

akshayl commented 7 years ago

The PRD addresses another related uses case i.e. "Handle Vulnerabilities in Running Containers". Perhaps we could use the behavior specified there for the scenarios you outlined?

akshayl commented 7 years ago

I have updated the requirements document to account for these corner cases.

mdubya66 commented 7 years ago

Removing from 1.2