Replies: 2 comments
-
In ephemeral mode each job is run on its own runner which is then terminated when the job is complete. So each instance runs only a single job. This means that even if traces are left behind by a job they will be deleted when the job is complete. This is inherently more secure. It also means you don't need to worry so much about boundaries between jobs and making sure the runner can't be somehow tainted for the next job. So running docker in a restricted mode is no longer a primary concern as the security boundary is the entire instance, which is then deleted anyway. @npalm anything to add? |
Beta Was this translation helpful? Give feedback.
-
Agreeing with @ScottGuymer |
Beta Was this translation helpful? Give feedback.
-
Hello. We are considering a couple of options for ephemeral runner hosting, including Kubernetes and EC2 dedicated instances. Our concern with hosting ephemeral runner images in kubernetes pods is that docker requires privileged pods as well as root-level access. I was wondering if anyone here knows if running these ephemeral runners in EC2 reduces this vulnerability, for example, by allowing docker to not need to run as root, or if privileged pods are no longer required. Is the security impact radius reduced in any meaningful way by using a dedicated EC2 instance instead of kubernetes and EKS clusters? Thanks.
Beta Was this translation helpful? Give feedback.
All reactions