[07:31:54] _joe_ (just back) - re: puppet patch - I do like the central data structure approach, it is clearer (for me) when one has to upgrade/check settings for different clusters and it is less error prone than git grepping everywhere. But I agree that it may be against what hiera wants us to do, if there is an alternative solution it would be good, but I woudln't go much far from what Janis created [07:32:00] since all the benefits would go away (namely the clarity of cluster settings etc..) [07:32:08] (at least this is my preference, I'd love to hear others as well :) [07:32:25] <_joe_> elukey: actually janis made a good case about how those data need to be used across roles [07:33:34] ah I see I am reading the patch, good :) [07:33:47] \o/ [09:49:54] Today I was investigating why the ores-legacy container (running uvicorn) was able to bind on port 80, and I found out something that I didn't know about docker: [09:50:06] root@ores-legacy-main-5468c74c5b-ddfm4:/# cat /proc/sys/net/ipv4/ip_unprivileged_port_start [09:50:09] 0 [09:50:22] and I also found https://medium.com/@olivier.gaumond/why-am-i-able-to-bind-a-privileged-port-in-my-container-without-the-net-bind-service-capability-60972a4d5496 [09:51:35] Not sure if it was discussed in the past but do we want to keep net.ipv4.ip_unprivileged_port_start=0 ? [09:51:50] (in the meantime I'll change the settings for ores-legacy) [10:03:29] doubtful, those are namespaced settings [10:03:55] as in, this doesn't affect the host, if that's what you are considering [10:04:00] it's only in the container AFAIK [10:04:57] containerd will complain on this one, though, won't it ? [10:06:51] akosiaris: yep yep it doesn't affect the host but it may lead to images running with namespace settings that are not great, (like running on port 80), but in theory it shouldn't be a big security concern. I was trying to reason out loud about it [10:07:00] re: containerd no idea [10:07:49] well, containerd is used by docker (moby actually, IIRC) and this PR is for moby, I doubt it found its way into containerd [10:08:13] so if anyone is listening below 1024 in our images, they are in for a surprise when we move to containerd [10:08:40] it's fixable ofc, although it's probably preferable that one doesn't end up spending time on this [10:09:06] the container port is anyway hidden from the rest of the infra. [10:09:12] as far as security goes... [10:09:21] ah yes sorry PEBCAK, so I was able to run uvicorn on port 80 in ml-staging [10:09:30] this is why I was a little confused [10:09:41] I am not sure what exactly is more secure if a process in a container listens on say 1080 and not 80 [10:10:12] nothing really, it may only generate some questions if people checks it [10:10:21] (like wondering why port 80 can be bound) [10:10:39] we can document it btw and just point people to it if they ask questions [10:10:48] but it's bound to break past k8s 1.24 [10:10:59] since we can't use docker with 1.24+ [10:11:09] yep yep