dind
discovery-engine
dind | discovery-engine | |
---|---|---|
3 | 2 | |
2,307 | 28 | |
- | - | |
0.0 | 7.6 | |
almost 6 years ago | 7 months ago | |
Shell | Go | |
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.
dind
-
SELinux is unmanageable; just turn it off if it gets in your way
> ...anything that expects to be managing docker inside docker.
Now that's an interesting problem to have!
If you trust those tools and don't have untrusted users or untrusted code, you can sometimes just mount /var/run/docker.sock and use the VM/VPS/server's Docker directly. It is actually the approach that was used by excellent tools like Portainer, though it's also really risky as well.
Alternatively, you can try to just run Docker in Docker (DinD), which is a bit more tricky and the opinions there are split about whether to do it and when to do it: https://github.com/jpetazzo/dind
Of course, someone might also jump in and suggest that Docker is architecturally problematic (i don't care much, just want my containers to run, then again; i don't deal with untrusted code or any sort of multitenancy) and you should use Podman or another set of technologies, which is interesting advice but would necessitate other approaches.
In short, like with most technologies: Docker and OCI container in general get more messy as your requirements become more advanced. For the problems that they do solve easily (app packaging), they are pretty good, though!
- Docker in docker situation running into errors
-
Weird question: Is it possible to run docker inside of a docker instance?
Yes, that cal docker in docker, for do it you need share the master's partition, please check https://github.com/jpetazzo/dind
discovery-engine
-
SELinux is unmanageable; just turn it off if it gets in your way
KubeArmor (https://github.com/kubearmor) makes implementing SELinux policies easy for your host / k8s workloads.
Please do checkout the project and provide your valuable feedback.
All of our policies for SElinux are Auto generated using https://github.com/accuknox/discovery-engine
Writing policies by hand is nearly impossible, error prone and that is the exact problem we are trying to solve - to make SELinux and AppArmor easy for K8s workloads and now host based workloads.
-
KubeArmor adds support for SELinux
Auto Policy discovery for KubeArmor: https://github.com/accuknox/auto-policy-discovery
What are some alternatives?
sysbox - An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
refpolicy - SELinux Reference Policy v2
cascade - A high level language for SELinux policy
firejail - Linux namespaces and seccomp-bpf sandbox
cilium-cli - CLI to install, manage & troubleshoot Kubernetes clusters running Cilium
systemd - The systemd System and Service Manager
libdropprivs - Example code (will be library) for dropping privileges