Detecting Security Vulnerabilities in Docker Container Images

Overview

Containers, especially Docker container images have been on fire of late and it is simple to understand why? Docker container images give your development and operations organizations a major shot of adrenaline. The results are quite impressive. Applications are developed at never before seen speeds and as such organizations are able to deliver innovation to customers much faster. It's all so easy, just get on Docker Hub, download a container and run it. So why isn't everyone already doing this? Unfortunately it is not quite that simple. Enterprises have many other requirements such as security. Once IT operations gets involved they typically start asking a lot of questions. Who built this container? How is the container maintained? Who provides support for the software within the container? Does the software running within the container adhere to our security guidelines? How can we run security compliance checks within containers? How do we update software within containers?

Red Hat has stepped up and decided that container security is an area where Red Hat can bring significant value. CloudForms 4 is a cloud management platform. In addition to supporting virtual machines platforms (RHEV, Hyper-V, VMware, OpenStack, Amazon EC2 and Azure) now also supports containers through OpenShift 3 and Atomic Enterprise. CloudForms 4 integrates either directly with OpenShift 3 (PaaS with CI/CD) or Atomic Enterprise (Container IaaS). In fact, CloudForms 4 should work with any container platform that implements Kubernetes by Google as that is basis for both.

OpenShift 3 provides additional value on top of Atomic Enterprise around development workflows (CI / CD) and integration with development tooling to build automated pipelines. If you are building applications OpenShift 3 is what you want, period. If you are running containerized Applications then either OpenShift 3 or Atomic Enterprise. As part of integrating with containers CloudForms 4 has a feature called smartstate analysis. Previously this worked only on virtual machines and allowed you to scan software content inside the virtual machine. You could then build security policies and automatically handle compliance events, such as shutting down non-compliant virtual machines. The smartstate analysis feature is now enabled through CloudForms 4, for container workloads. Let's see how it works! In this article we will show how to connect OpenShift 3 to CloudForms 4 through it's provider and perform smartstate anylysis for a MySQL Docker container image.

Connecting CloudForms 4 to OpenShift 3

As mentioned CloudForms has providers and now with CloudForms 4 there is a OpenShift 3 provider. In order to add the provider we must create a service account in OpenShift 3 and provide CloudForms with a service token from OpenShift.

Create JSON for CFME service account

[root@ose3-master ~]# vi cfme.json
{
 "apiVersion": "v1",
 "kind": "ServiceAccount",
 "metadata": {
 "name": "cfme"
 }
}

Ensure you are in the default project of OpenShift 3. Note: Projects in OpenShift map to Kubernetes namespaces.

[root@ose3-master ~]# oc new-project management-infra

Create the service account using JSON file.

[root@ose3-master ~]# oc create -f cfme.json

Give the server account cluster-admin role.

[root@ose3-master ~]# oadm policy add-cluster-role-to-user cluster-admin system:serviceaccount:management-infra:cfme

Get the token name from the service account.

[root@ose3-master ~]# oc get sa cfme -o yaml
 apiVersion: v1
 imagePullSecrets:
 - name: cfme-dockercfg-1z8sc
 kind: ServiceAccount
 metadata:
 creationTimestamp: 2015-11-26T12:53:46Z
 name: cfme
 namespace: default
 resourceVersion: "53311"
 selfLink: /api/v1/namespaces/default/serviceaccounts/cfme
 uid: bb38592b-943c-11e5-924e-525400bca113
 secrets:
 - name: cfme-token-9cxzf
 - name: cfme-dockercfg-1z8sc

Get the token itself for authentification.

[root@ose3-master ~]# oc describe secret cfme-token-9cxzf
Name: cfme-token-9cxzf
 Labels: <none>
 Annotations: kubernetes.io/service-account.name=cfme,kubernetes.io/service-account.uid=bb38592b-943c-11e5-924e-525400bca113
Type: kubernetes.io/service-account-token
Data
 ====
 token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImNmbWUtdG9rZW4tOWN4emYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiY2ZtZSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImJiMzg1OTJiLTk0M2MtMTFlNS05MjRlLTUyNTQwMGJjYTExMyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmNmbWUifQ.XH00iOfbXI2jOQNgLVt1jEXp5412bVoCZCqJQ-UR-9iWLJA2ha4E22uc0omq1tZ4xsJRpNaDJzB4g96xH_izQNAFTXWm5R7ESdrGvPBNaK_q6K2mh4C_sVKBCgqQYaq23Yhkan-7dchNCrX2mTPA8tZ7GpW7SRW7jRakhZhD5ljEthFbo8kWsYlreOeVidV3voV__o25425Yn4p6VHYZ5-eGAzieMI6IQvnynDvwZPEkxECX78oyx-8uap_IYCrg1kJUfGezXx05SHeYomOhBLMI7VMs6pHMhVTRGymRBi8aypWjPltzanR3NELKsHOdUx6PAFJ7YPGWkn753nEgHQ

Adding OpenShift 3 Provider

Once a service account for CloudForms has been created in OpenShift 3 we can add the provider.

In CloudForms 4 under Containers add a new provider.

Select OpenShift and copy/paste the token

After a few minutes you should see the container dashboard in CloudForms 4 populate with information. Note: we see Kubernetes constructs such as pods, replicators and services.

Add Security Context Constraints

Security context constraints allow OpenShift 3 administrators to control permissions on container pods. In order for CloudForms 4 to perform smartstate analysis on container images it needs super-privileged container access.

Create security context constraint YAML file. Ensure you add the cfme service account to list of users. Note: you need to allow privileged containers and host volume plugins as these are needed for smartstate analysis.

[root@ose3-master ~]# vi scc_cfme.yaml
 kind: SecurityContextConstraints
 apiVersion: v1
 metadata:
   name: scc-admin
 allowHostDirVolumePlugin: true
 allowPrivilegedContainer: true
 runAsUser:
   type: RunAsAny
 seLinuxContext:
   type: RunAsAny
 fsGroup:
   type: RunAsAny
 supplementalGroups:
   type: RunAsAny
 users:
 - system:serviceaccount:management-infra:cfme

Create security context constraint.

[root@ose3-master ~]# oc create -f scc_cfme.yaml

Run Smartstate Analysis

At this point everything is in place to run smartstate analysis and peer into individual Docker container images. In this case we will look into a MySQL container image.

In CloudForms 4 go to Container Images and find the desired container image.

Here we notice that the packages are 0. This means no smartstate analysis has run. To run smartstate analysis select the option under the configuration dropdown.

After smartstate analysis completes you will see the software packages installed within your container image.

By clicking on the packages you can see all the individual packages and most importantly their versions.

Container image software packages and versions are now known to CloudForms 4. In a future version of CloudForms 4 when active container management is introduced, you should be able to create security compliance policies and define actions in the event of a security violation. To learn more about creating compliance policies in CloudForms see this article that was previously published.

Summary

In this article we have seen how to enable smartstate analysis in CloudForms 4 in order to peer into container images. Container technology is without question revolutionizing the way we develop and run applications. The only thing standing in it's way has been security. This is a major step forward in the ability to ensure enterprise security compliance of container environments. Red Hat is focusing greatly on container security and enabling container technology in the enterprise. This is the start of much more to come so stay tuned, buckle up and enjoy the ride!

Happy Container Compliance with CloudForms 4 and OpenShift 3!

(c) 2015 Keith Tenzer