Securing and monitoring containers in enterprise environments
Did You Lock the Front Door?
You might have heard of Secure Computing Mode (known as seccomp), with which you enforce a limit on a process' abilities or on syscalls that are needed for a process to request a service from the kernel. The addition of these profiles is also possible in Kubernetes [5], currently the most popular container orchestration engine with an impressive 15-year production provenance from Google.
Creating a seccomp profile allows you to define every available syscall in a list, and after lots of testing at Google, you can take some comfort in the knowledge that the default profiles that enforce these tricky-to-fathom limits will help keep most applications available and not break anything horribly.
From a Docker perspective, a number of syscalls are run by default, but many are also switched off. At one point, their default profile blocked more than 50 syscalls with the promise that things would keep running as expected.
Want to Eat Your Cake Too?
In addition to fine-grained seccomp profiling, Docker cleverly integrates with the kernel's capabilities [6].
How to switch on only the permissions you require and not get bamboozled with the need to allow cap-add=all
, which opens the floodgates to the host on which a container runs, is definitely worth understanding. I find myself referring to Linux capabilities [7] continually these days.
Be warned, however, that even worse than opening up lots of kernel capabilities for your containers is the dreaded (and I've heard it called "lazy") privileged mode. With privileged containers, in addition to unleashing system capabilities with cap-all=all
, you lose all the limitations enforced by the device cgroups controller.
In terms of protecting your host from a container running in privileged mode, you might say that you're effectively leaving your front door swinging open in the wind, never mind forgetting to lock it.
As for the future of host security, it's common knowledge that Google has been working hard at spawning containers as the non-root user (and the Gnome project apparently has, too, from a desktop perspective). By all accounts, however, it's not a trivial undertaking. In case you are wondering, the popular Google Chrome browser sandboxes its Browser tabs in a not too dissimilar (and very clever) way that containers run. The surprising crossover between desktop and container spaces shows how important fine-grained kernel access for processes is.
The future is sharing VMs between distinct tenants (different customers) with fully assured safety and little fear of a compromise taking down your entire customer base at once. Kubernetes itself is not far from orchestrating containers within hypervisors for safety.
Freedom of Choice
One change that might have crept in under your radar, among those sometimes difficult-to-follow changes in the industry I mentioned earlier, is that Kubernetes has moved to allowing you to state your container runtime of choice.
Kubernetes reminds you that there's more than one way to launch a container – namely, using the cri=
switch (i.e., for the container run-time interface, CRI). The CRI means you are no longer tied to the Docker runtime but can choose other run-time engines, such as rkt
or the soon to be a la mode runtime that will comply with OCI standards (i.e., cri-o
).
Conveniently, the container network interface (CNI) improvements also integrate nicely with the chosen container runtime's networking in Kubernetes. The project's page can be seen on GitHub [8].
Although easy to miss, progress is well underway on other lesser known projects to bestow more run-time choice. You might have a look at the README files for rktlet
[9] and frakti
[10] on their respective GitHub sites.
I recommend having a quick read of both pages for some valuable insight into what you might be working with very soon. Each choice is sophisticated and ultimately could have different agendas.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.