Task container port mapping

[v36372]

Hi, I'm having a need for one of my tasks to connect to a http server running on the worker node (for my usecase, task containers are spawned from the worker dockerd deamon). To do this, I have thought of several ways:

• map http server port into the task container (-p 8080:8080)
• add extra host param for the task container to have access to host.docker.internal hostname (--add-host=host.docker.internal:host-gateway)
• use host network for task container (--net=host). This isn't a viable option for me due to security reason.

I think port mapping could be the easiest to implement

[runabol]

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)?

[v36372]

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

[runabol]

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

[v36372]

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

[v36372]

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.

[v36372]

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

[v36372]

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

[runabol]

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.

[v36372]

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.

[runabol]

Have you considered implementing this using a middleware?

[v36372]

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.