4 ms·

Self-hosted runners are brilliant, but have a poor security model for running containers or building them within a job. Whilst we're focusing on GitHub Actions

• goodoldneon 4y ago
  > poor security model for running containers or building them within a job You mean Docker-in-Docker? If so, we used Kaniko to build images without Docker-in-Docker
  • alexellisuk 4y ago
    There is a misconception that Kaniko means non-root, but in order to build a container it has to work with layers which requires root. Using Kaniko also doesn't solve for: How do you run containers within that build in order to test them? How do you run KinD/K3s within that build to validate the containers e2e?
    • goodoldneon 4y ago
      The benefit of Kaniko (relative to Docker-in-Docker) is that you don't need to run in privileged mode. We test our containers in our Dev environment after deploying
      • alexellisuk 4y ago
        That is a benefit over DIND and socket sharing, however it doesn't allow for running containers or K8s itself within a job. Any tooling that depends on running "docker" (the CLI) will also break or need adapting. This also comes to mind: "root in the container is root on the host" - https://suraj.io/post/root-in-container-root-on-host/ https://suraj.io/post/root-in-container-root-on-host/
        • mattbillenstein 4y ago
          This reminds me of the erlang map-reduce "did you just tell me to fuck myself" meme