Container Security
10 MINUTE EXERCISE
If you are looking to run containers in any kind of production capacity, simply knowing how to run a container is not enough. Ensuring that the container is secure is as critical as making sure any production facing infrastructure is secure.
Sometimes people can be lulled into a false sense of security around containers because of the sense that they are isolated from the host (e.g. VM). However, in the previous sections we made allowances to get our containers up and running, some of which we highlighted previously.
Exploiting a Vulnerable Container
In order to get a sense of how consequential these security exploits can be, the folowing video demonstrates how the Metasploit tool can hack into our container and even the host!
The Metasploit extension exercise offer you the ability to try this for yourself and how it can be fixed!
Scanning Containers for Security Issues
In this section we’ll look at one form of container security that actively look for vulnerabilities and ensure they are not part of our containers in the first place - scanning based on OSCAP. We’ll use our container (which clearly has security vulnerabilities) as a target of our OSCAP scan and let’s see what turns up!
|
We’re about to show a very fundamental approach to container scanning, but it is by no means the latest and greatest approach. However running through this section will give you the idea of what many of the tools in market are based on. |
Vulnerability Scanning with oscap-podman
The Open Security Content Automation Protocol (or OSCAP) refers to an open standard for quantifying vulnerabilities (or security policy infringements) that may be present in an operating system. The aggregated wisdom of all the Common Vulnerabilities and Exploits (CVEs) are codified in publicly available xml documents in the OVAL (Open Vulnerability and Assessment Language) xml format which oscap tooling can consume[1]
A podman tool, oscap-podman, is an oscap compatible scanner and adapts oscap for use with containers instead of just operating systems.
-
To save time, we have provided you with a suitable oval document already.
Let’s take a quick look at it (alternatively use CTRL+p (or CMD+p on MacOS) to quickly open
rhel-7.oval.xml)/usr/lib/code-server/bin/code-server -r /home/%USER%/container-workshop/oval/rhel-7.oval.xml
Figure 1. OVAL document
If you want to look at an oval document direct from the internet you can run the following command:
wget -O- https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 \ | bzip2 --decompress> ~%USER%/container-workshop/rhel-8.oval.xml -
With our oval document in hand, we simply run the scan on our image
sudo oscap-podman quay.io/bfarr/container-workshop-httpd:0.0.6 \(1) oval eval \(2) --report /home/%USER%/container-workshop/oval/vuln-report.html \(3) /home/%USER%/container-workshop/oval/rhel-7.oval.xml (4)1 The oscap-podman command must run as rootdue to the container evaluation itself needing elevated privileges. Hence we use thesudoprefix2 This indicates that we are wanting to evaluate the document using the ovalformat (as opposed to XCCDF)3 Indicates that we want the output as an (HTML) report in the specified directory 4 This is the location of the oval document we just viewed in VS Code In order for
oscap-podmanto be able to scan an image, it must already be present locally on the machine (for therootaccount) or you will get errors likeTarget of the scan not found: 'quay.io/bfarr/container-workshop-httpd:0.0.6'.If you get this error, first run this command before running the
oscap-podmancommand abovesudo podman pull quay.io/bfarr/container-workshop-httpd:0.0.6
-
The command might appear to do nothing for 30 seconds or so, but then you should see a flood of output somthing like this (showing only the last few lines):
... Definition oval:com.redhat.rhba:def:20150584: false Definition oval:com.redhat.rhba:def:20150441: false Definition oval:com.redhat.rhba:def:20150386: false Definition oval:com.redhat.rhba:def:20150364: false Evaluation done.
-
The report
vuln-report.htmlshould have appeared in yourcontainer-workshopdirectory of your explorer. To look at it from within the browser preview, right click on the file and selectOpen in Browser Preview
Figure 2. Open report in preview
-
On the right side of the screen, you should now see the generated report (as also seen in the image below). This report shows how our container fared against the different vulnerability checks and in our case indicates one big security issue.
You can double-click on the browser preview tab to expand that pane. Double-click again to bring it back to the original size
-
Let’s go a little deeper into the vulnerability that this oval scan uncovered. Included in the scan output is helpful information about what the vulnerability is, how it’s exploited, and how it can be resolved. Click on this CVE-2014-6271 or the link shown in the image below to learn more.
Figure 3. OSCAP Vulnerability Report
Your
Browser Previewshould navigate to Red Hat’s CVE information on the exploit which, in this case, is the famous Shellshock vulnerability that we have been expoiting on our container for most of this lab.
-
Feel free to read through the advisory. To determine how to fix the issue we’re going to follow link as in the Security Bulletin below.
Figure 4. Red Hat advisory on Shellshock CVE
-
Once on the security bulletin, select the "Resolve" tab as shown below. From this we can see that the recommended remediation is to update the version of bash that is running in our container to
bash-4.2.45-.el7_0.4
Figure 5. Security Bulletin with Shellshock remediation
-
Now that we know what we need to do to our container, we’re left with the question of HOW we’re meant to update the container given that containers are supposed to be immutable.
When dealing with containers, we don’t need to change the running container, but rather the image that the container runs as. In our case we’re going to want to update our
quay.io/bfarr/container-workshop-httpd:0.0.6image.This is where
buildahcomes in, which we’ll explore next.