One of the guiding principles at Twistlock has been meeting customers wherever they already are. As containers become the predominant way to build, ship, and run apps, we want to make sure customers can secure their apps across every cloud they run in. We recently worked with IBM to demonstrate how Twistlock can protect apps running on the IBM Bluemix Container Service and this blog gives an overview of how it works.

IBM Bluemix is a leading cloud Platform as a Service offering that encompasses many PaaS capabilities. Recently, IBM added a managed Kubernetes offering to Bluemix that enables customers to deploy and run apps with no need to configure VMs or even Kubernetes itself. Instead, the Bluemix offering provides the ability to create and manage clusters using the Bluemix CLI and the kubectl tool you’re already familiar with. Bluemix focuses on security and ease of use and really abstracts away a lot of complexity of dealing with building, running, and securing your clusters. In fact, Bluemix Container Service nodes don’t even provide SSH access; all interactions must be through well defined paths like kubectl. This provides a strong degree of consistency and operational discipline in the way apps are built and deployed.

Recall that the architecture of Twistlock uses a lightweight, fully containerized security agent (which we call Defender) to protect each node in the cluster. To make it easy to scale out security to all your nodes, we long ago added the ability to deploy Defender via Kubernetes Daemon Sets. A Daemon Set is basically a special kind of Kubernetes deployment that ensures that every node in a cluster runs a specific pod. This is especially useful for security tools like Twistlock; we’ve seen customers deploy Defenders to every node in a 400 node cluster in literally just a few minutes. Because IBM Bluemix Container Service really stresses standards and compatibility with existing tools, it was easy to get Twistlock running on it.

The first step I followed was to create my cluster using the Bluemix UI (I could have also done so via the Bluemix CLI as well):

Once my cluster was created, I validated that I could access it and enumerate the namespaces running on it (notice this is with the native kubectl I already had on my machine):

14:51:16 $ kubectl get ns
default Active 5h
ibm-system Active 5h
kube-system Active 5h

Next, I went to a Twistlock Console I already had running in another lab environment. I could have installed Console directly into Bluemix as well of course, but this is a nice illustration of how open and portable this combination of Docker, Kubernetes, Bluemix, and Twistlock really is. I have a Console running in one cloud provider, protecting containers and apps in another provider, with no real effort required to do so.

In most cases, I can simply fill in some fields in the Twistlock UI and we’ll generate a script that pushes the Defender image to your registry, creates the Daemon Set configuration yaml, and loads it into your cluster. However, recall that Bluemix is secure by default and doesn’t provide even SSH access to cluster nodes. So, I needed to pull the yaml from the Twistlock API:

curl -k -u USER:PASS "https://localhost:8083/api/v1/defenders/daemonset.yaml?registry=my-registry&type=daemonsetKubernetesNode&" > bx.yaml

I then upload that yaml directly to Bluemix again using my standard kubectl client I can use anywhere else:

14:42:47 $ kubectl create -f bx.yaml
secret "twistlock-secrets" created
serviceaccount "twistlock-service" created
daemonset "twistlock-defender-ds" created

Once the Daemon Set is created, Bluemix Container Service automatically ensures Defender is deployed to each node in the cluster. In this case, my cluster has only 1 node, which I can see is already running Defender:

14:43:15 $ kubectl get pods -n twistlock
twistlock-defender-ds-c1hb5 1/1 Running 0 29s

Within Twistlock, you can see the newly running Defender deployed in Bluemix:

Of course, once the Defender is running, it’s automatically learning about the environment and applying the security policies you’ve defined. To illustrate this, I deployed a simple nginx app on Bluemix:

14:49:21 $ cat nginx.yaml
apiVersion: v1
kind: ReplicationController
name: nginx
replicas: 2
app: nginx
name: nginx
app: nginx
- name: nginx
image: nginx
- containerPort: 80

14:49:55 $ kubectl create -f nginx.yaml
replicationcontroller "nginx" created

14:50:05 $ kubectl get pods
nginx-1x5n4 1/1 Running 0 8s
nginx-n3w2q 0/1 ContainerCreating 0 8s

14:50:13 $ kubectl get pods
nginx-1x5n4 1/1 Running 0 1m
nginx-n3w2q 1/1 Running 0 1m

As soon as the deployment is complete, Twistlock’s machine learning begins building the runtime model for the image and detecting and preventing vulnerabilities:

In summary, this was a brief blog post for a very good reason: IBM Bluemix is a real Kubernetes as a service and it behaves exactly as we’d expect it to. We didn’t have to run any special tools or figure out any creative hacks to deploy Twistlock on it. Instead, we were able to use existing capabilities in Kubernetes itself to automatically deploy Defenders to every node in the environment and allow the rest of Twistlock’s security intelligence to model and protect the environment as we would any other. The benefit of Twistlock and Bluemix together is that Bluemix helps you focus on your apps by providing a secure, well managed Kubernetes service to run them that Twistlock can autonomously deploy on to protect them.

Get started with Twistlock now!
Try the IBM Bluemix Container Service for free today!.

← Back to All Posts Next Post →