I know everyone always says don't run as ROOT. But what if you are using a database system that has to run as root. It's easy to say "dont do this" but in a situation like this, how do you protect all othe containers/pods from this "crazy" pod that runs processes as root.
I have started the article by explicitly stating that this has a security issue. and for more context, I have done this as a quick fix, specifically for Jenkins that was running in a docker container. And if Jenkins job builds and pushes a Docker image, it will need the docker commands. So mounting the docker process into the Jenkins container was a work around I found for this case.
You are more than welcome to suggest SPECIFIC alternative solutions, instead of generally stating it's a bad solution, which I myself already mentioned in the article. Thanks.
For other readers: running a container with root privileges is a DEFINITELY NO.
I kind of get you. The reason of why others are pointing this is a super bad practice/anti-pattern is because your post title is "Run Kubernetes Pod with root privileges" (tagged with #tutorial and with a very elaborated and motivational image), that title is more a How-To guide than an advice request. So yes, is important to point this is a bad practice before other more inexperienced devs/devops read it.
You could change your post's purpose asking for recommendations in how to fix your permissions issues, tag it with #help and you will see the difference in the replys.
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
Well, thank you for the work around. <3 I don't understand people saying over and over it's an anti-pattern and then not offering a better solution lol anyway, here's a init container that might work in case of volume issues:
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
It sounds like more of a security door is wide open than a concern, you don't seem phased, why is this?
Genuine question btw, some security problems sound way worse then they are.
Maybe you can create a separate namespace with a policy that only this pod has this. The other part is to do the install required by root and then change to a non-root usage.
We're a place where coders share, stay up-to-date and grow their careers.
I know everyone always says don't run as ROOT. But what if you are using a database system that has to run as root. It's easy to say "dont do this" but in a situation like this, how do you protect all othe containers/pods from this "crazy" pod that runs processes as root.
I have started the article by explicitly stating that this has a security issue. and for more context, I have done this as a quick fix, specifically for Jenkins that was running in a docker container. And if Jenkins job builds and pushes a Docker image, it will need the docker commands. So mounting the docker process into the Jenkins container was a work around I found for this case.
You are more than welcome to suggest SPECIFIC alternative solutions, instead of generally stating it's a bad solution, which I myself already mentioned in the article. Thanks.
For other readers: running a container with root privileges is a DEFINITELY NO.
I kind of get you. The reason of why others are pointing this is a super bad practice/anti-pattern is because your post title is "Run Kubernetes Pod with root privileges" (tagged with #tutorial and with a very elaborated and motivational image), that title is more a How-To guide than an advice request. So yes, is important to point this is a bad practice before other more inexperienced devs/devops read it.
You could change your post's purpose asking for recommendations in how to fix your permissions issues, tag it with #help and you will see the difference in the replys.
Thanks for pointing this out! I actually will adjust it, because could really be misleading
Still contains the tag
tutorial.This kind of article is what promotes bad practices all over the internet.
This just remembers the
chmod 777all around StackOverflow as a way of solving issues.I removed the tag..don't know why it was not saved.
Just archived it. I don't rely on that post anyway.
Fix the permissions issues, not resort to run as
root.Sorry to tell you but youre article is really BAD ADVICE, specially when coming from a "senior"
devops"engineer".see above!
Well, thank you for the work around. <3 I don't understand people saying over and over it's an anti-pattern and then not offering a better solution lol anyway, here's a init container that might work in case of volume issues:
Thank you very much I have been looking for this solution for a very long time
see above!
It sounds like more of a security door is wide open than a concern, you don't seem phased, why is this?
Genuine question btw, some security problems sound way worse then they are.
see above!
Maybe you can create a separate namespace with a policy that only this pod has this. The other part is to do the install required by root and then change to a non-root usage.