My personal reasons to not run my Nginx reverse-proxy inside Docker
1–10 of 18 posts
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#2Oof, in his reasons to use docker (which it seems like he uses as a synonym for containerization), misses probably the most important one -
6. Provides an additional layer of security between the application and its host
As far as his availability concerns, I don't see why running or not running docker would help this problem. You can certainly build highly available nginx reverse proxies in docker, and can do in place upgrades with no downtime. This has been solved for a very long time.
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#3[deleted]
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#4Just run it in LXC. Then the container is not immutable but the process will still be isolated with it's dependencies. And infrastructure as code, with Ansible etc, all possible.
Also the talk about docker being itself a dependency I can't really follow. I guess you would have many other dockers also running, otherwise being nxing the only thing within docker.. that doesn't make much sense..
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#5Oof, in his reasons to use docker (which it seems like he uses as a synonym for containerization), misses probably the most important one - 6. Provides an additional layer of security between the application and its host As far as his availability concerns, I don't see why running or not running docker would help this problem. You can certainly build highly available nginx reverse proxies in docker, and can do in pla…
Docker (and containers in general) adds namespacing, but not security, for applications. If anything, docker can add MORE attack vectors.
No one should use containers primarily for security ever.
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#6This a good analysis.
However, for a quick skim of the article, all of cited issues with Docker as such are in fact solved by services such as ECS[0].
Thus, the question of whether to manage nginx directly may be more of a business decision (am I dealing with a cloud provider?) than a technical one (are these requirements delivered by a service?).
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#7Oof, in his reasons to use docker (which it seems like he uses as a synonym for containerization), misses probably the most important one - 6. Provides an additional layer of security between the application and its host As far as his availability concerns, I don't see why running or not running docker would help this problem. You can certainly build highly available nginx reverse proxies in docker, and can do in pla…
Docker (and containers in general) adds namespacing, but not security, for applications. If anything, docker can add MORE attack vectors. No one should use containers primarily for security ever.
Sorry but what you said makes absolutely no sense. The security implication I am talking about is that in a typical container the application cannot escalate privilege out of the container and touch the host, with the exception of obvious things like shared file systems, etc. This is a known benefit of containerization and not at all controversial.
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#8Earlier quoted context omitted.
Docker (and containers in general) adds namespacing, but not security, for applications. If anything, docker can add MORE attack vectors. No one should use containers primarily for security ever.
Sorry but what you said makes absolutely no sense. The security implication I am talking about is that in a typical container the application cannot escalate privilege out of the container and touch the host, with the exception of obvious things like shared file systems, etc. This is a known benefit of containerization and not at all controversial.
Bold of you to assume that most devs are running containers with a non-root user.
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#9Earlier quoted context omitted.
Sorry but what you said makes absolutely no sense. The security implication I am talking about is that in a typical container the application cannot escalate privilege out of the container and touch the host, with the exception of obvious things like shared file systems, etc. This is a known benefit of containerization and not at all controversial.
Bold of you to assume that most devs are running containers with a non-root user.
Devs maybe, but the author is talking about production environments which are definitely moving to rootless.
Re: My personal reasons to not run my Nginx reverse-proxy inside Docker
#10Earlier quoted context omitted.
Bold of you to assume that most devs are running containers with a non-root user.
Devs maybe, but the author is talking about production environments which are definitely moving to rootless.
'Production' is an interesting appeal to authority, if I may risk using terms improperly.
My 'toy' controller/replica are production but due to planning - have no weight. Two people care in the 'oh that's mildly inconvenient' sense when they break. Everything moves on.
To lean into hyperbole a bit: for every shop that's rootless, there are nine that are rootful.
I don't say any of this to be defeatist, more... realistic. There's:
1) what people say they do
2) what people actually do
It's surely trending positively, but I'm also not interested in arguing about window dressing while the house is on fire.
What does SELinux or AppArmor look like in this hypothetical, disabled per usual? Plenty of work to do. No pats on the back yet.
I say all of this a bit heavily - not OP. Closely related to some heated talks I've had this week. It's easy to bike-shed endlessly