Below you will find some insights in the container security. But also I added some information on what has been happening with the IT / Cloud ⛅️ in the Silicon Valley.
What is happening in the Silicon Valley and the cloud industry?
IBM caught everybody by surprise and started the formal process to acquire Red Hat on Sunday, October 28th. The landscape of hybrid clouds changed and got IBM to potentially #1 of hybrid cloud 🌁 providers.
During the same weekend of the IBM announcement I was attending with my 12 year old son the TwitchCon in San Jose. My son is in a middle school, and as all middle schoolers he plays Fortnite, as well as he v-blogs a lot. And he said that he is going to use Twitch more than Youtube, now.
By the way — it was his idea to attend the TwitchCon. In fact we had a great time — finding all those cosplaying fans, and youtubers/twitchers (@EhBeeFamily and @Sceptic) in the #nerf battlefield. We watched the skirmish of well known Fortnite twitchers doing amazing stuff with their avatars in duels against others. It was fun to watch. Older gamers were watching Call of Duty game of Ninja.
On Monday, October 29th IBM’s Bob Lord announced the winners of $200k prize for the disaster relief apps for Call for Code competition in San Francisco. And last weeks were all around Oracle Code One, Kafka Summit, Twilio Signal, Silicon Valley Code Camp. And finally on Friday, November 2nd the CalHacks 5.0 started at UC Berkeley. That was a great 3 day event that gathered more than 2,000 participants!
So you are interested in securing a container based system. This blog post is for you. You will learn about some of the technics to improve the architecture, design and practicies of the containerized application.
VMs vs Containers
First one needs to understand the difference between using a container vs Virtual Machine (VM). Basically when you use the Virtual Machine there is a necessity to run entire Operating System (OS) in order to get your application operational. VMs typically will have potential security surface areas of attack, like open ports (or starting sshd). What it means you need to take care of all the OS vulnerabilities first, close all unnecessarily opened ports before you expose a VM based application to the users (in Internet and Intranet alike). In addition you need to start to limit availability of standard applications that you do not need in OS like sshd to decrease the surface of the potential attack. Furthermore going forward you need to update the OS with the latest security and functionality fixes.
When using containers you might slim down the operating system to only the files, libraries, daemons, and parts of the system that you are going to use in your application. This limits amount of the exposures of your system in comparison with VM to support your application. In some of the cases it might be possible to start from the scratch image (an empty — no OS — image), and add the libraries that are necessary for your executable.
One more good practice is not to run your services as ‘root’, and avoid privileged mode just in case there is a security hole. You might want to put limits on the resources that can be used by the container — to try to prevent noisy neighbor effects.
https://docs.docker.com/develop/develop-images/dockerfile_best-practices
Also adding a secret to the cluster — the file including passwords to your system — for sensitive info ( like API keys, tokens, usernames and passwords) rather than in env vars (environment variables).
The example of the secret file from jpetstore demo:
kubectl create secret generic mms-secret --from-file=mms-secrets=./mms-secrets.jsonWhile the mms-secrets.json file holds the API keys, tokens, and user numbers:
mms-secrets.json file:
{
"jpetstoreurl": "http://jpetstore.<Ingress Subdomain>",
"watson":
{
"url": "https://gateway.watsonplatform.net/visual-recognition/api",
"note": "It may take up to 5 minutes for this key to become active",
"api_key": "123123123123123123"},
"twilio":
{
"sid": "",
"token": "",
"number": "+1XXXXXXXXXX"
}
}
}Finally the best practice suggests implementing the repeatable CI/CD pipeline that includes fixes, security patches, the use of capabilities, and use secrets for sensitive information. And thanks to CI/CD pipeline all the fixes, security patches will be applied when they need to be quickly and easily, and not as one-offs/hacks. The above mentioned jPetStore Modernization Demo example implements such a toolchain.
Scanning and Signing of the container images
When you build your own image repository you should start from performing overall vulnerability scans of your container images. There are automated mechanisms implemented in the enterprise grade repositories — like the one that is based in the IBM Cloud.
IBM Cloud repository provides the image scan feature. Please find below all the vulnerabilities detected with some suggested resolutions:
When you dealt with all the issues you could sign your images for containerized applications you are going to use — read more here: https://console.bluemix.net/docs/services/Registry/registry_trusted_content.html
And then you can enforce the policy to use only signed images from the enterprise registry: https://console.bluemix.net/docs/services/Registry/registry_security_enforce.html#security_enforce — see the example of the policy with the enforced signed images (at the time of this blogpost the functionality is in the BETA):
apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1
kind: ClusterImagePolicy
metadata:
name: ibmcloud-default-cluster-image-policy
spec:
repositories:
# This enforces that all images deployed to this cluster pass trust and VA
# To override, set an ImagePolicy for a specific Kubernetes namespace or modify this policy
- name: "*"
policy:
trust:
enabled: true
va:
enabled: trueContainer Security in the Runtime
Yet another aspect of the security is the container security in the runtime. This type of the monitoring and securing containers that are already in production. One of the known systems doing exactly this task is the monitoring system designed by NeuVector — check: neuvector.com — and see the complex view on the system below:
The subject of the container security is a vast field, and each section is only a tip of an iceberg. I will try to uncover those concepts that I barely scratched here and the new ones in the follow-up posts. If you want to hear more — please clap for it! Thank you for reading this.
Please follow me on Twitter — blumareks
