Feature request: serve with TLS about drone-convert-pathschanged HOT 11 CLOSED

Just as a workaround, @tiagoposse you could configure two containers to be run inside a pod (see docs. This way you could setup nginx proxy as a sidecar and use a unix socket for communication between the app and the proxy. I would also use a memory backing for the volume.

from drone-convert-pathschanged.

Would a reverse proxy like NGINX do the job? I use it personally, and it doesn't seem to add much of any performance overhead.

from drone-convert-pathschanged.

Unfortunately we need end-to-end encryption, so the reverse proxy wouldn't cut it :(

from drone-convert-pathschanged.

Could you explain what you mean by end-to-end encryption (are you talking about SSL)? Where/How do you plan on using it?

from drone-convert-pathschanged.

Sorry, should've been clearer. I'm indeed talking about SSL. Using a different pod as a reverse proxy still leaves the traffic between that pod and this plugin unencrypted. We want all possible traffic inside a cluster to be encrypted if possible.

from drone-convert-pathschanged.

When you say using a different pod, is the reverse proxy still on the same machine as the drone-convert-pathschanged image? (Not very familiar with Kubernetes)

from drone-convert-pathschanged.

There are ways of enforcing that both pods exist in the same node, but even then, pods in the same node would have access to the traffic

from drone-convert-pathschanged.

Would both pods being on the same node not create enough security between the two?

If I'm not mistaken, the pods would just be communicating with each other over localhost. (They would just communicate in a similar fashion to Docker networks, right?)

from drone-convert-pathschanged.

Although I can't speak with 100% confidence, I think this would work different.

• Docker creates an overlay network and you put 2 containers in the same network, isolated from the other containers.
• In kubernetes, if 10 pods are in the same node, they share the local network.

A set of other reasons why I think supporting TLS here would be better:

• Paying for an additional pod to be running 24/7 for this purpose is unnecessary
• Supporting TLS at the app level is the only way to achieve end-to-end encryption
• In case of cluster stress or node failure, a situation can arise where there is no node that could accommodate both nginx and converter pods, creating a failure unnecessarily (of course there would be more pressing matters here, but this is still valid)

from drone-convert-pathschanged.

That explains it well - I'm assuming you use the Kubernetes feature similar to what some Cloud providers offer?

In that case I see it working well, just not something I thought much of.

from drone-convert-pathschanged.

Sure. I'd do it a different way considering we've spent more time on justifications than we'd actually spend fixing this "natively". But I understand there's a satisfying workaround, so closing this now :)

from drone-convert-pathschanged.