Any way to zitify a single docker container

[mkuhlmann]

Hi all,

this is a newby question: Is there any way to zitify a docker container? I mean the container itself.

Thanks in advance!

[TheLumberjack]

This is a difficult question since technically the outer OS is really the one doing the work anyway. If you want to use ziti for OUTBOUND access, arguably, there's no good way to zitify 'a single container', because of 'how' docker works and how ziti work. If you want outbound ziti intercepts, it's probably just best to install the tunneler outside of docker.

If you want to provide access into the container, you would want to leverage docker networks and you would want to use the "ziti-host" docker container. It can provide access into the docker network in 'host' mode.

So I guess it depends on if you want "host only" mode (meaning from outside the docker network, in) or if you want outbound too (which there's really no good way to do)

Hope that helps.

[Frederik]

Hey,

The only way to zitify a Docker Container is to use the SDK and built your Identity inside your application which is running inside the Container to ensure encrypted traffic to the next router.

In general, if you want to zitify the Workloads in order of reachability or be part of the Network, you have 3 Options:

A) If you are running it inside an orchestration platform, you would be able to use the proxy and/or the Host mode to accomplish this. --> Workload Tunneling | OpenZiti

B) The Service inside the Docker Container is a self-written app, you can zitify it by using the several SDKs to ensure encrypted traffic to and from the Container

C) If it's just a Docker container running an app which can't have their own identity and the Docker container running at a Host, you would need to do the same as you would do with VM. Expose it and ensure it will reach the tunneling for the Router approach.

Best Regards,
Frederik

[ekoby]

To add to Frederik's answer above -- another potential way to zitify a single app container is to use .. well.. zitify GitHub - openziti/zitify.

In a lot of use cases it is a simpler solution than using SDKs -- no code changes, work with pre-built/3rd-party programs, etc.

It is most certainly not production ready but could be prioritized internally if there is enough interest

[qrkourier]

Inspired by @ekoby's zitify idea, I experimented to find the bare minimum files needed inside the container and to illustrate how the zitify script configures the env vars for a wrapped glibc program. If you control the container image it probably makes more sense to build-in the libzitify.so, and possibly also the zitify wrapper script.

The two files needed in the container are libzitify.so and the identity config file. In this example, I mounted those two files in an unmodified Ubuntu Focal container using my Docker host's network to reach the Ziti controller and router. If the controller and router were reachable from a Docker bridge, e.g., available on the public internet, then setting the --network host wouldn't be necessary.

docker run \
    --name zitify \
    --rm \
    --env ZITI_IDENTITIES=/opt/openziti/etc/identities/miniziti-client.json \
    --volume /tmp/miniziti-client.json:/opt/openziti/etc/identities/miniziti-client.json \
    --volume /usr/local/bin/libzitify.so:/usr/local/bin/libzitify.so \
    --network host \
    ubuntu:focal \
        bash -euc '
            { apt-get update && apt-get -y install curl; } &>/dev/null; 
            LD_PRELOAD=/usr/local/bin/libzitify.so curl -sSf http://httpbin.miniziti.private/get
        ' | jq

(2965)[        0.001]    INFO ziti_log_set_level set log level: root=1

{
  "args": {},
  "headers": {
    "Accept": [
      "*/*"
    ],
    "Host": [
      "httpbin.miniziti.private"
    ],
    "User-Agent": [
      "curl/7.68.0"
    ]
  },
  "origin": "ziti-edge-router connId=2147483666, logical=ziti-sdk[router=tls://miniziti-router.192.168.49.2.sslip.io:443]",
  "url": "http://httpbin.miniziti.private/get"
}

The JSON response is from a Ziti fork of httpbin that includes the hosting identity's Ziti router URL.

[mkuhlmann]

Thanks all!

I have found another solution as well in the meantime. Having a docker stack for every app in docker should be sufficient too, right?

Here is a bare minimum docker compose file:

version: "3"

services:
ziti-router:
hostname: router
image: openziti/ziti-host:latest
environment:
- ZITI_IDENTITY_BASENAME=testnginxrouter
- ZITI_ENROLL_TOKEN=redacted
networks:
- zitinet_nginx
volumes:
- ziti-fs-nginx:/persistent
nginx:
hostname: nginx
image: nginx:latest
networks:
- zitinet_nginx

networks:
zitinet_nginx:
name: zitinet_nginx
driver: bridge

volumes:
ziti-fs-nginx:

Thanks and best regards

[qrkourier]

Yes, you can include a Ziti container as a sidecar proxy or a standalone reverse proxy.

If the Ziti container will only provide a reverse proxy I recommend the Linux tunneler container: Containers | OpenZiti

If the Ziti container will provide Ziti DNS and client proxy then I recommend the router container: Deploy the Router with Docker | OpenZiti

Bear in mind that any Ziti container that is providing a client proxy can also serve as a reverse proxy for additional Ziti service(s) that have a "host" config (i.e., reverse-proxy config).

[mkuhlmann]

Thanks @qrkourier,
I have successfully deployed a side car router now, but I have an additional question.
Following the docs, my container is now reachable for ZITI identities. Thats good. But what if I want the container itself to be also able to rejach other ZITI services?

From the docs I see that that using "network_mode: service: therouter" does the trick for the busybox, but then its not adressable for the router anymore.

Any advice on this situation?

Thanks in advance!

[qrkourier]

@mkuhlmann

but then its not adressable for the router anymore

Nice going setting up your Docker environment to host a Ziti service!

Now, you want to change the way your non-Ziti app is connecting to Ziti services. I'll call this app container "myapp."

Currently, "myapp" container has a separate Docker network interface. It is reachable with Docker DNS at domain name "myapp" inside the Docker bridge network, and you have a Ziti service (host.v1) config specifying a target address like myapp:8080. This works because "therouter" can resolve the domain name "myapp" and connect to 8080/tcp on that Docker bridge IP.

Now you want "myapp" to also be able to connect to a Ziti service, while remaining reachable as the target server for the existing Ziti service.

This requires two changes:

1. set your Docker Compose project to bind both containers to the same Docker network interface by setting "myapp" to have network_mode: service:therouter
2. change your Ziti service (host.v1) config address from myapp:8080 to 127.0.0.1:8080. This is because "myapp" no longer exists when it is bound to "therouter" network interface.

[mkuhlmann]

Awesome, that works. Thank you so much!

[mkuhlmann]

Hi @qrkourier ,
I'm advancing my home lab again and came across another problem:

Now I have multiple docker services utilizing a ziti router via the network_mode: service:... each. connection. So far so good.
I want to be able to connect from one service to another. Via Ziti of course. My first thought was just to attach the relevant role attribute that allows my tunnelers to access the serive to the respective router that is supposed to connect, but that does not work.
In my specific case there is a portainer service on one host that I want to give access to a portainer-agent service on another host.
Any idea, what I could be missing here? Please let me know, if you need further info.

Thanks in advance!

[TheLumberjack]

Is your router running with tproxy mode? By default it will likely be in host mode. I don't do it every day, but I'm believe I remember being able to intercept in the past, but if I'm right, the router would need to be in tproxy mode.

[mkuhlmann]

Yes, the routers are in tproxy mode.

[mkuhlmann]

Here is one docker-compose file:

services:
  rtr.ptagent.REDACTED.REDACTED.REDACTED:
    restart: unless-stopped
    env_file:
      -  stack.env
    image: openziti/ziti-router
    volumes:
      - /root/portainer-agent/ziti:/ziti-router
    ports:
      - 3022
    expose:
      - 3022
    user: root
    cap_add:
      - NET_ADMIN
    logging:
      driver: "json-file"
      options:
        max-size: "200k"
        max-file: "10"
  portainer-agent:
    image: portainer/agent:latest
    network_mode: service:rtr.ptagent.REDACTED.REDACTED.REDACTED
    volumes:
      - /root/portainer-agent/data:/data
      - /root/portainer-agent/stackdata:/stackdata
      - /var/run/docker.sock:/var/run/docker.sock
    restart: unless-stopped
    depends_on:
      - rtr.ptagent.REDACTED.REDACTED.REDACTED
    logging:
      driver: "json-file"
      options:
        max-size: "200k"
        max-file: "10"

And the respective env:

ZITI_CTRL_ADVERTISED_ADDRESS=ctrl.REDACTED.REDACTED.REDACTED
ZITI_CTRL_ADVERTISED_PORT=1280
ZITI_ENROLL_TOKEN=REDACTED
ZITI_ROUTER_ADVERTISED_ADDRESS=rtr.ptagent.REDACTED.REDACTED.REDACTED
ZITI_ROUTER_MODE=tproxy
ZITI_BOOTSTRAP=true
ZITI_BOOTSTRAP_ENROLLMENT=true
ZITI_AUTO_RENEW_CERTS=true
ZITI_BOOTSTRAP_CONFIG=true
ZITI_ROUTER_TYPE=edge
ZITI_INTERFACE=0.0.0.0

[TheLumberjack]

did you add CAP_NET_ADMIN? I see you have it addded

    cap_add:
      - NET_ADMIN

I went back and checked and I did a video a while back in december for a ziti tv. you're not doing this from WSL are you? I had a problem with this from WSL. I used docker too, not Portainer.Not sure if that would matter

Other than that, it should work. Here was the service I had configured, it looks the same as yours as far as i see:

  ziti-private-green:
    image: "openziti/ziti-router"
    env_file:
      - ../complex/.env
      - ./.env
    user: root
    dns:
      - 127.0.0.1
      - 1.1.1.1
    cap_add:
      - NET_ADMIN
    environment:
      - ZITI_CTRL_ADVERTISED_ADDRESS=${ZITI_CTRL_ADVERTISED_ADDRESS:-ziti-controller}
      - ZITI_CTRL_ADVERTISED_PORT=${ZITI_CTRL_ADVERTISED_PORT:-6262}
      - ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS:-ziti-edge-controller}
      - ZITI_CTRL_EDGE_ADVERTISED_PORT=${ZITI_CTRL_EDGE_ADVERTISED_PORT:-1280}
      - ZITI_ROUTER_NAME=ziti-private-green
      - ZITI_ROUTER_ADVERTISED_ADDRESS=ziti-private-green
      - ZITI_ROUTER_ROLES=ziti-private-green
      - ZITI_ROUTER_MODE=tproxy
      - ZITI_CTRL_ADVERTISED_PORT=6262
      - ZITI_BOOTSTRAP_CONFIG_ARGS="--private"
    networks:
      - zitigreen
    volumes:
      - ziti-fs:/persistent

[TheLumberjack]

Oh - the DNS entry I have you don't have. That's probably the culprit

[mkuhlmann]

@TheLumberjack

• the DNS entry I have you don't have. That's probably the culpri

I just added the DNS entry, but no luck.
Its definitely a lookup error:

[qrkourier]

The Portainer Agent is a server listening on a TCP port like 9001, and Portainer Server needs to initiate a connection to that agent port via Ziti, correct?

I understand that both Portainer Server and Portainer Agent are running in containers, each sharing a network interface with a Ziti router in tproxy mode (two-way transparent proxy with Ziti DNS).

Despite the name Portainer Server, it's actually a network client of the Portainer Agent, which is the application server in this case. I'll refer to the Ziti service that publishes the Portainer Agent port as the "agent service."

Things to check:

• P. Agent's router identity has a role matching the bind service policy for the agent service
• agent service has host config targeting agent port, e.g., 127.0.0.1:9001
• P. Server's router identity has a role matching the dial service policy for the agent service
• agent service has intercept config with address matching P. Server's agent URL, e.g. https://agent.portainer.ziti.internal:9001/ping
• ensure you can obtain a response from the agent service's /ping endpoint from another Ziti identity having the same role granting dial permission to the agent service