Deploy sentinel containers for each buildpack with Nessus agents

[dlapiduz]

In order to have more coverage of our OS scanning we should have sentinel containers reporting to nessus manager what OS level packages each buildpack is using and if there are any vulnerabilities on them.

Acceptance Criteria

• [ ] A pipeline is created to deploy an app for each buildpack
• [ ] There is an app per buildpack running the nessus agent reporting to the nessus manager

[jmcarp]

@dlapiduz: how do you think we should handle installing nessus agent on the apps? Looks like we could use buildpack-multi with apt-buildpack, unless there's a simpler option.

[dlapiduz]

yeah maybe we have to do that... Not sure what is the right way...

[jmcarp]

I took a quick look at this--I got nessus-agent to install with apt-buildpack, but I haven't been able to get it to run. It seems like nessus wants files to live in /opt/nessus_agent, but the buildpack installs packages in /home/vcap/app/.apt/opt/nessus_agent.

[ghost]

Seems like all we need to do is run nessus on the DEAs/Cells since the host has all the containers' files and processes.

[ghost]

This approach also covers external buildpacks--where a user references a buildpack by URL in their application manifest rather than specifying a platform-provided buildpack by name or letting the platform auto-detect the right buildpack.

[ghost]

But we could deploy sentinel apps for each platform-provided buildpack and rely on the nessus install on the host to scan them.

[dlapiduz]

@sushiandbeer we need to get the nessus to scan the libraries on the running OS so its not just about the files. We do run the agent in the runners but we need to run it in the containers too...

[ghost]

The rootfs files are found on the hosts at /var/vcap/data/packages/rootfs_cflinuxfs2, so nessus can scan them there. That is unless you mean nessus needs to scan them as they run. Even then, the host sees all processes since apps run in containers and not VMs.

[cnelson]

We think this should be retasked to scan the rootfs

[dlapiduz]

So I have an idea about this @cnelson @LinuxBozo @sharms:

What if we create a docker image with the basic filesystem and the buildpack, push it to somewhere where clair can scan it and run the scans there. We can also try to push it to the docker private hub and scan it there.

[dlapiduz]

Not sure how to create the image though.

[cnelson]

Do we want to scan the running apps themselves, or the intermediate compile container?

If the former, it's pretty easy:

# get the base cf stack
docker import https://github.com/cloudfoundry/stacks/releases/download/1.89.0/cflinuxfs2-1.89.0.tar.gz cflinuxfs2

# given an app, get it's compiled droplet
cf curl /v2/apps/6810626c-fe92-498f-8ac9-bb5ff1abb4fe/droplet/download > droplet.tar.gz && gunzip droplet.tar.gz

# smash 'em together
echo -e "FROM cflinuxfs2\nADD droplet.tar /home/vcap" > Dockerfile && docker build -t something-scannable .

This should be easy to do in a container running under concourse. If we are going to try to tackle this, we should probably use the opportunity to do https://github.com/18F/cg-atlas/issues/172 at the sametime, and just incorporate this scanning process into the pipeline that adds them to our CF deployment.

[dlapiduz]

I think that would be better than nothing so if we set that up we would be better off.

[mogul]

We're leaving this one as a nice-to-have but not critical given that upstream maintainers are already looking at CVEs for buildpack updates. It's also much lower priority than scanning fully-provisioned containers that already have customer code in them; that's where the least-scanned, highest-value work could be done.