DinD or actualy DinC in kuberneteis mode

[schipperkp]

What would you like added?

I need to allow dind when containerMode.type= kuberneteis.

We have. a non privlaged non root container that can run full docker in docker in kuberneties but when any action has a requirement of dind such as the link below it fails with the error noted below. This is not correct we have dind and do not need a special container mode that is different than kuberneties.

Error: Error: Building container actions is not currently supported

#3352.

Please add a seperate option enabling dind in any containermode....

Why is this needed?

dind is not linked to container mode but the ability of a team to support dind in the container they are running.

Additional context

exsample of dind in our container.

[github-actions]

Hello! Thank you for filing an issue.

The maintainers will triage your issue shortly.

In the meantime, please take a look at the troubleshooting guide for bug reports.

If this is a feature request, please review our contribution guidelines.

[schipperkp]

#3709

this is also an issue I can not do a workaround because it does not respect my dind values file

[schipperkp]

My repose to an internal ms(github) and company communications:

Andrew,

Thanks for your viewpoint it helps me understand some choices. There are some technical inaccuracies that I want to clear up in what you said and see if we can move the needle on this.

While kube does not support docker as the running container any more yes… that actually has nothing to do with a container that kube is running supporting docker commands inside of itself. For example we run k3s with containerd running a pod and running a fill docker sweat of commands in our container without root or privileged mode is secure and works end to end in our env. The industry uses DIND when the more accurate term is dinc (docker in containerd.

Kaniko for builds is ok but there is much that it does not support and many more tools you can use, but kaniko does benefit from not needing and host level changes. So, using kaniko you have to settle and using the other tools all require host level changes. This means you might as well do dinc correctly and securely and make the host level changes needed since all solution other then kaniko require host level changes. (new tools come all the time so this may not be 100% accurate on direct alternatives to kaniko…

Allowing DinC is not a security risk if it is done correctly and again 100% of the gha command using docker commands should be build or test commands so again the build and test systems are not public facing. If you can’t trust your own developer you got bigger issues. As I tell our security team our developers can do way more harm with the code they right then any access they may gain on the hosts their build container and the code on.

So back to this constraint… For arc to dictate where you can or can’t run a docker command seems to be asserting way way too much control on your users. Control you don’t have to invest coding and time in to support. If you simply have a flag “allowsDocker: true” in any spec, then it can be handled and left to the user and possible new ways to do this that may come up over time.

Again, as I said in my ticket we do this securely and without root or privileged access so your security points eludes to a misunderstand of the content of my ticket attached… 😊

Also.I would never do dind the way you’re even doing it. It is actually insecure and should be removed from your system… Also, I would let people overwrite it so we can do it more secure… There currently is no way to override that template in ARC when I try it just does your hard coded example. I would love to get rid of it disable it or be able to override it.

Hope this helps shed some light on the technical issues.

Thanks
Joshua

Githubs internal responce... to help the comunity

Hi Joshua,

Thanks for providing the information below.

Natively, Kubernetes no longer uses or supports Docker. Thus, no ability to call Docker out of the box. You'd have to build some support (like we did with DinD).

To do Docker builds, Kaniko is probably the best bet at the moment. It allows the images to be built in the restricted environment of Kubernetes pods. If you need Docker itself for the CLI or Dockerfile Actions, then DinD can be used. GitHub hosted runners could be used for that purpose as well.

Allowing DinD with Kubernetes mode could introduce security issues and that's why it's been designed this way.

Those are the constraints when using ARC; it's either DinD or Kubernetes mode, but not both. I'm happy to pass along some information on building images with Kubernetes mode if that seems to be the route that your security team would like to use.

Let me know if you have questions.

Best regards,
Andrew