Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Container security best practices: Ultimate guide

sysdig.com

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Container security best practices: Ultimate guide

#41

Post by ljm »

OrvalWintermute wrote: post #3

Unfortunately, this reads like a 100 foot marketing document for Sysdig, not actual container security best practices. If you want to look at actual container security best practices, check out CIS [1] & DISA [2], and NSA [3], with some theory at NIST [4], as well as the documentation from your preferred cloud vendors, be it AWS, Azure, GCP, or other, as well as the specific container security practices. [1] https://…

I guess Sysdig isn't a Y Combinator startup.

I read the entire article thinking it would be a shill, I saw little evidence that it was. In fact, I got to the end and I still don't know what the hell Sysdig is.

If anything, Sysdig fucking sucked at marketing this one, if it was supposed to be a puff piece for the product.

Re: Container security best practices: Ultimate guide

#42

Post by mac-chaffee »

eatonphil wrote: post #22

The thing that kills me about all of this is how hard it is to do it right. I wish there were a dumbed down version of containers and orchestrators for people trying to do basic multi-tenant compute in a SaaS and don't care a ton about the best performance. Would I be generally ok if I use gvisor to give a shell environment to customers and just keep the host up to date? Or is using containers just relatively pointle…

There's a set of benchmarks for multi-tenant kubernetes clusters that might prove useful (although they could use more depth): https://github.com/kubernetes-sigs/multi-tenancy/tree/master...

Re: Container security best practices: Ultimate guide

#44

Post by hsbauauvhabzb »

hsbauauvhabzb wrote: post #43

Calling your guide the ‘ultimate guide’ is disingenuous marketing. No single guide can cover all security concepts in all contexts. Every time I see that sorta wording I just assume the writer doesn’t actually know what they’re talking about

Continued: and given the writer seems to be all about tools the article fails to highlight that static (and automated dynamic) tools are limited in their ability to detect some classes of vulnerabilities and need to be backed with experience manual testing. This almost feels like it’s been written by a devops engineer who has a vague understanding about containerisation doesn’t have a clue about real and practical mechanisms to secure applications and services hosted inside containers.

I’m not saying the article is totally bad, but calling it an ‘Ultimate Guide’ makes the author a charlatan.

Re: Container security best practices: Ultimate guide

#45

Post by cpuguy83 »

nonameiguess wrote: post #36
eatonphil wrote: post #22

The thing that kills me about all of this is how hard it is to do it right. I wish there were a dumbed down version of containers and orchestrators for people trying to do basic multi-tenant compute in a SaaS and don't care a ton about the best performance. Would I be generally ok if I use gvisor to give a shell environment to customers and just keep the host up to date? Or is using containers just relatively pointle…

Multitenancy is difficult with containerization and not something I would recommend. It isn't what the technology is intended for. The ultimate example of multitenancy is actual platform and infrastructure providers and they all do it by giving you VMs because type I hypervisors are actually designed to do this kind of thing. Breakouts are always still possible when two processes are on the same physical server, but…

I'll be devil's advocate and say breakouts are totally possible with VM's, just by different vectors.

The vast majority of container breakouts are due to bugs in the control plane and not so much the kernel. The same is likely true for VMM's/hypervisors until those really started getting mature.

dotCloud and and Heroku are both examples of multi-tenant containers.

Re: Container security best practices: Ultimate guide

#46

Post by raesene9 »

cpuguy83 wrote: post #45
nonameiguess wrote: post #36

Earlier quoted context omitted.

Multitenancy is difficult with containerization and not something I would recommend. It isn't what the technology is intended for. The ultimate example of multitenancy is actual platform and infrastructure providers and they all do it by giving you VMs because type I hypervisors are actually designed to do this kind of thing. Breakouts are always still possible when two processes are on the same physical server, but…

I'll be devil's advocate and say breakouts are totally possible with VM's, just by different vectors. The vast majority of container breakouts are due to bugs in the control plane and not so much the kernel. The same is likely true for VMM's/hypervisors until those really started getting mature. dotCloud and and Heroku are both examples of multi-tenant containers.

That's very true, although I think there's a difference in attack surface size between the three isolation options (process based, sandbox based, hypervisor based).

I think the challenge for process isolation container based stacks (as I'm sure you know :) ) is that there's multiple components/groups involved in security and then there's co-ordination with the underlying Linux kernel as well, which makes things tricky, as Linux kernel devs will have potentially differing goals to the container people (e.g. the challenges about how to handle the interaction of new syscalls and seccomp filters)

If you compare that to something like gVisor, where there's essentially a single group responsible for creating/maintaining the sandbox, it's an easier task for them.

Re: Container security best practices: Ultimate guide

#47

Post by _8j50 »

Production host root fs should be mounted ro. Check out Linux IMA and how to only allow specific executables by hash. Centrally forward container logs. Use a VCS for container/workload templates and routinely audit for misconfig. Sysdig/falco and related tools are nice, but containers and their prod hosts are easier to harden

Re: Container security best practices: Ultimate guide

#48

Post by [deleted] »

dijit wrote: post #20
thinkharderdev wrote: post #17

Earlier quoted context omitted.

One of the hardest things to get any dev organization to start taking seriously is supply chain security. That first scan which lights up like a Christmas Tree is always such a daunting obstacle to get over. It's a shame because it is probably the highest value SDLC practice that many are not doing.

Yet, the base Debian image _does_ light up like a Christmas tree when you run a snyk scan. Mostly with incorrect issues (version number causes a flag but the fix is backported) or are considered low priority and thus WONTFIX by upstream. If you’re writing software against, say, dotnet3 (which has a docker image based on Debian) then you’re basically noised out.

[deleted]

Re: Container security best practices: Ultimate guide

#49

Post by OrvalWintermute »

moochmooch wrote: post #13
OrvalWintermute wrote: post #3

Unfortunately, this reads like a 100 foot marketing document for Sysdig, not actual container security best practices. If you want to look at actual container security best practices, check out CIS [1] & DISA [2], and NSA [3], with some theory at NIST [4], as well as the documentation from your preferred cloud vendors, be it AWS, Azure, GCP, or other, as well as the specific container security practices. [1] https://…

It's funny that you use the term "actual" to describe the guidance from the US government. They don't really know what they are talking about. Their release process for guidance takes so long that by the time it's release, it's out of date. This is absolutely true for k8s guidance. Last I checked, they were suggesting everyone use "Docker Enterprise" on their guidance long after it no longer existed (are vendors supp…

Sometimes they take a longer time to release a document officially in a final version, like NIST.

However, they regularly put out drafts and socialize them at an early stage.

Additionally, there is a huge amount of content that they produce that isn't widely disseminated outside of DoD/IC.

Re: Container security best practices: Ultimate guide

#50

Post by OrvalWintermute »

w7 wrote: post #39

My home k8s cluster is now "locked down" using micro-vms (kata-containers[0]), pod level firewalling (cilium[1]), permission-limited container users, mostly immutable environments, and distroless[2] base images (not even a shell is inside!). Given how quickly I rolled this out; the tools to enhance cluster environment security seem more accessible now than my previous research a few years ago. I know it's not exactly…

I read alot on home setups and yours seems to balance both high security and maintainability very well.

Care to share about the details of the security services side of your stack too?

Cheers

Post reply on HN