June 10, 2016 | Written by: CANTURK ISCI
Categorized: Compute Services | What's New
Share this post:
As of May 23rd IBM Bluemix Container Service now provides a native Kubernetes operations experience while removing the burden of maintaining master nodes. Kubernetes itself is based on the Docker engine for managing software images and instantiating containers. Get the details.
We introduced the Vulnerability Advisor (VA) service for IBM® Bluemix Containers around DockerCon 2015, and this first version of our service has been running in production since then, continuously scanning thousands of images and reporting to our users on vulnerability and compliance issues. Since our initial launch, we have continued to add several major new capabilities for VA spanning both new back-end analytics on images (such as additional compliance checks, configuration analysis, and password strength checks) and front-end capabilities under a new “Policy Manager,” which gives the users of IBM Containers the ability to impose admission control policies on their containers, before they become live.
Some of these new capabilities are direct results of feedback from our users, around the desire for deeper visibility into their environments and better fine-grain control. Thank you for all your great feedback, and please keep it coming.
A quick introduction to Vulnerability Advisor
This post presents a quick tour of VA, its key current capabilities, and some basic examples of how we make use of VA and its key features. VA is available in all geographies supported by Bluemix. We use Bluemix London and Dallas for the examples here. However, your experience should be the same regardless of geography. You can look at the VA for your images presentation from InterConnect 2016 for more information.
VA image status in Bluemix
We start our introduction by logging into Bluemix. We use the Bluemix service in London and the classic Bluemix interface for this demo. In a future post, we will show the same steps with the shiny new Bluemix interface. If you have a Bluemix account, log in. If not, sign up for your free trial to get started.
Once you are logged into Bluemix, click Catalog. This is where you first meet with VA. In the catalog, find the Container Images section. Here, you see several IBM provided default images. If you have also pushed images to the Container Service Registry, you see those images here as well. Now, hover your mouse over the images: An information window opens showing the deployment status of the images, which is basically a call to VA under the covers to get the current status of an image.
The status can be one of three categories:
- Safe to Deploy
- Deploy with Caution
- Deployment Blocked
Go to Create View
Now, let’s actually try to deploy these containers by creating container instances from these images and see what happens. Just to make things interesting, we try the one that has the Deployment Blocked status. Clicking on the image gets us to the deployment view. Here, there is more information about this image. Note that the CREATE button is disabled (in other words, deployment is blocked). There are three options:
- View the vulnerability report for this image
- Manage your org’s policies
- Authorize an override for this deployment
The first option in the deployment view is available to everyone, which tells the vulnerability and policy violation status of the image. The second and third options are available to org managers only, so they can relax and tighten policies for their images based on their requirements.
Explore status details
Let’s explore each of these options, in the order they are given. First, VA tells you all the discovered vulnerabilities and policy issues about your image. You can also go to related security notices to understand root causes and mitigation actions.
Browse Policy Manager
Second, your org policies give you the ability to see and possibly manage your policies in a view we call Policy Manager. Next to this view, there is also the Deployment Impact view, which tells how your existing images are impacted by the selected policies. Only org managers can alter policies. In our current settings, there is only one image that is blocked, while several are in the Deploy with Caution state.
Change org policies and observe impact
Now, for some more fun, let’s also see if we can change our policies and see their impact. For this, let’s take a restricted view against vulnerabilities and block images with vulnerabilities from deployment. Once we save it, the impact sidecar gets busy recomputing everything, and now we have several more images in blocked state.
Third, let’s look at what happens when we try the override option. In this case, we have a one-time, temporary override to deploy the image. Once we click it, the view for the image changes to Deploy with Caution and the CREATE button is now active. We can happily create our “risky” container from this image.
Still, let’s stop here and not deploy it, because VA told us our container has weak passwords and remote, password-based access enabled. Let’s hold on for a bit to understand why this is the case and try to fix our image.
Discover images with weak passwords
Going back to our initial Policy Manager results above (Step 5), the only policy that resulted in a deployment block was “Image has remote logins enabled, and some users have easily guessed passwords” and yuji-fff was the only image blocked with this policy. To validate yuji-fff image violates this policy, so we can revisit Step 4 where we explored status details for vulnerabilities and audit violations. The second tab clearly validates our expectation in the last reported violation: “Password should be strong.”
Update images in local development environment to address policy violation
Now that we have identified our offending image and the root cause of its violation, the next natural question is “How can we fix it?” For this part, we go back to our local Docker development environment, and improve our image security. There are multiple actions that we can take for this goal:
- (Definitely) provide a strong password
- Disable password based remote authentication
- Disable remote access altogether
For our image, we have simply rebuilt the image and provided a stronger password with chpasswd as one of the build steps. Then, we pushed the new image to the Bluemix Registry again, which under the covers, triggers a new VA scan. The results of this new scan:
As we see in the scan results, the number of violations went down from 6 to 5. The weak password violation is fixed, and we can now deploy our container without an easily compromisable password.
This ends our quick introduction to VA with some of its core functions and use cases. We addressed only one of our image violations. However, a better strategy is to address all of the three actions mentioned above, as well as the remaining vulnerability violations. I hope this serves as a useful starter to understanding and leveraging VA capabilities in Bluemix. We are currently working on making this analysis by VA more comprehensive, actionable, and easier to consume. Stay tuned for some of our upcoming new features and send us your feedback with any questions, comments, concerns, and requests for new capabilities.