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.
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):
email@example.com~/Downloads/bluemix 14:51:16 $ kubectl get ns NAME STATUS AGE 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:
firstname.lastname@example.org~/Downloads/bluemix curl -k -u USER:PASS "https://localhost:8083/api/v1/defenders/daemonset.yaml?registry=my-registry&type=daemonsetKubernetesNode&consolecn=my-console.com&namespace=twistlock&orchestration=Kubernetes" > bx.yaml
I then upload that yaml directly to Bluemix again using my standard kubectl client I can use anywhere else:
email@example.com~/Downloads/bluemix 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:
firstname.lastname@example.org~/Downloads/bluemix 14:43:15 $ kubectl get pods -n twistlock NAME READY STATUS RESTARTS AGE twistlock-defender-ds-c1hb5 1/1 Running 0 29s
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:
email@example.com~/Downloads/bluemix 14:49:21 $ cat nginx.yaml apiVersion: v1 kind: ReplicationController metadata: name: nginx spec: replicas: 2 selector: app: nginx template: metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80
firstname.lastname@example.org~/Downloads/bluemix 14:49:55 $ kubectl create -f nginx.yaml replicationcontroller "nginx" created
email@example.com~/Downloads/bluemix 14:50:05 $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-1x5n4 1/1 Running 0 8s nginx-n3w2q 0/1 ContainerCreating 0 8s
firstname.lastname@example.org~/Downloads/bluemix 14:50:13 $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-1x5n4 1/1 Running 0 1m nginx-n3w2q 1/1 Running 0 1m
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.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.