Application Container Security Guide [pdf]
1–10 of 39 posts
Re: Application Container Security Guide [pdf]
#2In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years have been doing the heavy lifting in getting cgroup and namespace functionality working properly and securely - and without any of the glamorous publicity that Docker and CoreOS get. They use AppArmor extensively as an "application firewall for syscalls", which may sound ugly but is the most practical security solution I've seen in this space.
Re: Application Container Security Guide [pdf]
#3In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…
> They use AppArmor extensively as an "application firewall for syscalls", which may sound ugly but is the most practical security solution I've seen in this space.
Seems like a good use case for Capsicum[1]. Too bad Capsicum hasn't been merged into the Linux Kernel yet[2].
Re: Application Container Security Guide [pdf]
#4I like how there is an implied influence (e.g. dockerism) about containers being immutable/ephemeral... meanwhile I've been incredibly happy moving most of my VM deployments over to nspawn because many standards of systems management were anti-patterns in dockerland.
Re: Application Container Security Guide [pdf]
#5In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…
openshift will give you a small container for free.
So it looks like they've solved it -- with selinux, seccomp and judicious use of capabilities no doubt.
Re: Application Container Security Guide [pdf]
#6In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…
AppArmor is probably a good product.
Unfortunately, I've been left with a bad taste.
MySQL Ubuntu packages pull in AppArmor by default - BY DEFAULT - and include a profile that doesn't let you put your data dir anywhere except for one particular location. And it's virtually impossible to tell why MySQL can write to THAT LOCATION RIGHT THERE where is clearly has the appropriate permissions.
Re: Application Container Security Guide [pdf]
#7In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…
There are a few commercial container security products too - twistlock, aquasec, neuvector - for those who can't wait.
Re: Application Container Security Guide [pdf]
#8In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…
> They use AppArmor extensively as an "application firewall for syscalls", which may sound ugly but is the most practical security solution I've seen in this space. Seems like a good use case for Capsicum[1]. Too bad Capsicum hasn't been merged into the Linux Kernel yet[2]. [1]: https://www.freebsd.org/cgi/man.cgi?capsicum(4) [2]: http://capsicum-linux.org/
Sounds like a good use case for SELinux [0], too, which has already been merged -- roughly 15 years or so ago.
Re: Application Container Security Guide [pdf]
#9In my experience, multi-tenant Linux container security is still in its infancy due to Docker's unwillingness to build out container security models, the complexity of configuring namespace permissions in the kernel, and the lack of namespace awareness among key driver providers like NVIDIA. The most innovative work I've seen done in this space actually comes from the lxc/lxd group at Canonical, who for many years ha…
AppArmor is probably a good product. Unfortunately, I've been left with a bad taste. MySQL Ubuntu packages pull in AppArmor by default - BY DEFAULT - and include a profile that doesn't let you put your data dir anywhere except for one particular location. And it's virtually impossible to tell why MySQL can write to THAT LOCATION RIGHT THERE where is clearly has the appropriate permissions.
What prevents you from updating the profile?
Re: Application Container Security Guide [pdf]
#10I like how there is an implied influence (e.g. dockerism) about containers being immutable/ephemeral... meanwhile I've been incredibly happy moving most of my VM deployments over to nspawn because many standards of systems management were anti-patterns in dockerland.
Oh hey, another nspawn user. I've had really good luck using it for isolation purposes as well, and it's really handy for testing clean builds (arch-nspawn comes to mind, but it's also really useful for simulating installs without using a full VM).
I'm curious what extra tools, if any, you've used for nspawn (automation or otherwise). In my experience, it's been pretty easy to manage just with the default tools but it seems images can be a bit fiddly if you deviate too far from the host OS or anything without systemd--although I can't imagine that'd be useful outside experimentation or testing.