Addressable identities versus end points

Ziti Overlay
1

I am working through the differences between

  1. addressable identity
  2. addressable end point

And.. thought to ask for guidance on the differences.. and what considerations you need to make when deciding which approach to take..

This all came about when I compared the config of the zitified ssh example with the golaong simple client example.

let me know if you have any tips

For instance, with the zitified ssh example, you address the identity.. as opposed to an intercept.. and dial the service..

zssh opc@ssh.server.id -d -s zssh-service -c zssh.json -i private.key

I understand that this is possible through the setting of {"bindUsingEdgeIdentity":true}}' in the config settings below

though I am not really sure what is happening here for this specific situation

..
ziti edge create config zssh-server-host.v1 host.v1 '{"protocol":"tcp", "address":"localhost","port":22, "listenOptions": {"bindUsingEdgeIdentity":true}}'

ziti edge create service zssh-service --configs zssh-server-host.v1

ziti edge create service-policy zssh-service-binding Bind --service-roles '@zssh-service' --identity-roles '@ssh.server.id'
ziti edge create service-policy zssh-service-dialing Dial --service-roles '@zssh-service' --identity-roles '@ssh.client.id'

..
My confusion happens when I compare this setup to the golang simple-client example. In this case you don't address the identity.. rather its an intercept that is linked to the service.

so when you dial the service.. its going to look for the intercept.. not an addressable identity

go run simple-client.go $HOME/golang.http.client.json golanghttp

...

ziti edge create config golanghttp-intercept.v1 intercept.v1 '{"protocols":["tcp"],"addresses":["golanghttp.zitified"], "portRanges":[{"low":1234, "high":2345}]}'

ziti edge create service golanghttp --configs 'golanghttp-intercept.v1'

ziti edge create service-policy golanghttp-bind-policy Bind --identity-roles '@golang.http.server' --service-roles '@golanghttp'
ziti edge create service-policy golanghttp-dial-policy Dial --identity-roles '#http-clients' --service-roles '@golanghttp'

2

I feel like what you're asking is the difference between an "addressable terminator", vs a "regular" terminator so I'll take that approach.

"direct dialing"

Generally speaking, when you make a service, you associate bind and dial configurations to that service. Most times when you make the configs you don't specify the "bind options" or "dial options" in those configs. That's a "direct dial" (not an official phrase, I just made it up) service. That means when you dial the service it will just work and you don't know what identity provides the service.

"addressable dialing"

If you make a host.v1 config with listenOptions then you will need to make the intercept config with dialOptions. Addressable dialing means you know exactly what identity is providing the service and is probably more expected to be used with SDKs where you can set the dialOptions in your code. GitHub - openziti-test-kitchen/zssh: Ziti SSH uses addressable dialing like this, you can see it setting the dialOptions here: https://github.com/openziti-test-kitchen/zssh/blob/main/zsshlib/ssh.go#L239

The tunneling apps are not really configured to work with this at this time. You can use addressable dialing with a tunneler, but when you make the service you'll effectively have to hardcode the identity into service that you're dialing.

Hopefully that helps

1 Like
3

This is very helpful.. a few penny's dropped there. I noticed that listenOptions in the host config.. and the DialOptions in the zssh app. Makes sense.

Something else that I found out that took me some time to work through.. relates to the following two Python samples

For them to work, you need to setup the following

ziti edge create config dockerhttp-intercept.v1 intercept.v1 '{"protocols":["tcp"],"addresses":["dockerhttp.zitified"], "portRanges":[{"low":2000, "high":2000}]}'
ziti edge create service dockerhttp --configs dockerhttp-intercept.v1 -a "dockerhttp-services"
ziti edge create service-policy dockerhttp-dial-policy Dial --identity-roles '#httpbin-clients' --service-roles '#golanghttp-services'
ziti edge create service-policy dockerhttp-bind-policy Bind --identity-roles '@httpbin-identity' --service-roles '#golanghttp-services'

https://github.com/openziti/ziti-sdk-py/blob/main/sample/ziti-echo-server.py

https://github.com/openziti/ziti-sdk-py/blob/main/sample/ziti-http-server.py

What surprised me was not to define a host config... though I guess it makes sense as the example is all about starting up a host.. which then creates a terminator for you.

For this situation, it would be a direct dialing scenario..as you don't specify the dial options

Now that I mention it.. I can see what it means..

"addressable dialing" means that you specific the identity that you want to perform the dialing as it called.. this would offer a finer control over privileged access

whereas.. "direct dialing" just dials the service.. and there is no further security controls put in place.. unless it's embedded in the client / server code etc

4

host config has nothing to do with terminators. The reason you don't need a 'host config' is because the service itself is hosting (binding) the service. Tunnelers need the config to understand what service to host and how. The python sdk server is doing all this without the need for a config.

"Addressable/direct" dialing have no finer access/privilege control. It's just about whether you are targetting a specific identity or not. OpenZiti takes care of the accecss control/authorization the same ways as always.

1 Like