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

31–40 of 65 posts

Re: Container security best practices: Ultimate guide

#31

Post by paxys »

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…

I think "dumbed down" and "multi-tenant compute" aren't compatible. No company needs to do multi-tenant compute by default. If you do, you are in the cloud hosting/infrastructure business (whether you like it or not) and should be expected to have the knowledge necessary to run such an operation.

Re: Container security best practices: Ultimate guide

#32

Post by blowski »

y4mi wrote: post #27
blowski wrote: post #25

Earlier quoted context omitted.

Yeah. Typical dev hyperbole. In a similar vein, a fairly mid-level dev was recently trying to convince me that "Rob Pike is a clueless idiot who knows nothing about language design".

I somehow think that their opinion was a little more nuanced then that. And fwiw, Rob Pike definitely did make mistakes. Golang is a great language, but it's not perfect.

It really wasn’t more nuanced than that - I’m pretty much quoting verbatim. The argument stemmed from the lack of generics in Go, which apparently was a sign of incompetence.

My general point is that there a lot of people who see the world in binary - genius or idiot, perfect or incompetent.

Re: Container security best practices: Ultimate guide

#33

Post by gui77aume »

I'm always a bit confused about the CPU limit (for the pod), some guides (and tools) advice to always set one, but this one [0] doesn't. Ops people I worked with almost always want to lower that limit and I have to insist for raising it (no way they disable it). Is there an ultimate best practice for that?

[0] https://learnk8s.io/production-best-practices

Re: Container security best practices: Ultimate guide

#34

Post by eatonphil »

paxys wrote: post #31
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…

I think "dumbed down" and "multi-tenant compute" aren't compatible. No company needs to do multi-tenant compute by default. If you do, you are in the cloud hosting/infrastructure business (whether you like it or not) and should be expected to have the knowledge necessary to run such an operation.

While that's a common sentiment in some topics in tech; I think the general intent, if not actual result, of progress in tech is to make things faster, more secure and easier.

So forgive me for asking. :)

Re: Container security best practices: Ultimate guide

#35

Post by moochmooch »

ziddoap wrote: post #14
moochmooch wrote: post #13

Earlier quoted context omitted.

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…

I always have to laugh a little bit when someone says NIST, NSA, etc. just "don't really know what they are talking about". They aren't perfect (you know, being humans and all), and can sometimes be slow in disseminating information to the public, but you're out to lunch if you think they "don't really know" anything.

I'm scoping my statement to container security & orchestration best practices, not their competency as a whole. I know the specifics of their guidance due to the industry I work in, so I feel comfortable speaking generally about specific guidance in regards to specific technology.

Your comments reads overly defensive to me.

Re: Container security best practices: Ultimate guide

#36

Post by nonameiguess »

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 it's never as trivial as figuring out how to mount the kernel virtual filesystems.

I say this as a Kubernetes consultant. If you want "multitenancy" in the sense of distinct product or application teams all employed by the same parent company or organization, it's fine. But if you're talking truly different organizations with no implied trust between them, don't put them on a shared cluster.

I'm kind of curious how Github does this, because you can still get very minimalistic with VMs. Make the startup script for your application something that also mounts the filesystems it needs and name it /sbin/init and you just made yourself a poor man's unikernel.

Re: Container security best practices: Ultimate guide

#37

Post by jeffbee »

gui77aume wrote: post #33

I'm always a bit confused about the CPU limit (for the pod), some guides (and tools) advice to always set one, but this one [0] doesn't. Ops people I worked with almost always want to lower that limit and I have to insist for raising it (no way they disable it). Is there an ultimate best practice for that? [0] https://learnk8s.io/production-best-practices

CPU limits are harmful if they strand resources that could have been applied. I usually skip them for batch deployments, use them for latency-sensitive services. Doesn’t seem like a security topic though.

Re: Container security best practices: Ultimate guide

#38

Post by ziddoap »

moochmooch wrote: post #35
ziddoap wrote: post #14

Earlier quoted context omitted.

I always have to laugh a little bit when someone says NIST, NSA, etc. just "don't really know what they are talking about". They aren't perfect (you know, being humans and all), and can sometimes be slow in disseminating information to the public, but you're out to lunch if you think they "don't really know" anything.

I'm scoping my statement to container security & orchestration best practices, not their competency as a whole. I know the specifics of their guidance due to the industry I work in, so I feel comfortable speaking generally about specific guidance in regards to specific technology. Your comments reads overly defensive to me.

>I'm scoping my statement to container security & orchestration best practices, not their competency as a whole.

vs.

>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.

Perhaps you can understand why I thought you were speaking generally, when your comment is written generally. I can't read minds to figure out what your silently scoping your comment to.

But if saying I laughed and why I laughed is overly defensive, my apologies. I'm not sure how else I would tell someone I find their comment funny.

Re: Container security best practices: Ultimate guide

#39

Post by w7 »

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 a production setup, but I really do feel that it's atleast the most secure runtime environment I've ever had accessible at home. Probably more so than my desktops, which you could argue undermines most of my effort, but I like to think I'm pretty careful.

In the beginning I was very skeptical, but being able to just build a docker/OCI image and then manage its relationships with other services with "one pane of glass" that I can commit to git is so much simpler to me than my previous workflows. My previous setup involved messing with a bunch of tools like packer, cloud-init, terraform, ansible, libvirt, whatever firewall frontend was on the OS, and occasionally sshing in for anything not covered. And now I can feel even more comfortable than when I was running a traditional VM+VLAN per exposed service.

[0] https://github.com/kata-containers/kata-containers

[1] https://github.com/cilium/cilium

[2] https://github.com/GoogleContainerTools/distroless

Re: Container security best practices: Ultimate guide

#40

Post by ziddoap »

0xbadcafebee wrote: post #23
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://…

Even if it is a marketing document, it's still got incredibly valuable information. Almost nobody is going to read a government specification, but they will probably read this page.

>Almost nobody is going to read a government specification

Why is that?

Every company I have worked security in, including where I am at now, regularly reads government guidance. Especially NIST guidance, which is referenced all over the world.

Post reply on HN