How to access Ziti Controller via Console

I deployed the controller using k3d in ec2 machine following the blog ,
Deploy OpenZiti in Kubernetes with Ease Using k3d ,

--namespace "ziti" --create-namespace \
--set clientApi.advertisedHost="ec2-<my_ip>" \
--set clientApi.advertisedPort=1280 \
--set clientApi.service.type=LoadBalancer \
--set ctrlPlane.advertisedHost="ec2-<my_ip>" \
--set ctrlPlane.advertisedPort=6262 \
--set ctrlPlane.service.type=LoadBalancer \
--set \
--set trust-manager.enabled=true \
--set cert-manager.enabled=true

Then I deployed ZAC as helm chart as a nodePort service , I was not able to access console on browser it complained that it should be secure so since localhost is secure
I did ssh-tunneling into the ec2 machine along with port-forward and now i can open console on browser .

So what should be my controller name and url

I tried the variants with

as both name and URL and also tried the same with port 6262 , also tried with controller name ziti-controller keeping the urls

That appears to be the correct URL based on the advertised address and port you showed here. Can you connect to the controller and inspect the certificate and confirm the DNS SANS field contains this address?

This doesn't mean much to me:

was not able to access console on browser it complained that it should be secure

Without knowing how you're deploying things, this might be perfectly fine. If you're using a self signed certificate that's entirely expected

There is no certificate here , I installed it from here Install the Console in Kubernetes | OpenZiti
without additional configuring

@sadath-12 how were you deploying ZAC? Did you run using the following steps?

npm install
ng build ziti-console-lib
ng build ziti-console-node
node server

No @rgalletto but I deployed via helm

helm install \
  --namespace ziti-console --create-namespace --generate-name \
  openziti/ziti-console \
    --set service.type=LoadBalancer \
    --set service.advertisedPort=80

then edited to the NodePort

Ahh ok I see. So if you are self hosting and accessing ZAC locally via HTTPS the "untrusted certificate" error is expected unless you use a self signed cert that is trusted by your systems trust store.

There are a few different setup guides out there that explain how to do this, but the one i typically would follow is explained here by LetsEncrypt:

I've never installed ziti console in kubernetes but when in docker or directly starting the node server, if you set these environment variables and supply valid cert/key

# The in-container path for the key file to use for TLS.
# The in-container path for the cert bundle file to use for TLS.
# the HTTPS port ZAC uses

That should enable TLS in your ziti console

In Kubernetes, the best way to configure a TLS server certificate for the standalone ZAC Node.js server is with Cert Manager (CM) (section link) and an Ingress Controller with the ClusterIP service type instead of the NodePort service type you're currently using.

This feature will deprecate the standalone ZAC Node.js server for Kubernetes deployments: add console service option to controller chart · Issue #222 · openziti/helm-charts · GitHub

I think we should have insecure option as well to use , for dev purposes

I see what you mean. When I install the ziti-console chart to deploy the standalone ZAC Node.js server without an Ingress Controller, the web browser displays an empty white screen and the Javascript console complains about an SSL error, citing a CORS violation.

As a workaround, you can deploy the standalone ZAC chart and access it via the CORS-allowed "localhost" address without TLS by forwarding a local port with kubectl.

kubectl -n ziti port-forward deployments/ziti-console 1408:1408

Then, visit http://localhost:1408/login

One of the nice things about the forthcoming controller chart feature I mentioned is that it will use Ziti's built-in TLS by default.

thanks @qrkourier you sense me nicely .
I am aware localhost is considered as secure , but this cluster is in aws not in my local .
So instead I tried to ssh-tunnel into my laptop and opened zac and it works after that the issue is it is not connecting to the controller and the steps i tried to login is

controller name:

controller name:

controller name: ziti-controller

controller name: ziti-controller

login fails in all the above cases

I'm happy to hear you worked around the empty white console page by forwarding a local port with SSH to access the NodePort without TLS. You can also do this with kubectl instead of SSH, but you must use the container port, not the advertised port of the cluster service if forwarding to the deployment with kubectl.

Now you're having trouble with logging in as "admin," correct?

When you deploy the standalone ZAC server, you have the option to configure the URL of the Ziti controller, e.g., --set "settings.edgeControllers[0].url=".

Alternatively, you can manually add a controller by visiting the console and adding the URL.

I assume you are using the correct password for user "admin."

What is the precise symptom of the failure? Is an error message displayed? Is there a interesting Javascript console message? Is there an HTTP response from the server when you submit the form? Does the console's pod log show anything helpful?

At first ZAC asked me controller name and url and it says , login failed cant connect to controller.
I'm sure controller is working as I can login via ziti cli

There must be a problem with the URL to the controller's client API or the connection to that URL. Did you try it with a prefix https://?

with https I get "error": "Invalid Edge Controller"
with http I get {"error":"Edge Controller not Online","errorObj":{}}

I have another option for you. I've just released v1.0.10 of the ziti-controller chart. It provides the console on the /zac/ path in the management API, so you no longer need a separate ziti-console deployment.

You can ensure the new version is installed by adding this to your helm upgrade command: --version 1.0.10.

After upgrading the ziti-controller chart, you can visit the console at https://{controller address}:{controller port}/zac/.

but the ziti controller is also running on http for testing purpose . Why cant we have http for zac for testing purpose ?

I'm not aware of a way to configure any of Ziti controller's servers with a non-TLS web listener. This is by design and does not impede testing. For example, you can operate a Ziti controller with a single web listener (a web configuration object where RESTful APIs may be bound) and it will use the controller's default server certificate for all APIs, e.g., edge-client, edge-management.

The console's static files are present in to the ziti-controller container image in /ziti-console, and the new Helm chart configures the controller to serve the single page application (SPA) on the same web listener as the edge-management binding with URL path /zac/.