Task container port mapping about tork HOT 11 CLOSED

Is that server running on Docker as well? If so, what about creating a docker network for that http server and using the networks property on the task (https://www.tork.run/rest-api)?

from tork.

The server is running on k8s. I have the docker socket mounted inside to have access to docker API.

from tork.

And you can't access the service through its service endpoint?

from tork.

No, that would required a k8s service account which is too much of a risk we don't want to do that.

from tork.

And you can't access the service through its service endpoint?

I misinterpreted your reply. I can not access the service through the service endpoint because the container IP address is blocked by the cluster.

from tork.

I'm thinking we could go for this:

• Add support for extra host config for tasks
• Add extra host if provided to hostConfig here https://github.com/runabol/tork/blob/main/runtime/docker/docker.go#L247

	hc := container.HostConfig{
		PublishAllPorts: true,
		Mounts:          mounts,
		Resources:       resources,
                ExtraHosts:      t.ExtraHosts,
	}

Task definition:

name: Example
tasks:
  - name: Example
    extra_hosts:
      - host.docker.internal:host-gateway
    run: |
      apk add curl
      curl host.docker.internal:8080 > $TORK_OUTPUT
    image:  alpine:3.18.3

from tork.

@runabol hi, any update on this? Maybe there is a quick fix to unblock on my end 🤔

from tork.

I guess I still fail to understand why an (internal) service endpoint can't be used to solve your problem.

Allowing tasks to interact with the host machine directly will potentially compromise the isolation of tasks and introduce security risks.

from tork.

I guess I still fail to understand why an (internal) service endpoint can't be used to solve your problem.

Allowing tasks to interact with the host machine directly will potentially compromise the isolation of tasks and introduce security risks.

mainly because I'm using tork in embedded mode. Worker has /var/run/docker.sock mounted inside, both coordinator & worker are deployed on a k8s cluster (same cluster with the internal service). This cluster only accept connections from the cluster IP range. In order for one of my worker node to reach this internal service, the cluster firewall rules need to be updated to allow new IP range, which is something I don't want to mess with.

from tork.

Have you considered implementing this using a middleware?

from tork.

Have you considered implementing this using a middleware?

Yeah, I made it work using middleware, letting the coordinator handle this and then pass results back to the task through ENVs. Thanks.

from tork.