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

61–65 of 65 posts

Re: Container security best practices: Ultimate guide

#61

Post by OrvalWintermute »

w7 wrote: post #55
OrvalWintermute wrote: post #50

Earlier quoted context omitted.

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,…

> Is there something more specific you wanted?

Yeah sure, what is your network infrastructure too? :)

Are all the containers Linux only, or other OSes too?

Re: Container security best practices: Ultimate guide

#62

Post by runamok »

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…

So if you are trying to troubleshoot something in a particular container how do you handle it? Attach a sidecar with various tools or...?

Re: Container security best practices: Ultimate guide

#63

Post by w7 »

runamok wrote: post #62
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…

So if you are trying to troubleshoot something in a particular container how do you handle it? Attach a sidecar with various tools or...?

Using a sidecar is also an option for debugging stuff involving shared storage, yes. The distroless project also ships aptly named "debug" containers that have BusyBox if you want a minimal shell for debugging something in the container filesystem itself. I've also made use of self-made "debug" containers with go-delve or the JVM in their respecting over-the-network debugging modes and a kubectl port forward, for anything written by me.

Re: Container security best practices: Ultimate guide

#64

Post by w7 »

OrvalWintermute wrote: post #61
w7 wrote: post #55

Earlier quoted context omitted.

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,…

> Is there something more specific you wanted? Yeah sure, what is your network infrastructure too? :) Are all the containers Linux only, or other OSes too?

Inside the cluster my containers are Linux only. I don't believe kata-containers supports Windows containers as I don't think rust-vmm, which is used by CloudHypervisor[0], or the kata internal execution agent support it.

If I wanted to run Windows in the cluster I'd probably have to look at KubeVirt[1]. KubeVirt is oriented towards getting traditional VM workloads (ones you'd run in QEMU, Hyper-V, etc) functioning in a Kubernetes environment. While kata-containers is oriented towards giving container runtime based workloads (images that run on docker, containerd, CRI-O) the protection of virtualization, with minimal friction.

Previously external to the cluster I had some Windows VMs hosted on QEMU/KVM + libvirt for experimentation with Linux and Active Directory integration, but they've since been deleted. The only remaining traditional VMs I have are 2 DNS servers and one OpenBSD server for serving up update images to my routers.

For network infra I have a number of VyOS[2] firewalls both at the edge and between VLANs, and Mikrotik devices for switching.

[0] https://github.com/cloud-hypervisor/cloud-hypervisor

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

[2] https://www.vyos.io

Re: Container security best practices: Ultimate guide

#65

Post by w7 »

w7 wrote: post #64
OrvalWintermute wrote: post #61

Earlier quoted context omitted.

> Is there something more specific you wanted? Yeah sure, what is your network infrastructure too? :) Are all the containers Linux only, or other OSes too?

Inside the cluster my containers are Linux only. I don't believe kata-containers supports Windows containers as I don't think rust-vmm, which is used by CloudHypervisor[0], or the kata internal execution agent support it. If I wanted to run Windows in the cluster I'd probably have to look at KubeVirt[1]. KubeVirt is oriented towards getting traditional VM workloads (ones you'd run in QEMU, Hyper-V, etc) functioning i…

Correction, CloudHypervisor supports Windows, but the kata agent does not.
Post reply on HN