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

51–60 of 65 posts

Re: Container security best practices: Ultimate guide

#51

Post by hsbauauvhabzb »

raesene9 wrote: post #18
danjc wrote: post #5

Curious to know whether anyone here can speak to how much safer Hyper V isolation[1] is than process isolation and whether it negates some of the concerns in the article. 1. https://docs.microsoft.com/en-us/virtualization/windowsconta...

Microsoft's guidance (last I looked) was that Windows containers (e.g. the non Hyper-V ones) were not a security boundary, only Hyper-V based Windows containers should be considered to provide isolation. That has the slight clash with the fact that Hyper-V containers are not currently supported under Kubernetes ( https://kubernetes.io/docs/setup/production-environment/wind... ):) For more depth on the challenges of s…

It just changes complexity. The difference between a container on bare metal where the target is an adjacent application (or container image), and a container inside a vm where the target is an adjacent application on the host (or inside a vm/vm+Container) the attack chain includes a container breakout and* a hypervisor breakout, which is harder to do, but probably not beyond highly sophisticated threat actors.

Re: Container security best practices: Ultimate guide

#52

Post by gunfighthacksaw »

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://…

Yet another (soon to be penultimate, etc) ultimate guide

Re: Container security best practices: Ultimate guide

#53

Post by dilyevsky »

jeffbee wrote: post #37
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.

They are actually even worse for latency sensitive workload because cfs with 100ms default period will cause crap tail latency (especially for multithreaded processes such as most go programs)

Re: Container security best practices: Ultimate guide

#54

Post by jeffbee »

dilyevsky wrote: post #53
jeffbee wrote: post #37

Earlier quoted context omitted.

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.

They are actually even worse for latency sensitive workload because cfs with 100ms default period will cause crap tail latency (especially for multithreaded processes such as most go programs)

Yes, but I put limits on LS workloads because I expect them to have a capacity plan, stick to it, and not abusively starve out batch workloads.

Re: Container security best practices: Ultimate guide

#55

Post by w7 »

OrvalWintermute wrote: post #50
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

Sure, hopefully I understand what you mean.

For network observability I'm using Cilium's Hubble, which I will soon figure out how to get into a greylog setup or something. For container image vulnerability interrogation I'm running Harbor with Trivy enabled, initial motivation was to have an effective pull through cache for multiple registries because I got rate limited by AWS ECR (due to a misconfigured CI pipeline, oops), but it ended up killing two birds with 1 stone.

Next on my list is writing an admission controller to modify supported registry targets to match my pull through cache configuration.

Is there something more specific you wanted?

Re: Container security best practices: Ultimate guide

#56

Post by dilyevsky »

jeffbee wrote: post #54
dilyevsky wrote: post #53

Earlier quoted context omitted.

They are actually even worse for latency sensitive workload because cfs with 100ms default period will cause crap tail latency (especially for multithreaded processes such as most go programs)

Yes, but I put limits on LS workloads because I expect them to have a capacity plan, stick to it, and not abusively starve out batch workloads.

I think this is backwards. How are you planning on “sticking to it” when you’re serving unpredictable user traffic? If requests are set appropriately everywhere then it won’t really starve batch as kernel would just scale everything to their respective cpu.shares when cpu is fully saturated. This would allow you to weather spiky load with minimum latency impact and minimize spend

Re: Container security best practices: Ultimate guide

#57

Post by gui77aume »

dilyevsky wrote: post #53
jeffbee wrote: post #37

Earlier quoted context omitted.

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.

They are actually even worse for latency sensitive workload because cfs with 100ms default period will cause crap tail latency (especially for multithreaded processes such as most go programs)

Interesting. It's my impression too. I understand that CPU limit will artificially throttle CPU, when not necessarily needed, wasting CPU cycles I could use. (Java programs in my case but I imagine it's comparable to Go ones)

Do you recommend to disable CPU limit? In the general case.

Re: Container security best practices: Ultimate guide

#58

Post by dilyevsky »

gui77aume wrote: post #57
dilyevsky wrote: post #53

Earlier quoted context omitted.

They are actually even worse for latency sensitive workload because cfs with 100ms default period will cause crap tail latency (especially for multithreaded processes such as most go programs)

Interesting. It's my impression too. I understand that CPU limit will artificially throttle CPU, when not necessarily needed, wasting CPU cycles I could use. (Java programs in my case but I imagine it's comparable to Go ones) Do you recommend to disable CPU limit? In the general case.

We don’t set them anywhere in prod and generally didn’t have any issues. We always set cpu requests and alert if those are exceeded for prolonged periods and always set memory req=limit

Re: Container security best practices: Ultimate guide

#59

Post by jeffbee »

dilyevsky wrote: post #56
jeffbee wrote: post #54

Earlier quoted context omitted.

Yes, but I put limits on LS workloads because I expect them to have a capacity plan, stick to it, and not abusively starve out batch workloads.

I think this is backwards. How are you planning on “sticking to it” when you’re serving unpredictable user traffic? If requests are set appropriately everywhere then it won’t really starve batch as kernel would just scale everything to their respective cpu.shares when cpu is fully saturated. This would allow you to weather spiky load with minimum latency impact and minimize spend

It's weird that apparently you are a borg user from google, according to other discussions we have exchanged, but you question the value of hard-capping for latency-sensitive processes.

Re: Container security best practices: Ultimate guide

#60

Post by dilyevsky »

jeffbee wrote: post #59
dilyevsky wrote: post #56

Earlier quoted context omitted.

I think this is backwards. How are you planning on “sticking to it” when you’re serving unpredictable user traffic? If requests are set appropriately everywhere then it won’t really starve batch as kernel would just scale everything to their respective cpu.shares when cpu is fully saturated. This would allow you to weather spiky load with minimum latency impact and minimize spend

It's weird that apparently you are a borg user from google, according to other discussions we have exchanged, but you question the value of hard-capping for latency-sensitive processes.

Borg sre even ;) (former) and yes i do question them. For one borg aint using 100ms cfs period and it wasn’t even standard cfs if i recall so yes i do question that outside of limited borg usecase
Post reply on HN