Aqua Security's blog covers container and cloud-native security, including malware campaigns, vulnerabilities, supply chain attacks and container history.
HN links it for security incident reports such as the Trivy supply chain attack; one commenter calls its content FUD.
(Same discussion as on lobste.rs)
Thank you for this link, I've only seen the initial CVE announcement.
> This is not FUD [...]
The site is practicing FUD, it accomplishes communicating a message in an untruthful fashion by mixing two different things into one. (Just check out their stack overflow links, it is not clear if they are talking about root or `--privileged`)
People are confused wether `docker root == host system root` and this site doesn't help them to get a better understanding whether or not it is the case. (It isn't) Plus it misses what its main goal should be, running a Secure Docker environment.
You are talking about a previous exploit, not a permanent issue. Keeping your host system up to date and additional hardenings is always going to be necessary in exposed environments.
> Use Docker containers with SELinux enabled (--selinux-enabled). This prevents processes inside the container from overwriting the host docker-runc binary.
Authors recommendation is also using SELinux, this also helped with outer Docker/Kernel related vulnerabilities in the past. Why isn't the page even mentioning this?
---
I think it is important to give a proper outlook on how problematic things are and not to confuse people with super high expectations. You often end up running containers that you have only little control about.
1. Avoiding root in self-built containers is definitively the way to go, since it reduces (unnecessary) attack surface, but
1. It requires some…
> Containers already existed
Fascinating. I'm admittedly very new to container-land, but my understanding was precisely the opposite - that Docker invented this concept and practice of building a runtime environment that can then be replicated and deployed to many hosts. Do you have any search terms or articles I should pursue to learn more about the predecessors?
I've read through this[0], but it mostly suggests that approaches prior to Docker provided isolation/jailing, which is an important part of containerization but neglects a lot of tooling around building, deploying, etc.
[0] https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016
EDIT: various other comments ("The Docker UX is what made the difference, not the underlying tech. Building containers in an easy incremental and reproducible way that could then be stored in a repo and pulled over HTTP was the evolution in packaging that was needed.", "I think the feature that won the hearts of devs was the incremental builds that let people fail quickly in a forgiving way", "Containers were painful as hell to set up and use; it was like using Git, but worse. Docker made it convenient, simple, and useful. By now everybody understands that immutable artifacts and simple configuration formats are extremely effective") seem to support this perception.
EDIT2: Thanks to all those that replied!
>individual teams can’t deploy their code without coordinating with every other team, which yields long user feedback loops and a bunch of other knock-on effects
Fine until one of the microservices needs an update with new features -> new API because Something Has Changed, and suddenly...
>the whole purpose of containers is to decouple the application from the platform.
Are containers not a de facto platform?
>Literally laughing out loud at the idea that marketing people are behind microservices.
Here's a moderately complete list of products. How many are pay-to-play?
https://www.aquasec.com/cloud-native-academy/container-platforms/container-platforms-6-best-practices-and-15-top-solutions/
All you're really doing with containers is creating a meta-monolith running on external hardware with custom automation - managed by an ever so handy third party software product. Also running on external hardware. All of which you're paying for.
You can also DIY and not pay. In theory. But really...?
This makes sense at global scale where you're drowning in income and need to handle all kinds of everything for $very_large_number customers.
It's complete madness for a small startup that doesn't even have a proven market yet.
It is unrealistic to fit Kubernetes Security Best Practices into a single blog post. Here are MANY other blog posts or other very similar content:
https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/
https://www.aquasec.com/wiki/display/containers/Kubernetes+Security+Best+Practices
https://dev.to/petermbenjamin/kubernetes-security-best-practices-hlk
https://techbeacon.com/hackers-guide-kubernetes-security
https://www.sumologic.com/blog/devops/kubernetes-security-best-practices/
https://news.ycombinator.com/item?id=16764743
https://speakerdeck.com/ianlewis/kubernetes-security-best-practices
https://dzone.com/articles/kubernetes-security-best-practices
and a quick search reveals a full length e-book about it:
https://info.aquasec.com/kubernetes-security-sem (https://kubernetes-security.info/)
https://cdn2.hubspot.net/hubfs/1665891/Assets/Kubernetes%20Security%20-%20Operating%20Kubernetes%20Clusters%20and%20Applications%20Safely.pdf?t=1538587424944&_hsenc=p2ANqtz-_7jbqtRATdJAm7eFxtd5u4nVLYuIlrF67z5qbslZ10-I63-RZ4ogqu9iuuEMsx7fskPYWww2jDpVjOvrLs
The original write-up is linked from this post https://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/ - Good, lots of details on exact reproduction.
One idea for mitigation before you can get a patch out for this would be to use admission control (e.g. OPA/Kyverno) to block setting custom sysctls altogether or blocking the characters used in the attack. There's some notes on that https://blog.aquasec.com/cve-2022-0811-cri-o-vulnerability and Kyverno have a mention of the finer grained policy https://twitter.com/kyverno/status/1504499323324678145
One thing that's worth noting is that to exploit this the attacker needs create pod rights (or rights to create a workload type that then creates pods), so it's probably not critical for every cluster.
They aren't all over the place, in fact they are far more advanced than whatever you're referring to. Containers on Linux have also existed for a long time:
https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016
The containerization solutions you're referring to didn't gain widespread adoption like Docker and Kubernetes because they weren't as polished and lacked features and functionality that is available today. Windows containers have a big image requirement, and most server-side software is already optimized for Linux so they aren't in high demand. Just take a look at Docker Hub and tell me how many Windows containers you find compared to Linux, especially the official images of the most common software.