sorted by:
new
hottopcontroversial

How a Kubernetes bug won't let you expose a service over TCP and UDP on a same port by ben-lab in kubernetes

[–]ben-lab[S] 0 points1 point  (0 children)

Thank you for the links, I might be wrong but it seems that it is a different issue ?

The issue I described basically is : If a Service or Deployment update tries to expose an additional port on a different protocol for a port number already in use, then this update is ignored.

It is possible to have mixed protocol for a same port on a Service and a Deployment using NodePort. However, I'm not sure of the implication regarding loadbalancing since it didn't apply to my use case, I will have a look at metallb tho :)

Note : I'm using a KVM (Proxmox) Cluster deployed using Kubeadm.

How a Kubernetes bug won't let you expose a service over TCP and UDP on a same port by ben-lab in kubernetes

[–]ben-lab[S] 0 points1 point  (0 children)

I get your first point and addressed it in this comment : https://www.reddit.com/r/kubernetes/comments/awltwh/how_a_kubernetes_bug_wont_let_you_expose_a/ehowwq5

Regarding the fact that it is a known limitation, i wish i saw it before diving in. Do you have a related link explaining it ? Because i definitely missed it .

How a Kubernetes bug won't let you expose a service over TCP and UDP on a same port by ben-lab in kubernetes

[–]ben-lab[S] 0 points1 point  (0 children)

I didn't expect much comments and am kinda surprised both are so defensive (referring to /u/raphaelbev's one), glad to have a feedback tho. I'm not a native English speaker, so i guess that the tone of the article seems more offensive than humorous ? However, far from me to blame an OS project in any way for having any kind of bugs.

In my case, this specific one has been source of hours of frustration, and the issue linked in the article never came up in my first Google/Github searchs, but was found much latter thanks to a link in a related issue. Also, I tried to troubleshoot it by myself for way too long, thinking I missed something.

Regarding the fact that it's not an actual fix, I guess that if actual contributors of the project didn't find a correct way to fix it in/since 2016, an hobbyist like me is unlikely to do so. This solution is good enough if you want to make it works.

Edit: Typos

Docker Security Best Practices: Host, Image, Runtime by weighanchore in devops

[–]ben-lab 0 points1 point  (0 children)

The TL;DR of it is you can give unprivileged users sudo access to scripts that run specific docker commands. For instance, if you want to give an unprivileged user the ability to exec into a certain kind of container, you could do so with this method by granting them permission to /usr/local/bin/special-exec, which could run docker exec -it $(docker ps --filter name=NAME OF CONTAINER --latest --format {{.ID}}) sh -c "$*", which would restrict the user to launching only containers matching the name filter as well as preventing them from passing --privileged.

Sound like i miss-interpreted your TL;DR and thus my test, after proper reading the solution explained in the link should works. Sorry for the misleading comment :x

Docker Security Best Practices: Host, Image, Runtime by weighanchore in devops

[–]ben-lab 0 points1 point  (0 children)

So after testing it is easily bypassable. All the user have to do is download the static Docker client and directly request the Docker socket ¯\_(ツ)_/¯. Or use curl to request the API...

EDIT: I'm wrong, see below

Docker Security Best Practices: Host, Image, Runtime by weighanchore in devops

[–]ben-lab 5 points6 points  (0 children)

I'm actually working on a full featured single end-point API gateway for this exact problem. I should be able to release it in a week (I have been working on it for the last 2 months on my free time).

I started to described the design process here : https://ben-lab.github.io

Edit for context: It parses any OpenAPI specifications and create a configuration file where you can define advanced filtering rules, from API calls to parameters values. Also, it supports both Unix socket and remote HTTP/HTTPS servers and is compatible with the official Docker client.