gvisor
KubeArmor
gvisor | KubeArmor | |
---|---|---|
70 | 3 | |
15,645 | 1,468 | |
1.0% | 8.1% | |
9.9 | 9.3 | |
5 days ago | about 9 hours ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gvisor
-
Unfashionably secure: why we use isolated VMs
If you think about it virtualization is just a narrowing of the application-kernel interface. In a standard setting the application has a wide kernel interface available to it with dozens (ex. seccomp) to 100's of syscalls. A vulnerablility in any one of which could result in complete system compromise.
With virtualization the attack surface is narrowed to pretty much just the virtualization interface.
The problem with current virtualization (or more specifically, the VMM's) is that it can be cumbersome, for example memory management is a serious annoyance. The kernel is built to hog memory for cache and etc. but you don't want the guest to be doing that - since you want to overcommit memory as guests will rarely use 100% of what is given to them (especially when the guest is just a jailed singular application), workarounds such as free page reporting and drop_caches hacks exist.
I would expect eventually to see high performance custom kernels for a application jails - for example: gVisor[1] acts as a syscall interceptor (and can use KVM too!) and a custom kernel. Or a modified linux kernel with patched pain points for the guest.
[1] <https://gvisor.dev/>
- Syd the perhaps most sophisticated sandbox for Linux
-
Hacking Alibaba Cloud's Kubernetes Cluster
Hillai: Following our research, Alibaba took several steps to address the vulnerabilities we discovered. They limited image pull secret permissions to read-only access, preventing unauthorized uploads. Additionally, they implemented a secure container technology similar to Google's gVisor project. This technology hardens containers and makes them more difficult to escape from, adding another layer of security.
-
We Improved the Performance of a Userspace TCP Stack in Go by 5X
If you want to use netstack without Bazel, just use the go branch:
https://github.com/google/gvisor/tree/go
go get gvisor.dev/gvisor/pkg/tcpip@go
The go branch is auto generated with all of the generated code checked in.
- My VM is lighter (and safer) than your container
-
Maestro: A Linux-compatible kernel in Rust
Isn't gVisor kind of this as well?
"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."
https://github.com/google/gvisor
- Google/Gvisor: Application Kernel for Containers
- GVisor: OCI Runtime with Application Kernel
- How to Escape a Container
-
Faster Filesystem Access with Directfs
This sort of feels like seeing someone riding a bike and saying: why don’t they just get a car? The simple fact is that containers and VMs are quite different. Whether something uses VMX and friends or not is also a red herring, as gVisor also “rolls it own VMM” [1].
[1] https://github.com/google/gvisor/tree/master/pkg/sentry/plat...
KubeArmor
-
Implement DevSecOps to Secure your CI/CD pipeline
Falco is a cloud native Kubernetes threat detection tool. It can detect unexpected behavior, intrusions, and data theft in real time. In the backend, it uses Linux eBPF technology to trace your system and applications at runtime. For example, it can detect if someone tries to read a secret file inside a container, access a pod as a root user, etc, and trigger a webhook or send logs to the monitoring system. There are similar tools like Tetragon, KubeArmor, and Tracee which also provide Kubernetes runtime security.
- KubeArmor: Container-Aware Runtime Security Enforcement System Using LSM
-
The State of FOSS in India
We're building a KubeArmor - a container-aware runtime security enforcement system n using LSMs - between India, Korea and the US
https://github.com/accuknox/kubearmor
What are some alternatives?
firecracker - Secure and fast microVMs for serverless computing.
cilium - eBPF-based Networking, Security, and Observability
podman - Podman: A tool for managing OCI containers and pods.
datree - Prevent Kubernetes misconfigurations from reaching production (again 😤 )! From code to cloud, Datree provides an E2E policy enforcement solution to run automatic checks for rule violations. See our docs: https://hub.datree.io
wsl-vpnkit - Provides network connectivity to WSL 2 when blocked by VPN
eBPF-Guide - eBPF (extended Berkeley Packet Filter) Guide. Learn all about the eBPF Tools and Libraries for Security, Monitoring , and Networking.
kata-containers - Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/
tetragon - eBPF-based Security Observability and Runtime Enforcement
sysbox - An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
cronn - cron service with extras
containerd - An open and reliable container runtime
hubble - Hubble - Network, Service & Security Observability for Kubernetes using eBPF