Any way to zitify a single docker container

Zitifications
1

Hi all,

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

Thanks in advance!

2

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.

3

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

2 Likes
4

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

5

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.

1 Like
6

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

7

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