BSI IT-Security guidelines for Containers
BSI, the German „Federal office for Information Security“, releases IT security information and assistance on all aspects of IT security for many years.
BSI is currently modernizing the „IT-Grundschutz“ (IT cyber security shapes).
One of those modules is related to container security. This document is currently in the status „Community draft“
– this draft was released in May 2018.
This is a rather new operation field for BSI too. Docker & co. already exist since years – but security related topics were of rather low interest or not in the focus! It is just that easy and handy to start a container – security means effort, time and money.
This has changed a lot since many companies use containers in production.
If you deal with containers, you might know those guidelines already… I think it is a good starting point on what to look for!
BSI ranks the following vulnerabilities and threads as potentially dangerous for containers
Vulnerabilities in images
If you use images from any public repo, identifying vulnerabilities without a separate tool is a challenge. You might skip this step and use an image with a very old os version or any other software.
IBM Cloud private offers a „Vulnerability advisor“ that is capable to scan images for vulnerabilities before they are deployed into any system.
So either use such a tool or only use verified images from repos you trust.
Administrative access without control
Containers should not be accessible using ssh / ftp! As many images use standard operating systems, ssh access might be enabled – so take care of this!
Tool based orchestration
Let`s think of Kubernetes as orchestration engine … this might also contain vulnerabilities. Furthermore, admin access to Kubernetes is a problem as you can delete / destroy and manipulate your complete container ecosystem
Persistency of data
You know that containers should not contain „moveable“ data. You should take care that e.g. also logs are stored on a persistent volume so that you do not loose data after deleting / recreating a container.
User data must be persistently stored outside the container!
For sure you need to take care not to use username:password as plaintext is any script that is executed while the container is created
Then BSI documented specific requirements for the operation of containers (Here are just a few of them)…
Separation of container environment
BSI gives three models how to separate the container environment
Usage of secure images
You have to ensure that your images come from either a repo that you can trust or your own repo where all your images are scanned by an vulnerability advisor.
Identity management of admins
You should use your personal account when using the container system
One service per container
Each container should only run one service! As this is also the methodology of micro services, this should be no problem as long as you carefully planned your app modernization journey.
Limitation of resources per container
CPU, RAM and network should be limited for each container on the host.
And some more…
As I already wrote, I assume (at least I hope) that anyone who thought about running containers in production already thought about those items…
I think this is a great starting point and a summary of a very important topic that was not taken too serious within the last years as the container technology was too new and fancy.
In my opinion it is still a rather long way into high security standards for containers… but many people wrack their brain about how to make containers more secure.
One very interesting topic is IBMs Nabla
container platform launch where containers kernel usage is better isolated. Nabla limits the amount of interactions with other containers or the host.
There is a lot happening regarding container security and the released guidelines of BSI are already a milestone if you compare this with the status two or three years ago.