diff --git a/docusaurus/blog/wildcard-dns/cheatsheet.md b/docusaurus/blog/wildcard-dns/cheatsheet.md index 7e00fbf3d..9e9990efb 100644 --- a/docusaurus/blog/wildcard-dns/cheatsheet.md +++ b/docusaurus/blog/wildcard-dns/cheatsheet.md @@ -4,7 +4,7 @@ authors: dovholuknf # Wildcard DNS Cheatsheet -```bash +``` # ------------- start docker docker-compose up diff --git a/docusaurus/blog/zitification/kubernetes/index.md b/docusaurus/blog/zitification/kubernetes/index.md index c865d0a2e..c84032deb 100644 --- a/docusaurus/blog/zitification/kubernetes/index.md +++ b/docusaurus/blog/zitification/kubernetes/index.md @@ -57,7 +57,7 @@ as my service name. When deployed by a cloud provider, the Kubernetes API is gen #### Example Ziti CLI commands -```bash +``` # the name of the service service_name=k8s.oci # the name of the identity you'd like to see on the kubectl client @@ -100,7 +100,7 @@ Once we have established the pieces of the [Ziti Network][8], we'll want to get Notice that we are changing the file location output by these commands and they are being output as two separate Kubernetes config files. If you prefer to merge them all into one big config file and change contexts - feel free. I left them as separate files here because it provides a very clear separation as to which config is being used or modified. -```bash +``` # Get this value directly from Oracle oci_cluster_id="put-your-cluster-id-here" @@ -129,7 +129,7 @@ At this point we should have all the pieces in place so that we can start puttin This step is very straight-forward for anyone who's used Kubernetes before. Issue the following commands, making sure the path is correct for your public Kubernetes config file, and verify Kubernetes works as expected. -```bash +``` export KUBECONFIG=/tmp/oci/config.oci.public kubectl get pods -v6 --request-timeout='5s' I1019 13:57:31.910962 3211 loader.go:372] Config loaded from file: /tmp/oci/config.oci.public @@ -148,7 +148,7 @@ Next we'll grab a few lines from the excellent guide NetFoundry put out for inte 3. locate the jwt file for the Kubernetes identity. If you followed the steps above the file will be named: `"${the_kubernetes_identity}".jwt` (make sure you replace the variable with the correct value) 4. use the jwt to add Ziti: `helm install ziti-host netfoundry/ziti-host --set-file enrollmentToken="${the_kubernetes_identity}".jwt` (again make sure you replace the variable name) If you need to, make sure you create a persistent volume. The ziti pod requires storage to store a secret. -```bash +``` apiVersion: v1 kind: PersistentVolume metadata: @@ -169,7 +169,7 @@ spec: Now consume the one time token (the jwt file) to enroll and create a client-side identity using the Ziti Desktop Edge for Windows (or MacOS or via the `ziti-edge-tunnel` if you prefer). Once you can see the identity in your tunneling app, you should be able to use the private kubernetes config file to access the same exact cluster. Remember though, we have mapped the port on the client side to use 443. That means you'll need to update your config file and change 6443 --> 443. Now when you run `get pods` you'll see the ziti-host pod deployed: -```bash +``` export KUBECONFIG=/tmp/oci/config.oci.private kubectl get pods NAME READY STATUS RESTARTS AGE @@ -185,7 +185,7 @@ If you have made it this far, you've seen us access the Kubernetes API via the p 3. Build `kubeztl` from [the GitHub repo](https://github.com/openziti-test-kitchen/kubeztl) 4. Use `kubeztl` to get pods! - ```bash + ``` ./kubeztl -zConfig ./id.json -service k8s.oci get pods NAME READY STATUS RESTARTS AGE ziti-host-976b84c66-kr4bc 1/1 Running 0 101m @@ -195,7 +195,7 @@ If you have made it this far, you've seen us access the Kubernetes API via the p The `kubeztl` command has also been modified to allow you to add the service name and config file directly into the file itself. This is convenient since you will not need to supply the ziti identity file, nor will you need to specify which service to use. Modifying the file is straight-forward. Open the config file, find the context listed under the contexts root and add two rows as shown here. -```bash +``` contexts - context: cluster: cluster-cjw4arxuolq @@ -206,7 +206,7 @@ contexts Once done - you can now simply use the context the same way you have always - `kubeztl get pods`! -```bash +``` ./kubeztl get pods NAME READY STATUS RESTARTS AGE ziti-host-976b84c66-kr4bc 1/1 Running 0 114m diff --git a/docusaurus/blog/zitification/prometheus/part2.md b/docusaurus/blog/zitification/prometheus/part2.md index a277de086..812b52d80 100644 --- a/docusaurus/blog/zitification/prometheus/part2.md +++ b/docusaurus/blog/zitification/prometheus/part2.md @@ -117,13 +117,13 @@ attribute to the identity of `kubeA.services`. This will be used later when sett #### Create the Identity -```text +``` ziti edge create identity device kubeA.ziti.id -o /tmp/prometheus/kubeA.ziti.id.jwt -a "kubeA.services" ``` You should see confirmation output such as: -```text +``` New identity kubeA.ziti.id created with id: BeyyFUZFDR Enrollment expires at 2022-04-22T01:18:53.402Z ``` @@ -133,7 +133,7 @@ Once created, we can use helm to install the `ziti-host` pod. The jwt is a one-u `ziti-host`. As this is probably your first time running this helm chart, you will need to install it. The command is idempotent to running it over and over is of no concern. Run the following: -```text +``` helm repo add netfoundry https://netfoundry.github.io/charts/ helm repo update helm install ziti-host netfoundry/ziti-host --set-file enrollmentToken="/tmp/prometheus/kubeA.ziti.id.jwt" @@ -141,7 +141,7 @@ helm install ziti-host netfoundry/ziti-host --set-file enrollmentToken="/tmp/pro You will see the confirmation output from helm. Now when you look at your Kubernetes cluster with `kubectl`, you will see a pod deployed: -```text +``` kubectl get pods NAME READY STATUS RESTARTS AGE ziti-host-db55b5c4b-rpc7f 1/1 Running 0 2m40s @@ -159,7 +159,7 @@ second service provided is a scrape target for Prometheus. There is one metric e #### Create and Enroll the Identity -```text +``` ziti edge create identity user kubeA.reflect.id -o /tmp/prometheus/kubeA.reflect.id.jwt ziti edge enroll /tmp/prometheus/kubeA.reflect.id.jwt -o /tmp/prometheus/kubeA.reflect.id.json ``` @@ -171,7 +171,7 @@ able to test the service to ensure they work. To enable testing the services, we will allow identities using tunneling apps to be able to access the services, this is how we'll verify the services work. Make the configs and services now. -```text +``` # create intercept configs for the two services ziti edge create config kubeA.reflect.svc-intercept.v1 intercept.v1 \ '{"protocols":["tcp"],"addresses":["kubeA.reflect.svc.ziti"],"portRanges":[{"low":80, "high":80}]}' @@ -190,7 +190,7 @@ need to be authorized to bind these services. Tunneling apps will need to be aut Prometheus servers will need to be able to dial these services too. We will now create `service-policies` to authorize the tunneling clients, Prometheus scrapes, and the `reflectz` server to bind the service. -```text +``` # create the bind service policies and authorize the reflect id to bind these services ziti edge create service-policy "kubeA.reflect.svc.bind" Bind \ --service-roles "@kubeA.reflect.svc" --identity-roles "@kubeA.reflect.id" @@ -211,7 +211,7 @@ that to deploy `reflectz` we need to supply an identity to the workload using `- to 'Bind' the services the workload exposes. We also need to define what the service names are we want to allow that identity to bind. We do this using the `--set serviceName` and `--set prometheusServiceName` flags. -```text +``` helm repo add openziti-test-kitchen https://openziti-test-kitchen.github.io/helm-charts/ helm repo update helm install reflectz openziti-test-kitchen/reflect \ @@ -222,7 +222,7 @@ helm install reflectz openziti-test-kitchen/reflect \ After running helm, pod 2 should be up and running. Let's take a look using `kubectl` -```text +``` kubectl get pods NAME READY STATUS RESTARTS AGE reflectz-775bd45d86-4sjwh 1/1 Running 0 7s @@ -243,7 +243,7 @@ but we can define it now. #### Create and Enroll the Identity -```text +``` # create and enroll the identity. ziti edge create identity user kubeA.prometheus.id -o /tmp/prometheus/kubeA.prometheus.id.jwt -a "reflectz-clients","prometheus-clients" ziti edge enroll /tmp/prometheus/kubeA.prometheus.id.jwt -o /tmp/prometheus/kubeA.prometheus.id.json @@ -251,7 +251,7 @@ ziti edge enroll /tmp/prometheus/kubeA.prometheus.id.jwt -o /tmp/prometheus/kube #### Create Configs and Services (including Tunneling-based Access) -```text +``` # create the config and service for the kubeA prometheus server ziti edge create config "kubeA.prometheus.svc-intercept.v1" intercept.v1 \ '{"protocols":["tcp"],"addresses":["kubeA.prometheus.svc"],"portRanges":[{"low":80, "high":80}]}' @@ -263,7 +263,7 @@ ziti edge create service "kubeA.prometheus.svc" \ #### Authorize the Workload and Clients -```text +``` # grant the prometheus clients the ability to dial the service and the kubeA.prometheus.id the ability to bind ziti edge create service-policy "kubeA.prometheus.svc.dial" Dial \ --service-roles "@kubeA.prometheus.svc" \ @@ -290,7 +290,7 @@ network. We're also passing one `--set-file` parameter to tell Prometheus what i This secret will be used when we configure Prometheus to scrape the workload. Go ahead and run this command now and run `kubectl get pods` until all the containers are running. -```text +``` helm repo add openziti-test-kitchen https://openziti-test-kitchen.github.io/helm-charts/ helm repo update helm install prometheuz openziti-test-kitchen/prometheus \ @@ -327,13 +327,13 @@ we'll create that identity, authorize it to bind the services, and authorize cli similar to what we did for ClusterA, there's not much to explain. Setup ClusterB's `reflectz` now. #### Create the Identity -```text +``` ziti edge create identity user kubeB.reflect.id -o /tmp/prometheus/kubeB.reflect.id.jwt ziti edge enroll /tmp/prometheus/kubeB.reflect.id.jwt -o /tmp/prometheus/kubeB.reflect.id.json ``` #### Create Configs and Services (including Tunneling-based Access) -```text +``` # create intercept configs for the two services ziti edge create config kubeB.reflect.svc-intercept.v1 intercept.v1 \ '{"protocols":["tcp"],"addresses":["kubeB.reflect.svc.ziti"],"portRanges":[{"low":80, "high":80}]}' @@ -346,7 +346,7 @@ ziti edge create service "kubeB.reflect.scrape.svc" --configs "kubeB.reflect.svc ``` #### Authorize the Workload to Bind the Services -```text +``` # create the bind service policies and authorize the reflect id to bind these services ziti edge create service-policy "kubeB.reflect.svc.bind" Bind \ --service-roles "@kubeB.reflect.svc" --identity-roles "@kubeB.reflect.id" @@ -355,7 +355,7 @@ ziti edge create service-policy "kubeB.reflect.scrape.svc.bind" Bind \ ``` #### Authorize Clients to Access the Services -```text +``` # create the dial service policies and authorize the reflect id to bind these services ziti edge create service-policy "kubeB.reflect.svc.dial" Dial \ --service-roles "@kubeB.reflect.svc" --identity-roles "#reflectz-clients" @@ -364,7 +364,7 @@ ziti edge create service-policy "kubeB.reflect.svc.dial.scrape" Dial \ ``` #### Deploy `reflectz` {#deploy-reflectz-1} -```text +``` helm repo add openziti-test-kitchen https://openziti-test-kitchen.github.io/helm-charts/ helm repo update helm install reflectz openziti-test-kitchen/reflect \ @@ -381,7 +381,7 @@ the surface with very subtle differences. We'll explore these differences as we config** (a difference from the ClusterA install), a service, and two service-policies. Let's get to it. #### Create the Identity -```text +``` ziti edge create identity user kubeB.prometheus.id -o /tmp/prometheus/kubeB.prometheus.id.jwt -a "reflectz-clients","prometheus-clients" ziti edge enroll /tmp/prometheus/kubeB.prometheus.id.jwt -o /tmp/prometheus/kubeB.prometheus.id.json ``` @@ -391,7 +391,7 @@ Here's a difference from ClusterA. Since we are going to listen on the OpenZiti we don't need to create a `host.v1` config. A `host.v1` config is necessary for services which have a 'Bind' configuration and are being bound by a tunneling application. We're not doing that, here Prometheus will 'Bind' this service, thus we don't need that `host.v1` config. -```text +``` # create the config and service for the kubeB prometheus server ziti edge create config "kubeB.prometheus.svc-intercept.v1" intercept.v1 \ '{"protocols":["tcp"],"addresses":["kubeB.prometheus.svc"],"portRanges":[{"low":80, "high":80}], "dialOptions": {"identity":"kubeB.prometheus.id"}}' @@ -411,7 +411,7 @@ to be bound by the `ziti-host` identity. Here we are flipping that script. We are allowing Prometheus to bind this service! That means we'll need to authorize the `kubeB.prometheus.id` to be able to bind the service. -```text +``` # grant the prometheus clients the ability to dial the service and the kubeB.prometheus.id the ability to bind ziti edge create service-policy "kubeB.prometheus.svc.dial" Dial \ --service-roles "@kubeB.prometheus.svc" \ @@ -442,7 +442,7 @@ Finally, to allow the server to scrape targets we need to supply a final identit You'll notice for simplicities sake, we are using the same identity for all three needs which is perfectly fine. If you wanted to use a different identity, you could. That choice is up to you. To keep it simple we just authorized this identity for all these purposes. -```text +``` # install prometheus helm repo add openziti-test-kitchen https://openziti-test-kitchen.github.io/helm-charts/ helm repo update @@ -470,6 +470,6 @@ All the commands above are also available in github as `.sh` scripts. If you wou [ziti-doc repository](https://github.com/openziti/ziti-doc) and access the scripts from the path mentioned below. "Cleanup" scripts are provided if desired. -```text +``` ${checkout_root}/docusaurus/blog/zitification/prometheus/scripts ``` \ No newline at end of file diff --git a/docusaurus/blog/zitification/prometheus/part3.md b/docusaurus/blog/zitification/prometheus/part3.md index 29a2b91c6..0e06cd752 100644 --- a/docusaurus/blog/zitification/prometheus/part3.md +++ b/docusaurus/blog/zitification/prometheus/part3.md @@ -28,13 +28,13 @@ everything get installed and it all "seems to work". But how do we **know** it w let's enroll it in your local tunneling app and find out. Go out and get [a tunneling client](/docs/learn/core-concepts/clients/choose) running locally. Once you have that installed, provision an identity and enroll it with your tunneling client. -```text +``` ziti edge create identity user dev.client -a "prometheus-clients","reflectz-clients" ``` You should have access to six total services when this identity is enrolled: -```text +``` Service Name: kubeA.prometheus.svc Intercept: kubeA.prometheus.svc:80 Service Name: kubeA.reflect.svc @@ -70,14 +70,14 @@ Neat, but this isn't what we want to actually monitor. What we really want to monitor is the workload we deployed: `reflectz`. We can do this by editing the Prometheus configmap using `kubectl`. Let's go ahead and do this now: -```text +``` kubectl edit cm prometheuz-prometheus-server ``` This will open an editor in your terminal and allow you to update the config map for the pod. Once the editor is open, find the section labeled "scrape_config" and add the following entry: -```text +``` - job_name: 'kubeA.reflectz' scrape_interval: 5s honor_labels: true @@ -109,14 +109,14 @@ location of the identity. If you would like to tail the `configmap-reloadz` container, you can issue this one liner. This will instruct `kubectl` to tail the logs from `configmap-reloadz`. -```text +``` pod=$(kubectl get pods | grep server | cut -d " " -f1); echo POD: $pod; kubectl logs -f "$pod" prometheus-server-configmap-reload ``` When the trigger happens for ClusterA you will see a message like the one below. Notice that `configmap-reloadz` is using the underlay network: `http://127.0.0.1:9090/-/reload` -```text +``` 2022/04/23 20:01:23 config map updated 2022/04/23 20:01:23 performing webhook request (1/1/http://127.0.0.1:9090/-/reload) 2022/04/23 20:01:23 successfully triggered reload @@ -161,7 +161,7 @@ Now we can use netcat to open a connection through this intercept a few times. T reflect service. Connect, send some text, the use ctrl-c to disconnect. Do that a few times then click 'execute' again on the graph page. You can see I did this over a minute and moved my total count on kubeA to 8, shown below. -```text +``` /tmp/prometheus$ nc kubeA.reflect.svc.ziti 80 kubeA reflect test you sent me: kubeA reflect test @@ -184,7 +184,7 @@ Hopefully you agree with me that this is pretty neat. Well what if we take it to workload we deployed to ClusterB? Could we get that to work? Recall from above how we enabled the job named 'kubeA.reflectz'. What if we simply copied/pasted that into the configmap changing kubeA --> kubeB. Would it work? Let's see. -```text +``` # edit the configmap on ClusterA: kubectl edit cm prometheuz-prometheus-server @@ -214,7 +214,7 @@ ClusterA, we have just scraped a workload from Kubernetes ClusterB, entirely ove Generate some data like you did before by running a few netcat connection/disconnects and click 'Execute' again. Don't forget to send the connection request to kubeB though! -```text +``` nc kubeB.reflect.svc.ziti 80 this is kubeb you sent me: this is kubeb @@ -245,7 +245,7 @@ data from our two Prometheus instances using a locally deployed `Prometheuz` via GitHub has a sample Prometheus [file you can download](https://raw.githubusercontent.com/openziti/ziti-doc/main/docusaurus/blog/zitification/prometheus/scripts/local.prometheus.yml). Below, I used curl to download it and put it into the expected location. -```text +``` curl -s https://raw.githubusercontent.com/openziti/ziti-doc/main/docusaurus/blog/zitification/prometheus/scripts/local.prometheus.yml > /tmp/prometheus/prometheus.config.yml ziti edge create identity user local.prometheus.id -o /tmp/prometheus/local.prometheus.id.jwt -a "reflectz-clients","prometheus-clients" @@ -270,7 +270,7 @@ But wait, I'm not done. That docker instance is listening on an underlay network I want to fix that too. Let's start this docker container up listening only on the OpenZiti overlay. Just like in [part 2](./part2.md) we will make a config, a service and two policies to enable identities on the OpenZiti overlay. -```text +``` curl -s https://raw.githubusercontent.com/openziti/ziti-doc/main/docusaurus/blog/zitification/prometheus/scripts/local.prometheus.yml > /tmp/prometheus/prometheus.config.yml # create the config and service for the local prometheus server @@ -295,7 +295,7 @@ you're familiar with docker these will probably all make sense. The most importa flag. The `-p` flag is used to expose a port from inside docker, outside docker. Look at the previous docker sample and you'll find we were mapping local underlay port 9090 to port 9090 in the docker container. In this example, **we will do no such thing**! :) -```text +``` docker run \ -e ZITI_LISTENER_SERVICE_NAME=local.prometheus.svc \ -e ZITI_LISTENER_IDENTITY_FILE=/etc/prometheus/ziti.server.json \ diff --git a/docusaurus/blog/zitification/zitifying-scp/index.md b/docusaurus/blog/zitification/zitifying-scp/index.md index b3d88c054..09acb9029 100644 --- a/docusaurus/blog/zitification/zitifying-scp/index.md +++ b/docusaurus/blog/zitification/zitifying-scp/index.md @@ -40,19 +40,19 @@ There are two main functions of `zscp`. Just like `scp` you can send and receive To send files we use this basic syntax: -```bash +``` ./zscp LOCAL_FILEPATHS... @TARGET_IDENTITY:REMOTE_FILEPATH ``` Then, to retrieve remote files we use a similar syntax: -```bash +``` ./zscp @TARGET_IDENTITY:REMOTE_FILEPATH LOCAL_FILEPATH ``` Below is a working example of using `zscp` to send a file to a remote machine. In this case the remote username is not the same as my local username. Just like with `scp`, I'll need to supply the username in my command and it will use the same syntax that regular `scp` uses. Here I am `zscp'ing` as username `ubuntu` to the remote computer that is joined to the Ziti Network using the identity named `ziti-tunnel-aws`. -```bash +``` ./zscp local/1.txt ubuntu@ziti-tunnel-aws:remote INFO connection to edge router using token 6c2e8b79-ce8e-483e-a9f8-a930530e706a INFO sent file: /Users/name/local/1.txt ==> /home/ubuntu/remote/1.txt @@ -66,7 +66,7 @@ This is only a basic example on how we can use `zscp` to send a singular file to Just like `zssh`, `zscp` has the same flags to pass in: ssh key, ziti configuration file, service name, and one to toggle debug logging. All the defaults are the same as with `zssh`, thus both `zscp` and `zssh` will work without the `-i` and `-c` flag providing the files exist at the default locations. Refer to \[zitifying-ssh\]\[2\] for instructions on how to use the flags below. -```bash +``` -i, --SshKeyPath string Path to ssh key. default: $HOME/.ssh/id_rsa -c, --ZConfig string Path to ziti config file. default: $HOME/.ziti/zssh.json -d, --debug pass to enable additional debug information @@ -75,7 +75,7 @@ Just like `zssh`, `zscp` has the same flags to pass in: ssh key, ziti configurat In addition to the flags above, `zscp` has a flag to enable recursive copying: -```bash +``` -r, --recursive pass to enable recursive file transfer ``` @@ -83,7 +83,7 @@ To use the recursive flag, you must input a directory into the `LOCAL_FILEPATH` Contents of `big_directory` on local computer: -```bash +``` tree local local └── big_directory @@ -100,7 +100,7 @@ local Here is the command and output: -```bash +``` $ zscp -r big_directory ubuntu@ziti-tunnel-aws:remote INFO connection to edge router using token d6c268ee-e4f5-4836-bd38-2fc1558257aa INFO sent file: /Users/name/local/big_directory/1.txt ==> /home/ubuntu/remote/big_directory/1.txt @@ -113,7 +113,7 @@ INFO sent file: /Users/name/local/big_directory/small_directory3/6.txt ==> /h After `zssh'ing` to the remote machine, we can prove that all files have been transferred to remote device: -```bash +``` ubuntu@IP:~$ tree remote/ remote/ └── big_directory diff --git a/docusaurus/blog/zitification/zitifying-scp/zscp-cheatsheat.md b/docusaurus/blog/zitification/zitifying-scp/zscp-cheatsheat.md index 9a4f9f922..40f2f8fad 100644 --- a/docusaurus/blog/zitification/zitifying-scp/zscp-cheatsheat.md +++ b/docusaurus/blog/zitification/zitifying-scp/zscp-cheatsheat.md @@ -4,7 +4,7 @@ authors: dovholuknf # `zscp` Cheat Sheet -```bash +``` # establish some variables which are used below service_name=zscpSvc client_identity="${service_name}"Client diff --git a/docusaurus/blog/zitification/zitifying-ssh/index.md b/docusaurus/blog/zitification/zitifying-ssh/index.md index be186a1ca..eeab3b9d9 100644 --- a/docusaurus/blog/zitification/zitifying-ssh/index.md +++ b/docusaurus/blog/zitification/zitifying-ssh/index.md @@ -66,7 +66,7 @@ Once you have the executable download, make sure it is named `zssh` and for simp Below you can see me `zssh` from my local machine to the AWS machine secured by `ziti-tunnel`: -```bash +``` ./zssh ubuntu@ziti-tunnel-aws INFO[0000] connection to edge router using token 95c45123-9415-49d6-930a-275ada9ae06f connected. @@ -93,7 +93,7 @@ The `-s/--service` flag is for passing in a different service name other than "z The `-d/--debug` flag outputs additional information to assist you with debugging. For example: -```bash +``` $ ./zssh ubuntu@ziti-tunnel-aws -d INFO[0000] sshKeyPath set to: /home/myUser/.ssh/id_rsa INFO[0000] ZConfig set to: /home/myUser/.ziti/zssh.json @@ -106,7 +106,7 @@ ubuntu@ip-172-31-27-154:~$ Shown above is also one additional piece of information, the remote username. Shown in the example above I have `zssh`ed to an ubuntu image in AWS. When it was provisioned AWS used the username `ubuntu`. In order to `zssh` to this machine I need to tell the remote `sshd` server that I wish to attach as the `ubuntu` user. If your username is the same for your local environment as the remote machine you do not need to specify the username. For example, my local username is `cd` (my initials). When I `zssh` to my dev machine I can simply use `zssh ClintLinux`: -```bash +``` $ ./zssh ClintLinux INFO[0000] connection to edge router using token 909dfb4f-fa83-4f73-af8e-ed251bcd30be connected. diff --git a/docusaurus/blog/zitification/zitifying-ssh/zssh-cheat-sheet.md b/docusaurus/blog/zitification/zitifying-ssh/zssh-cheat-sheet.md index 5d1105ba4..187880750 100644 --- a/docusaurus/blog/zitification/zitifying-ssh/zssh-cheat-sheet.md +++ b/docusaurus/blog/zitification/zitifying-ssh/zssh-cheat-sheet.md @@ -4,7 +4,7 @@ authors: dovholuknf # `zssh` Cheat Sheet -```bash +``` # establish some variables which are used below service_name=zsshSvc client_identity="${service_name}"Client diff --git a/docusaurus/docs/_cli-change-password.md b/docusaurus/docs/_cli-change-password.md index e19edcd21..6f5418103 100644 --- a/docusaurus/docs/_cli-change-password.md +++ b/docusaurus/docs/_cli-change-password.md @@ -2,6 +2,6 @@ If a user identity has a password authenticator (`updb`) then you may change the password with the CLI. -```bash +``` ziti edge update authenticator updb -s ``` diff --git a/docusaurus/docs/_cli-log-levels-and-formats.md b/docusaurus/docs/_cli-log-levels-and-formats.md index e6c3065b6..3bd4e2fe3 100644 --- a/docusaurus/docs/_cli-log-levels-and-formats.md +++ b/docusaurus/docs/_cli-log-levels-and-formats.md @@ -13,7 +13,7 @@ Output from Ziti components comes in three distinct styles. Choose the style of - `json` - a machine-readable format targeting automated processes for log aggregation/searching - `text` - a human-readable format using plain text (no ascii escape codes) -```bash +``` ziti-router run ./router.yml --log-formatter pfxlog ``` @@ -22,7 +22,7 @@ ziti-router run ./router.yml --log-formatter pfxlog By default the Ziti components will log at the `INFO` level. This means that log messages `INFO`, `WARNING`, `ERROR`, and `FATAL` will all be emitted. Ziti components all support verbose logging by adding `--verbose or -v` to the command being executed. Verbose mode will add `DEBUG` log messages. -```bash +``` ziti-controller run ./ctrl.yml --verbose ``` diff --git a/docusaurus/docs/_cli-login.md b/docusaurus/docs/_cli-login.md index 1f425b98d..4b603a492 100644 --- a/docusaurus/docs/_cli-login.md +++ b/docusaurus/docs/_cli-login.md @@ -2,12 +2,12 @@ The `ziti` CLI will help you get a session from the controller's management API. You will be prompted to trust any new server certificates. Your session cache and trust store are managed by the CLI in your home directory. -```bash +``` # implies https://localhost:1280 ziti edge login -u admin -p admin ``` -```bash +``` # implies https:// ziti edge login ziti.example.com:8441 -u admin -p admin ``` diff --git a/docusaurus/docs/guides/Local_Gateway/EdgeRouter.md b/docusaurus/docs/guides/Local_Gateway/EdgeRouter.md index 960aaf454..be6f764ce 100644 --- a/docusaurus/docs/guides/Local_Gateway/EdgeRouter.md +++ b/docusaurus/docs/guides/Local_Gateway/EdgeRouter.md @@ -39,7 +39,7 @@ Please complete the following steps before continue with this demo. **ssh** into your router VM (**local-router**). Retrieve **ziti_router_auto_enroll** to setup your router. -```bash +``` wget https://github.com/netfoundry/ziti_router_auto_enroll/releases/latest/download/ziti_router_auto_enroll.tar.gz tar xf ziti_router_auto_enroll.tar.gz ``` @@ -63,7 +63,7 @@ We are also going to create the router without healthcheck section and metrics, - --disableMetrics ### 2.1.2 Create and Register Router #### 2.1.2.1 Create Router using one command -```bash +``` sudo ./ziti_router_auto_enroll -f -n --controller 68.183.139.122 --controllerFabricPort 8440 --controllerMgmtPort 8441 --adminUser admin --adminPassword Test@123 --disableHealthChecks --disableMetrics --autoTunnelListener --routerName local-router ``` What this command does: @@ -81,7 +81,7 @@ What this command does: An alternative way to register router is creating it on the controller first and then register it on the router VM. Create Router and retrieve JWT on the **controller** -```bash +``` zitiLogin # the followin will create a edge router with tunneler enabled on the controller ziti edge create edge-router local-router -o local-router.jwt -t @@ -89,7 +89,7 @@ cat local-router.jwt ``` Copy the output of "local-router.jwt" and register the router on the **router VM** -```bash +``` sudo ./ziti_router_auto_enroll -f -n --controllerFabricPort 8440 --controllerMgmtPort 8441 --disableHealthChecks --disableMetrics --autoTunnelListener ``` What this command does: @@ -103,7 +103,7 @@ What this command does: You do not have to perform this step if your installation was successful. #### 2.1.3.1 ziti-router service -```bash +``` systemctl status ziti-router ``` @@ -117,7 +117,7 @@ ziggy@local-gw:~$ systemctl status ziti-router ``` #### 2.1.3.2 resolver -```bash +``` resolvectl ``` @@ -137,10 +137,10 @@ Link 2 (ens160) Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 8.8.8.8 DNS Servers: 8.8.8.8 -``` +``` #### 2.1.3.3 Check Router and Identity -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge list edge-routers /opt/ziti/ziti edge list identities @@ -170,7 +170,7 @@ results: 1-3 of 3 ``` ### 2.1.4 setup ufw The following steps turn on the ufw firewall and opens the ports for this demo. -```bash +``` sudo ufw enable sudo ufw allow from any to 172.16.31.173/32 port 53 proto udp sudo ufw allow from any to 172.16.31.173/32 port 22 proto tcp @@ -180,7 +180,7 @@ sudo ufw allow from any to 172.16.31.173/32 port 80 proto tcp We want to add attribute "clients" to the identity associated with the edge router. **You do not need to login again if your token has not expired yet** -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge update identity local-router -a clients ``` @@ -203,7 +203,7 @@ results: 1-3 of 3 **ssh** into your router VM (**remote-router**). Retrieve **ziti_router_auto_enroll** to setup your router automatically. -```bash +``` wget https://github.com/netfoundry/ziti_router_auto_enroll/releases/latest/download/ziti_router_auto_enroll.tar.gz tar xf ziti_router_auto_enroll.tar.gz ``` @@ -214,7 +214,7 @@ We are going to use Router Name: **remote-router** ### 2.2.2 Create and Register Router #### 2.2.2.1 Create Router using one command -```bash +``` sudo ./ziti_router_auto_enroll -f -n --controller 68.183.139.122 --controllerFabricPort 8440 --controllerMgmtPort 8441 --adminUser admin --adminPassword Test@123 --disableHealthChecks --disableMetrics --autoTunnelListener --routerName remote-router ``` @@ -224,7 +224,7 @@ sudo ./ziti_router_auto_enroll -f -n --controller 68.183.139.122 --controllerFab An alternative way to register router is creating it on the controller first and then register it on the router VM. Create Router and retrieve JWT on the **controller** -```bash +``` zitiLogin # the followin will create a edge router with tunneler enabled on the controller ziti edge create edge-router remote-router -o remote-router.jwt -t @@ -232,7 +232,7 @@ cat remote-router.jwt ``` Copy the output of "remote-router.jwt" and register the router on the **router VM** -```bash +``` sudo ./ziti_router_auto_enroll -f -n --controllerFabricPort 8440 --controllerMgmtPort 8441 --disableHealthChecks --disableMetrics --autoTunnelListener ``` @@ -240,19 +240,19 @@ sudo ./ziti_router_auto_enroll -f -n --controllerFabricPort 8440 --controllerMgm You do not have to perform this step if your installation was successful. #### 2.2.3.1 ziti-router service -```bash +``` systemctl status ziti-router ``` **expected output:** The status should show "active (running)" #### 2.2.3.2 resolver -```bash +``` resolvectl ``` **expected output:** The resolver should be set to the IP of the local LAN. #### 2.2.3.3 Check Router and Identity -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge list edge-routers /opt/ziti/ziti edge list identities @@ -282,7 +282,7 @@ results: 1-4 of 4 ### 2.2.3 setup ufw For this demo, we only show the connection initiated from local-tunnel side towards remote-tunnel. The ufw rules below are not needed. If you want to have bidirectional connections, you will need to setup these rules. -```bash +``` sudo ufw enable sudo ufw allow from any to 172.16.240.128/32 port 53 proto udp sudo ufw allow from any to 172.16.240.128/32 port 22 proto tcp @@ -293,7 +293,7 @@ sudo ufw allow from any to 172.16.240.128/32 port 80 proto tcp We want to add attribute "hosts" to the identity associated with the edge router. **You do not need to login again if your token has not expired yet** -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge update identity remote-router -a hosts ``` @@ -316,14 +316,14 @@ results: 1-4 of 4 The Ubuntu Server needs to support **ssh** (port 22) and **http** (port 8000) for our demo. Make sure these ports are open on the firewall. -```bash +``` sudo ufw enable sudo ufw allow from any to 172.16.240.129/32 port 22 proto tcp sudo ufw allow from any to 172.16.240.129/32 port 8000 proto tcp ``` Next, start the webserver. The web server will be listening on the port 8000. -```bash +``` echo "You have reached Remote Web Server." >hello.txt python3 -m http.server ``` @@ -340,7 +340,7 @@ The second change is to setup routing. - We also need to route **172.16.240.129/32** to **local-router**. **172.16.240.129** is IP we intended to intercept and pass through ziti fabric. To do this, open an cmd window as Administrator. -```bash +``` route add 100.64.0.0 mask 255.192.0.0 172.16.31.173 route add 172.16.240.129 mask 255.255.255.255 172.16.31.173 ``` @@ -352,7 +352,7 @@ The service configuration can be done on either the local-router or the remote-r ## 4.1 Create an intercept.v1 config This config is used for local side connection. We are setting up intercept on dns name "mysimpleservice.ziti" -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge create config ssh-intercept-config intercept.v1 '{"protocols": ["tcp"], "addresses": ["mysimpleservice.ziti"], "portRanges": [{"low": 22, "high": 22}]}' ``` @@ -360,7 +360,7 @@ This config is used for local side connection. We are setting up intercept on dn ## 4.2 Create a host.v1 config This config is used for remote side connection. We are setting up the address the remote server can reach. In this demo, We are dropping the traffic off at "172.16.240.129" -```bash +``` /opt/ziti/ziti edge create config ssh-host-config host.v1 '{"address":"172.16.240.129", "protocol":"tcp", "port":22}' ``` If the config command were successfully, you will see two configs by using "list configs" command: @@ -377,7 +377,7 @@ results: 1-2 of 2 ## 4.3 Create ssh Service Now we need to put these two configs into a service. We going to name the service "ssh" and assign an attribute "rtrhosted" -```bash +``` /opt/ziti/ziti edge create service ssh -c ssh-intercept-config,ssh-host-config -a rtrhosted ``` **Check Service** by using "list service" @@ -396,7 +396,7 @@ This step is **optional** if you used quickstart. The service-edge-router-policy But in case you need to add a policy, here is the command to add the service tag we created (rtrhosted) to all routers -```bash +``` /opt/ziti/ziti edge create service-edge-router-policy ssh-serp --edge-router-roles '#all' --service-roles '#rtrhosted' --semantic 'AnyOf' ``` Check your service-edge-router-policy, and make sure the policy name "ssh-serp" is created. The automatically created one is called "allSvcAllRouters". @@ -413,12 +413,12 @@ results: 1-2 of 2 ## 4.5 Create Bind policies We need to specify which identity (in our case, **#hosts**) is going to host the service by setting up a bind service policy -```bash +``` /opt/ziti/ziti edge create service-policy ssh-bind Bind --identity-roles "#hosts" --service-roles '#rtrhosted' --semantic 'AnyOf' ``` ## 4.6 Create Dial policies We also need to specify which identity (in this case, **#clients**) is going to intercept the service by setting up a dial service policy -```bash +``` /opt/ziti/ziti edge create service-policy ssh-dial Dial --identity-roles "#clients" --service-roles '#rtrhosted' --semantic 'AnyOf' ``` If both policies are setup correctly, you should see two service-policies. @@ -448,14 +448,14 @@ In the previous section, we showed how to configure a DNS based intercept via op The service configuration can be done on either the local-router or the remote-router. ## 5.1 Create an intercept.v1 config Create intercept config on IP: 172.16.240.129 and port **80** for http traffic. -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge create config http-intercept-config intercept.v1 '{"protocols": ["tcp"], "addresses": ["172.16.240.129"], "portRanges": [{"low": 80, "high": 80}]}' ``` ## 5.2 Create a host.v1 config Create Host config on IP: 172.16.240.129 and port **8000**. As you can see, we have redirected traffic intended for port 80 (from client) to port 8000 (on the host). -```bash +``` /opt/ziti/ziti edge create config http-host-config host.v1 '{"address":"172.16.240.129", "protocol":"tcp", "port":8000}' ``` @@ -475,7 +475,7 @@ results: 1-4 of 4 ## 5.3 Create http Service Put these two configs into a service. We going to name the service "http" and assign an attribute "rtrhosted" -```bash +``` /opt/ziti/ziti edge create service http -c http-intercept-config,http-host-config -a rtrhosted ``` **Check Service** diff --git a/docusaurus/docs/guides/Local_Gateway/EdgeTunnel.md b/docusaurus/docs/guides/Local_Gateway/EdgeTunnel.md index 298203af5..599b2be97 100644 --- a/docusaurus/docs/guides/Local_Gateway/EdgeTunnel.md +++ b/docusaurus/docs/guides/Local_Gateway/EdgeTunnel.md @@ -36,15 +36,15 @@ Login to your controller and create two identities named **local-tunnel** and ** ssh @68.183.139.122 ``` Then source the environmental file (only need to perform once per login). -```bash +``` source ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env ``` Login to ziti cli. -```bash +``` zitiLogin ``` Create identities and save the enrollment token to files. -```bash +``` ziti edge create identity user local-tunnel -o local-tunnel.jwt ziti edge create identity user remote-tunnel -o remote-tunnel.jwt ``` @@ -61,7 +61,7 @@ root@LocalGWDemoNC:~# ls -l *jwt -rw------- 1 root root 892 Apr 26 20:06 remote-tunnel.jwt ``` **add attribute to the identity**, now we want to update the identities to have some attribute. The local-tunnel has attribute "clients". The remote-tunnel has attribute "hosts". -```bash +``` ziti edge update identity local-tunnel -a clients ziti edge update identity remote-tunnel -a hosts ``` @@ -90,10 +90,10 @@ ziggy@local-tunnel:~$ systemctl status ziti-edge-tunnel Loaded: loaded (/etc/systemd/system/ziti-edge-tunnel.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2023-04-28 18:38:41 UTC; 3 days ago <... output truncated ...> -``` +``` ### 2.2.2 setup ufw The following steps turn on the ufw firewall and opens the ports for this demo. -```bash +``` sudo ufw enable sudo ufw allow from any to 172.16.31.175/32 port 53 proto udp sudo ufw allow from any to 172.16.31.175/32 port 22 proto tcp @@ -101,14 +101,14 @@ sudo ufw allow from any to 172.16.31.175/32 port 80 proto tcp ``` ### 2.2.3 setup forwarding First setup IP forwarding in the Linux system. -```bash +``` echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/01-ipforward.conf >/dev/null sudo sysctl -p /etc/sysctl.d/01-ipforward.conf ``` Second, setup forwarding on the firewall from local interface to the tun interface created by ziti (tun0). Find the local interface first, if you have only one local interface, this command can help you find the name of the interface. -```bash +``` ip -o -4 route show to default | awk '{print $5}' ``` **output** @@ -117,7 +117,7 @@ ziggy@local-tunnel:~$ ip -o -4 route show to default | awk '{print $5}' ens160 ``` Now setup the forwarding on ufw -```bash +``` sudo ufw route allow in on ens160 out on tun0 ``` @@ -126,7 +126,7 @@ sudo ufw route allow in on ens160 out on tun0 Login to your **remote-tunnel** machine/VM. Register the tunneler by using **remote-tunnel.jwt** token with the instructions mentioned in [this section](#221-register-identities). ### 2.3.2 setup ufw For this demo, we only show the connection initiated from local-tunnel side towards remote-tunnel. The ufw rules below are not needed. If you want to have bidirectional connections, you will need to setup these rules. -```bash +``` sudo ufw enable sudo ufw allow from any to 172.16.240.130/32 port 53 proto udp sudo ufw allow from any to 172.16.240.130/32 port 22 proto tcp @@ -139,14 +139,14 @@ sudo ufw allow from any to 172.16.240.130/32 port 80 proto tcp The Ubuntu Server needs to support **ssh** (port 22) and **http** (port 8000) for our demo. Make sure these ports are open on the firewall. -```bash +``` sudo ufw enable sudo ufw allow from any to 172.16.240.129/32 port 22 proto tcp sudo ufw allow from any to 172.16.240.129/32 port 8000 proto tcp ``` Next, start the webserver. The web server will be listening on the port 8000. -```bash +``` echo "You have reached Remote Web Server." >hello.txt python3 -m http.server ``` @@ -163,7 +163,7 @@ The second change is to setup routing. - We also need to route **172.16.240.129/32** to **local-tunnel**. **172.16.240.129** is IP we intended to intercept and pass through ziti fabric. To do this, open an cmd window as Administrator. -```bash +``` route add 100.64.0.0 mask 255.192.0.0 172.16.31.175 route add 172.16.240.129 mask 255.255.255.255 172.16.31.175 ``` @@ -175,7 +175,7 @@ We make all configuration changes on the controller. Login to the controller and ssh @68.183.139.122 ``` Example on how to start CLI with quickstart created controller: -```bash +``` source ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env zitiLogin ``` @@ -183,14 +183,14 @@ zitiLogin ## 4.1 Create an intercept.v1 config This config is used for local side connection. We are setting up intercept on DNS name "mysimpleservice.ziti" -```bash +``` ziti edge create config ssh-intercept-config intercept.v1 '{"protocols": ["tcp"], "addresses": ["mysimpleservice.ziti"], "portRanges": [{"low": 22, "high": 22}]}' ``` ## 4.2 Create a host.v1 config This config is used for remote side connection. We are setting up the address the remote server can reach. In this demo, We are dropping the traffic off at "172.16.240.129" -```bash +``` ziti edge create config ssh-host-config host.v1 '{"address":"172.16.240.129", "protocol":"tcp", "port":22}' ``` If the config command were successfully, you will see two configs by using "list configs" command: @@ -207,7 +207,7 @@ results: 1-2 of 2 ## 4.3 Create ssh Service Now we need to put these two configs into a service. We going to name the service "ssh" and assign an attribute "tun-hosted" -```bash +``` ziti edge create service ssh -c ssh-intercept-config,ssh-host-config -a tun-hosted ``` **Check Service** by using "list service" @@ -225,7 +225,7 @@ results: 1-1 of 1 This step is **optional** if you used quickstart. The service-edge-router-policy already includes "#all" service roles to "#all" edge router roles as displayed on the screen capture below. But in case you need to add a policy, here is the command to add the service tag we created (tun-hosted) to all routers. -```bash +``` ziti edge create service-edge-router-policy ssh-serp --edge-router-roles '#all' --service-roles '#tun-hosted' --semantic 'AnyOf' ``` Check your service-edge-router-policy, and make sure the policy name "ssh-serp" is created. The automatically created one is called "allSvcAllRouters". @@ -241,12 +241,12 @@ results: 1-2 of 2 ``` ## 4.5 Create Bind policies We need to specify which identity (in our case, **#hosts**) is going to host the service by setting up a bind service policy -```bash +``` ziti edge create service-policy ssh-bind Bind --identity-roles "#hosts" --service-roles '#tun-hosted' --semantic 'AnyOf' ``` ## 4.6 Create Dial policies We also need to specify which identity (in this case, **#clients**) is going to intercept the service by setting up a dial service policy -```bash +``` ziti edge create service-policy ssh-dial Dial --identity-roles "#clients" --service-roles '#tun-hosted' --semantic 'AnyOf' ``` If both policies are setup correctly, you should see two service-policies. @@ -302,20 +302,20 @@ We can login to the controller to perform the configurations. ``` ssh @68.183.139.122 ``` -```bash +``` source ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env zitiLogin ``` ## 5.1 Create an intercept.v1 config Create intercept config on IP: 172.16.240.129 and port **80** for http traffic. -```bash +``` ziti edge create config http-intercept-config intercept.v1 '{"protocols": ["tcp"], "addresses": ["172.16.240.129"], "portRanges": [{"low": 80, "high": 80}]}' ``` ## 5.2 Create a host.v1 config Create Host config on IP: 172.16.240.129 and port **8000**. As you can see, we have redirected traffic intended for port 80 (from client) to port 8000 (on the host). -```bash +``` ziti edge create config http-host-config host.v1 '{"address":"172.16.240.129", "protocol":"tcp", "port":8000}' ``` If the command finished successfully, you will see two more configs created, their names start with "http": @@ -334,7 +334,7 @@ results: 1-4 of 4 5.3 Create http Service Put these two configs into a service. We going to name the service "http" and assign an attribute "tun-hosted" -```bash +``` ziti edge create service http -c http-intercept-config,http-host-config -a tun-hosted ``` **Check Service** @@ -365,7 +365,7 @@ Connect to the Windows Client machine, open a web browser. Enter this address (h Create an VM (Ubuntu 22.04) on the public cloud. **ssh** into that machine. Retrieve **ziti_router_auto_enroll** to setup your router. -```bash +``` wget https://github.com/netfoundry/ziti_router_auto_enroll/releases/latest/download/ziti_router_auto_enroll.tar.gz tar xf ziti_router_auto_enroll.tar.gz ``` @@ -385,7 +385,7 @@ Test@123 <--- Controller Passwd We are going to use Router Name: **DemoPublicER** ### A.1.2 Enroll edge-router -```bash +``` sudo ./ziti_router_auto_enroll -f -n --controller 68.183.139.122 --controllerFabricPort 8440 --controllerMgmtPort 8441 --adminUser admin --adminPassword Test@123 --disableHealthChecks --disableMetrics --assumePublic --routerName DemoPublicER ``` Check to make sure ziti-router is running correctly @@ -404,7 +404,7 @@ root@LocalGWDemoER:~# systemctl status ziti-router **expected output:** The status should show "active (running)" Assign the attribute (#public) to the router. Here is how to do it from **the router**. -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge update edge-router DemoPublicER -a public ``` @@ -422,7 +422,7 @@ results: 1-2 of 2 ### A.1.3 setup ufw The following steps turn on the ufw firewall and opens the ports for this demo. -```bash +``` sudo ufw enable sudo ufw allow 22/tcp sudo ufw allow 80/tcp @@ -435,7 +435,7 @@ The edge-router-policy sets up the access point (Edge Routers) to the ziti fabri There are many approaches on how to create policies to suit your need. For example, you may want to create policy for identities on the west coast to connect to ER in west coast. And policy for east coast identities to connect to east coast ER. But fine tuning edge-route-policy is beyond the scope of this demo. Here, we are going to show you a simple policy for all identities. ### A.2.1 edge-router-policy for all identities We will create an edge-router-policy for all identities to connect to public routers. Here is how to do it from the router. -```bash +``` /opt/ziti/ziti edge login 68.183.139.122:8441 -u admin -p Test@123 -y /opt/ziti/ziti edge create edge-router-policy demoEdgeRouterPolicy --edge-router-roles '#public' --identity-roles '#all' ``` diff --git a/docusaurus/docs/guides/Public_Cloud_Deployment/Controller.md b/docusaurus/docs/guides/Public_Cloud_Deployment/Controller.md index 432c635f3..9b9e66797 100644 --- a/docusaurus/docs/guides/Public_Cloud_Deployment/Controller.md +++ b/docusaurus/docs/guides/Public_Cloud_Deployment/Controller.md @@ -315,7 +315,7 @@ You should **Turn on ufw** and **restart the VM** after the security group confi - ufw must be turned on for traffic to get to the VM. - after ufw is enabled, setup **allow** traffic for OpenZiti ports: -```bash +``` sudo ufw enable sudo ufw allow 8440:8443/tcp sudo shutdown -r 0 @@ -358,7 +358,7 @@ Make sure the firewall is active, it should display **Processing all rules** if - Once the VM is created, we can get the IP address (and the DNS name) of the VM from the Virtual machine screen. - Login to the VM by using defined user "username" (default username is azureuser) and the private sshkey: -```bash +``` ssh -i @ or ssh -i @ @@ -372,13 +372,13 @@ Use the DNS name to setup the controller with [Host OpenZiti Anywhere](/docs/lea - Once the VM is created, we can get the IP address (and the DNS name) of the VM from the Instance detail screen. - **NOTE:** DNS name is only available if you enabled **DNS Hostnames** under VPC. - Login to the VM by using user name "ubuntu": -```bash +``` ssh -i ubuntu@ or ssh -i ubuntu@ ``` - export the DNS record -```bash +``` export EXTERNAL_DNS=$(dig +short -x $(curl -s icanhazip.com) | sed "s/.$//") ``` Then follow the [Host OpenZiti Anywhere](/docs/learn/quickstarts/network/hosted/#express-install) guide to setup the controller. @@ -390,7 +390,7 @@ Then follow the [Host OpenZiti Anywhere](/docs/learn/quickstarts/network/hosted/ ![Diagram](/img/public_cloud/GCP-login1.jpg) - export the DNS record -```bash +``` export EXTERNAL_DNS=$(dig +short -x $(curl -s icanhazip.com) | sed "s/.$//") ``` Then follow the [Host OpenZiti Anywhere](/docs/learn/quickstarts/network/hosted/#express-install) guide to setup the controller. @@ -400,7 +400,7 @@ Then follow the [Host OpenZiti Anywhere](/docs/learn/quickstarts/network/hosted/ - Once the VM is created, we can get the IP address of the droplet from the Resources screen. - Login to the VM by using user "root" and IP address: -```bash +``` ssh root@ ``` Then follow the [Host OpenZiti Anywhere](/docs/learn/quickstarts/network/hosted/) to setup the controller. You must replace the EXTERNAL_DNS with the following command before running the quickstart. @@ -413,7 +413,7 @@ This ensures the Controller setup by the quickstart is advertising the external - Once the VM is created, we can get the IP address of the VM from the instance details screen. - Login to the VM by using user name "ubuntu" and the IP address: -```bash +``` ssh -i ubuntu@ ``` @@ -427,12 +427,12 @@ This ensures the Controller setup by the quickstart is advertising the external - Once the VM is created, we can get the IP address of the VM from the Devices screen. - Login to the VM by using user name "ubuntu" and the IP address: -```bash +``` ssh -i ubuntu@ ``` - export the DNS record -```bash +``` export EXTERNAL_DNS=$(dig +short -x $(curl -s icanhazip.com) | sed "s/.$//") ``` Then follow the [Host OpenZiti Anywhere](/docs/learn/quickstarts/network/hosted/#express-install) guide to setup the controller. @@ -454,14 +454,14 @@ To setup npm executables, you can follow [install Node.js guide](https://www.dig For example, this is how to install the version of node needed for ZAC. Setup the repo: -```bash +``` cd ~ curl -sL https://deb.nodesource.com/setup_18.x -o nodesource_setup.sh sudo bash nodesource_setup.sh ``` Install nodejs: -```bash +``` sudo apt install nodejs ``` @@ -475,12 +475,12 @@ Following helpers are needed to complete the guides for router and services. ### 1.5.1 Add Environment Variables Back to the Shell Source the environment variables when you log back in the shell -```bash +``` source ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env ``` If the environment variables are sourced correctly, you can do the following to check: -```bash +``` echo $ZITI_HOME ``` **Output:** @@ -490,22 +490,22 @@ echo $ZITI_HOME ### 1.5.2 Change Ziti edge admin password Find the Current admin edge login password of controller (if you forget the password): -```bash +``` grep "export ZITI_PWD" ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env ``` Or if you have environment variable setup correctly: -```bash +``` echo $ZITI_PWD ``` To update the passwd -```bash +``` ziti edge update authenticator updb -s ``` **Important:** if you change the password, you must update the passwd (ZITI_PWD) in the "~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env" file. ### 1.5.3 Some useful command for the Router ** login the CLI** -```bash +``` zitiLogin ``` diff --git a/docusaurus/docs/guides/Public_Cloud_Deployment/Router.md b/docusaurus/docs/guides/Public_Cloud_Deployment/Router.md index 22c04b051..ebcb7d67c 100644 --- a/docusaurus/docs/guides/Public_Cloud_Deployment/Router.md +++ b/docusaurus/docs/guides/Public_Cloud_Deployment/Router.md @@ -31,7 +31,7 @@ Please follow **[Create a VM section](Controller#11-create-a-vm-to-be-used-as-th - Once the VM is created, we can get the IP address of the VM from the Virtual machine screen. - Login to the VM by using defined user "username" (default username is azureuser) and the private sshkey: -```bash +``` ssh -i @ ``` @@ -40,7 +40,7 @@ ssh -i @ - Once the VM is created, we can get the IP address of the VM from the Instance(s) screen. Login to the VM by using user name "ubuntu": -```bash +``` ssh -i ubuntu@ ``` @@ -53,7 +53,7 @@ ssh -i ubuntu@ - Once the VM is created, get the IP address of the droplet from the Resources screen. Login to the VM by using user "root" and IP address: -```bash +``` ssh root@ ``` @@ -61,7 +61,7 @@ ssh root@ - Once the VM is created, we can get the IP address of the VM from the instance details screen. - Login to the VM by using user name "ubuntu" and the IP address: -```bash +``` ssh -i ubuntu@ ``` @@ -69,21 +69,21 @@ ssh -i ubuntu@ - Once the VM is created, we can get the IP address of the VM from the Devices screen. - Login to the VM by using user name "ubuntu" and the IP address: -```bash +``` ssh -i ubuntu@ ``` ### 2.2.1 apt update -```bash +``` sudo apt update sudo apt upgrade ``` ### 2.2.2 Download ziti_router_auto_enroll binary **ziti_router_auto_enroll** is an easy way to setup your router automatically. -```bash +``` wget https://github.com/netfoundry/ziti_router_auto_enroll/releases/latest/download/ziti_router_auto_enroll.tar.gz tar xf ziti_router_auto_enroll.tar.gz ``` @@ -121,7 +121,7 @@ If you choose to explore these two functionalities, you can remove the options ( ### 2.3.3 Create the Router with link listener Use this procedure to create a Public Router with link listener (but without tunnel). -```bash +``` sudo ./ziti_router_auto_enroll -f -n --controller 68.183.52.206 --controllerFabricPort 8440 --controllerMgmtPort 8441 --adminUser admin --adminPassword Test@123 --assumePublic --disableHealthChecks --disableMetrics --routerName pub-er ``` **output** @@ -218,12 +218,12 @@ Otherwise, this section provides CLI commands to create routers on the controlle **login to controller** login to CLI first -```bash +``` zitiLogin ``` To create an edge router (no tunneler) -```bash +``` ziti edge create edge-router pub-er -o pub-er.jwt ``` **output** @@ -233,7 +233,7 @@ Enrollment expires at 2023-04-07T03:52:03.997Z ``` To create an edge router with tunneler -```bash +``` ziti edge create edge-router pub-er -t -o pub-er.jwt ``` @@ -299,7 +299,7 @@ sudo ./ziti_router_auto_enroll -f -n --controllerFabricPort 8440 --controllerMgm ## 2.5 Auto start the router After enroll the router, a systemd service file is automatically created and enabled. To check the status of the service file, issue the following command: -```bash +``` systemctl status ziti-router ``` **Output** @@ -350,7 +350,7 @@ Current DNS Server: 67.207.67.2 Under the Global DNS servers, it should say something like "67.207.67.2 67.207.67.3" **Now, make changes to the resolver:** -```bash +``` cd /etc/systemd/resolved.conf.d/ rm DigitalOcean.conf sudo ln -s /dev/null DigitalOcean.conf @@ -660,7 +660,7 @@ You should **Turn on ufw** and **restart the VM** after the security group confi - ufw must be turned on for traffic to get to the VM. - after ufw is enabled, setup **allow** traffic for ports: -```bash +``` sudo ufw enable sudo ufw allow 80/tcp sudo ufw allow 443/tcp diff --git a/docusaurus/docs/guides/Public_Cloud_Deployment/Services.md b/docusaurus/docs/guides/Public_Cloud_Deployment/Services.md index ea45929a0..504093fd1 100644 --- a/docusaurus/docs/guides/Public_Cloud_Deployment/Services.md +++ b/docusaurus/docs/guides/Public_Cloud_Deployment/Services.md @@ -33,7 +33,7 @@ Please make sure you can login to your network and see the welcome screen before You will need to login to controller to provision identities and service. Please make sure you are performing the action on the right node. On the controller, before performing the CLI command, you will need to login first: -```bash +``` zitiLogin ``` @@ -128,7 +128,7 @@ Once the identities are created, you can check the identities and download the * #### 3.2.3.2 Create Identity with CLI Create two identities (ingress-tunnel, egress-tunnel) on the **controller**: -```bash +``` ziti edge create identity device ingress-tunnel -o ingress-tunnel.jwt ziti edge create identity device egress-tunnel -o egress-tunnel.jwt ``` @@ -227,7 +227,7 @@ Create the configuration from **MANAGE CONFIGURATIONS** screen. ![Diagram](/img/public_cloud/Services10.png) #### 3.4.1.2 CLI -```bash +``` ziti edge create config t2thostconf host.v1 '{"protocol":"tcp", "address":"127.0.0.1", "port":22}' ``` ### 3.4.2 Create an intercept.v1 config @@ -241,7 +241,7 @@ Check the provisioned configs on the configuration screen: ![Diagram](/img/public_cloud/Services12.png) #### 3.4.2.2 CLI -```bash +``` ziti edge create config t2tintconf intercept.v1 '{"protocols": ["tcp"], "addresses": ["t2tssh.ziti"], "portRanges": [{"low": 22, "high": 22}]}' ``` If the command finished successfully, you will see two configs: @@ -264,7 +264,7 @@ Create service from **Services** menu from **MANAGE EDGE SERVICES** screen. ![Diagram](/img/public_cloud/Services13.png) #### 3.4.3.2 CLI -```bash +``` ziti edge create service t2tssh -c t2tintconf,t2thostconf ``` @@ -291,7 +291,7 @@ Create a **service policy** from **MANAGE SERVICE POLICIES** screen: ![Diagram](/img/public_cloud/Services15-Bind.jpg) #### 3.4.4.2 CLI -```bash +``` ziti edge create service-policy t2tssh.bind Bind --service-roles '@t2tssh' --identity-roles "@egress-tunnel" ``` ### 3.4.5 Create Dial Service policy @@ -305,7 +305,7 @@ We should have two service policies created. The services name should match on t ![Diagram](/img/public_cloud/Services17.jpg) #### 3.4.5.2 CLI -```bash +``` ziti edge create service-policy t2tssh.dial Dial --service-roles '@t2tssh' --identity-roles "@ingress-tunnel" ``` Make sure both policies are setup correctly： @@ -382,7 +382,7 @@ Please refer to [Network Diagram 2](#312-network-diagram-2) for our test setup. #### 3.5.1.1 ZAC ![Diagram](/img/public_cloud/Services20.png) #### 3.5.1.2 CLI -```bash +``` ziti edge create config t2ehostconf host.v1 '{"protocol":"tcp", "address":"127.0.0.1", "port":8080}' ``` ### 3.5.2 Create an intercept.v1 config @@ -394,7 +394,7 @@ And you should have two configs: ![Diagram](/img/public_cloud/Services22.png) #### 3.5.2.2 CLI -```bash +``` ziti edge create config t2eintconf intercept.v1 '{"protocols": ["tcp"], "addresses": ["10.124.0.2"], "portRanges": [{"low": 80, "high": 80}]}' ``` ``` @@ -419,7 +419,7 @@ ziti edge create service t2ehttp -c t2eintconf,t2ehostconf #### 3.5.4.1 ZAC ![Diagram](/img/public_cloud/Services25-Bind.jpg) #### 3.5.4.2 CLI -```bash +``` ziti edge create service-policy t2ehttp.bind Bind --service-roles '@t2ehttp' --identity-roles "@local-er" ``` ### 3.5.5 Create Dial Service policy @@ -431,7 +431,7 @@ Check two service polices: ![Diagram](/img/public_cloud/Services27.jpg) #### 3.5.5.2 CLI -```bash +``` ziti edge create service-policy t2ehttp.dial Dial --service-roles '@t2ehttp' --identity-roles "@egress-tunnel" ``` Make sure both policies are setup correctly： @@ -462,7 +462,7 @@ This is hello from local-er. ``` Then start the http server. -```bash +``` python3 -m http.server 8080 ``` @@ -508,7 +508,7 @@ Used address **127.0.0.1** as host side destination, and port **80** as destinat #### 3.6.2.1 ZAC ![Diagram](/img/public_cloud/Services30.jpg) #### 3.6.2.2 CLI -```bash +``` ziti edge create config e2thostconf host.v1 '{"protocol":"tcp", "address":"127.0.0.1", "port":80}' ``` ### 3.6.3 Create an intercept.v1 config @@ -520,7 +520,7 @@ And you should have two configs: ![Diagram](/img/public_cloud/Services32.jpg) #### 3.6.3.2 CLI -```bash +``` ziti edge create config e2tintconf intercept.v1 '{"protocols": ["tcp"], "addresses": ["11.11.11.11","e2thttp.ziti"], "portRanges": [{"low": 80, "high": 80}]}' ``` ``` @@ -545,7 +545,7 @@ ziti edge create service e2thttp -c e2thostconf,e2tintconf #### 3.6.5.1 ZAC ![Diagram](/img/public_cloud/Services34-Bind.jpg) #### 3.6.5.2 CLI -```bash +``` ziti edge create service-policy e2thttp.bind Bind --service-roles '@e2thttp' --identity-roles "@egress-tunnel" ``` ### 3.6.6 Create Dial Service policy @@ -557,7 +557,7 @@ Check two service polices: ![Diagram](/img/public_cloud/Services36.jpg) #### 3.6.6.2 CLI -```bash +``` ziti edge create service-policy e2thttp.dial Dial --service-roles '@e2thttp' --identity-roles "@local-er" ``` Make sure both policies are setup correctly： @@ -589,7 +589,7 @@ You have reached the "egress-tunnel". ``` Then start the http server. -```bash +``` sudo python3 -m http.server 80 ``` @@ -675,7 +675,7 @@ DNS=10.5.0.4 #local private IP of the ER **NOTE, the IP address should match your Next hop in the route table** Restart the systemd-resolved service -```bash +``` sudo systemctl restart systemd-resolved.service ``` @@ -690,7 +690,7 @@ DNS=10.5.0.4 #local private IP of the ER **NOTE, the IP address should match your Next hop in the route table** Restart the systemd-resolved service -```bash +``` sudo systemctl restart systemd-resolved.service ``` @@ -705,7 +705,7 @@ DNS=10.138.0.2 #local private IP of the local ER **NOTE, the IP address should match your Next hop in the route table** Restart the systemd-resolved service -```bash +``` sudo systemctl restart systemd-resolved.service ``` @@ -720,7 +720,7 @@ DNS=144.126.220.15 ``` Restart the systemd-resolved service -```bash +``` sudo systemctl restart systemd-resolved.service ``` @@ -736,7 +736,7 @@ DNS=10.5.0.4 #local private IP of the ER **NOTE, the IP address should match your "Target Selection" in the route table** Restart the systemd-resolved service -```bash +``` sudo systemctl restart systemd-resolved.service ``` @@ -749,7 +749,7 @@ sudo systemctl restart systemd-resolved.service DNS=169.45.71.226 #Public IP of the ER ``` Restart the systemd-resolved service -```bash +``` sudo systemctl restart systemd-resolved.service ``` diff --git a/docusaurus/docs/guides/kubernetes/workload-tunneling/index.md b/docusaurus/docs/guides/kubernetes/workload-tunneling/index.md index ece82527f..24389f4f0 100644 --- a/docusaurus/docs/guides/kubernetes/workload-tunneling/index.md +++ b/docusaurus/docs/guides/kubernetes/workload-tunneling/index.md @@ -4,7 +4,7 @@ title: Workload Tunneling This guide will help you discover the best strategy and tool for connecting a Kubernetes workload. This overview page links to child pages for each strategy and tool, and a summary of each is provided in the sections below. Click on the chart's outcomes to see the corresponding documentation. -```mermaid +``` graph TB; A{Pod connects to an
OpenZiti Service?} A -- Yes --> B{Intercept at pod or
node level?} diff --git a/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-daemonset.md b/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-daemonset.md index d8d60e62a..e7bf453ec 100644 --- a/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-daemonset.md +++ b/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-daemonset.md @@ -10,7 +10,7 @@ This [daemonset manifest](https://get.openziti.io/tun/docker/ziti-tun-daemonset. The default nameserver address is `100.64.0.2`, but containers don't automatically use it until you configure cluster DNS. CoreDNS doesn't currently have a fallthrough mechanism, but you can use conventional names for your OpenZiti services' like `*.ziti`, and configure CoreDNS to forward queries that match that namespace to the OpenZiti nameserver. -```yaml +``` apiVersion: v1 data: Corefile: | @@ -41,7 +41,7 @@ data: Some Kubernetes distributions provide a method for persisting CoreDNS configuration, e.g., the `import` plugin. A common pattern is for the CoreDNS pod to mount a configmap with a particular name in the `kube-system` namespace, e.g., `coredns-custom` on a directory like `/etc/coredns/custom/` with an aligned statement in the Corefile like `import /etc/coredns/custom/*.server`. The CoreDNS customization configmap then has contents like: -```yaml +``` apiVersion: v1 kind: ConfigMap metadata: diff --git a/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-sidecar.md b/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-sidecar.md index cc3bf2d92..475263c71 100644 --- a/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-sidecar.md +++ b/docusaurus/docs/guides/kubernetes/workload-tunneling/kubernetes-sidecar.md @@ -29,14 +29,14 @@ This guide will re-use the Ziti service "testapi-service", a REST API demo serve 1. We will create a new identity for our client app with the correct role to grant access to the Ziti service. - ```bash + ``` ziti edge create identity device sidecar-client \ --jwt-output-file /tmp/sidecar-client.jwt --role-attributes testapi-clients ``` 1. Enroll the identity. - ```bash + ``` ziti edge enroll /tmp/sidecar-client.jwt ``` @@ -44,7 +44,7 @@ This guide will re-use the Ziti service "testapi-service", a REST API demo serve You can restore the KUBECONFIG context from the Minikube quickstart like this if you switched contexts after running it. -```bash +``` minikube --profile miniziti update-context ``` @@ -52,7 +52,7 @@ minikube --profile miniziti update-context The `ziti-tunnel` sidecar will access its identity by mounting a Kubernetes secret in the container. -```bash +``` kubectl create secret generic "sidecar-client-identity" \ --from-file=/tmp/sidecar-client.json ``` @@ -66,13 +66,13 @@ demonstration, the client application is `wget`. Our Pod sends a `POST` request You need to update the deployment manifest with the CoreDNS CLUSTER-IP address before you deploy. This is because the `ziti-tunnel` sidecar provides an override nameserver for the pod, so we need to inject the CoreDNS nameserver as fallback resolver for non-Ziti names because `ziti-tunnel` itself will not answer queries for non-Ziti DNS names. - ```bash + ``` kubectl --namespace kube-system get services kube-dns ``` 1. Save the following to a file named /tmp/sidecar-demo.yaml. - ```yaml + ``` # /tmp/sidecar-demo.yaml apiVersion: apps/v1 kind: Deployment @@ -142,7 +142,7 @@ demonstration, the client application is `wget`. Our Pod sends a `POST` request 1. Once the manifest YAML is saved, we can deploy the pod with `kubectl` - ```bash + ``` kubectl apply -f /tmp/sidecar-demo.yaml ``` @@ -150,14 +150,14 @@ demonstration, the client application is `wget`. Our Pod sends a `POST` request 1. Find the name of the pod that Kubernetes deployed for us. - ```bash + ``` $ kubectl get pods ziti-tunnel-sidecar-demo-749c476989-6wpfn 1/1 Running 0 42s ``` 1. Tail the logs for the "testclient" container inside the pod. The first few attempts didn't get a reply because the tunnel was starting up. - ```bash + ``` $ kubectl logs --follow ziti-tunnel-sidecar-demo-749c476989-6wpfn --container testclient + wget --quiet --output-document=- --post-data ziti=awesome http://testapi.ziti/post + jq .data diff --git a/docusaurus/docs/guides/securing-apis/aks-api-with-nginx-ziti-module.md b/docusaurus/docs/guides/securing-apis/aks-api-with-nginx-ziti-module.md index 56f074a64..57ab53091 100644 --- a/docusaurus/docs/guides/securing-apis/aks-api-with-nginx-ziti-module.md +++ b/docusaurus/docs/guides/securing-apis/aks-api-with-nginx-ziti-module.md @@ -58,7 +58,7 @@ Currently, configmaps have a binary file limit of 1MB and the size of the ngx-zi :::tip One way to update the build is to add to the Dockerfile (`build/Dockerfile`) this snippet of code under the common section, i.e. `FROM ${BUILD_OS} as common` -```shell +``` # copy ziti module COPY ./ngx_ziti_module.so /usr/lib/nginx/modules @@ -66,13 +66,13 @@ COPY ./ngx_ziti_module.so /usr/lib/nginx/modules Also, need to add the following package `libc6` to the debian build in the same Dockerfile, i.e. `FROM nginx:1.23.3 AS debian`. Did not try the alpine build but the assumption is that would be the same. -```shell +``` && apt-get install --no-install-recommends --no-install-suggests -y libcap2-bin libc6 \ ``` Lastly, if you don't want the image name to have a postfix of`SNAPSHOT...` , comment it out in `Makefile`. -```shell +``` VERSION = $(GIT_TAG)##-SNAPSHOT-$(GIT_COMMIT_SHORT) ``` @@ -82,7 +82,7 @@ Once the image is built, upload it to your container registry. You will need it :::note if you don't have time to build your own, can use our test image based on debian 11 and nginx v1.23.3 -```shell +``` set { name = "controller.image.repository" value = "docker.io/elblag91/ziti-nginx-ingress" @@ -112,7 +112,7 @@ export ARM_TENANT_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Run terraform plan. :::info Steps -```shell +``` git clone https://github.com/dariuszSki/openziti-nginx-ingress-terraform.git cd openziti-nginx-ingress-terraform/tf-provider terraform init @@ -122,7 +122,7 @@ terraform apply "aks" Once completed, grab `cluster_public_fqdn` under `outputs` as shown in the example below. -```shell +``` cluster_name = "akssandeastus" cluster_private_fqdn = "" cluster_public_fqdn = "akssand-2ift1yqr.hcp.eastus.azmk8s.io" @@ -136,7 +136,7 @@ If you are using your own deployment method, here are some configuration details - ***Ziti Nginx Module Identity*** -```shell +``` nginx_ziti_identity = "${file("./server-nginx.json")}" resource "kubernetes_secret" "ziti-identity" { metadata { @@ -151,7 +151,7 @@ resource "kubernetes_secret" "ziti-identity" { - ***Image Reference*** -```shell +``` set { name = "controller.image.repository" value = "docker.io/elblag91/ziti-nginx-ingress" @@ -169,7 +169,7 @@ Services are commented out until they are created. Then, terraform plan can be r ::: -```shell +``` controller: service: create: false @@ -191,7 +191,7 @@ controller: - ***Volume section and path to secrets. Added openziti.io folder.*** -```bash +``` volumes: - name: "ziti-nginx-files" projected: @@ -215,13 +215,13 @@ controller: - ***Create configs*** -```shell +``` ziti edge create config k8s-api-intercept.v1 intercept.v1 "{\"protocols\": [\"tcp\"], \"addresses\": [\"akssand-2ift1yqr.hcp.eastus.azmk8s.io\"],\"portRanges\": [{\"low\": 443,\"high\": 443}]}" ``` - ***Create Service*** -```shell +``` ziti edge create service k8s-api --configs "k8s-api-intercept.v1" --role-attributes "service-nginx" ``` @@ -229,7 +229,7 @@ ziti edge create service k8s-api --configs "k8s-api-intercept.v1" --role-attribu - ***Create Service Bind Policy*** -```shell +``` ziti edge create service-policy k8s-api-bind Bind --semantic "AnyOf" --identity-roles "#servers" --service-roles "#service-nginx" ``` @@ -237,7 +237,7 @@ ziti edge create service-policy k8s-api-bind Bind --semantic "AnyOf" --identity- - ***Create Service Dial Policy*** -```shell +``` ziti edge create service-policy k8s-api-dial Dial --semantic "AnyOf" --identity-roles "#clients" --service-roles "#service-nginx" ``` @@ -247,7 +247,7 @@ ziti edge create service-policy k8s-api-dial Dial --semantic "AnyOf" --identity- Uncomment `ziti identity1` block in `resource.helm_release.nginx-ingress` -```shell +``` config: entries: main-snippets: | @@ -270,11 +270,11 @@ Need to disable ZDE for this network before the next step, so the nginx updates - ***Re-run terraform*** -```bash +``` terraform plan -var include_aks_nginx=true -out aks ``` -```bash +``` terraform apply "aks" ``` @@ -283,7 +283,7 @@ terraform apply "aks" :::tip If the terraform was run, the kube-config file was created in the tf root directory. One can also use `az cli` to get the kube config downloaded. -```shell +``` # Configure your local kube configuration file using azure cli az login # if not already logged in # Windows WSL @@ -296,26 +296,26 @@ az aks get-credentials --resource-group $RG_NAME --name {cluster_name} --subscri - ***Check context in the kubectl config file*** -```shell +``` kubectl config get-contexts ``` `Expected Output` -```shell +``` CURRENT NAME CLUSTER AUTHINFO NAMESPACE * akssandeastus akssandeastus clusterUser_nginx_module_rg_eastus_akssandeastus ``` - ***Let's check the status of nodes in the cluster.*** -```shell +``` kubectl get nodes ``` `Expected Output` -```shell +``` NAME STATUS ROLES AGE VERSION aks-agentpool-20887740-vmss000000 Ready agent 151m v1.24.9 aks-agentpool-20887740-vmss000001 Ready agent 151m v1.24.9 @@ -323,13 +323,13 @@ aks-agentpool-20887740-vmss000001 Ready agent 151m v1.24.9 - ***List cluster info*** -```shell +``` kubectl cluster-info ``` `Expected Output` -```shell +``` Kubernetes control plane is running at https://akssand-2ift1yqr.hcp.eastus.azmk8s.io:443 CoreDNS is running at https://akssand-2ift1yqr.hcp.eastus.azmk8s.io:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://akssand-2ift1yqr.hcp.eastus.azmk8s.io:443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy @@ -339,13 +339,13 @@ To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. - ***List pods*** -```shell +``` kubectl get pods --all-namespaces ``` `Expected Output` -```shell +``` NAMESPACE NAME READY STATUS RESTARTS AGE default nginx-ingress-nginx-ingress-7ffd564557-ngt69 1/1 Running 0 134m kube-system azure-ip-masq-agent-9scx6 1/1 Running 0 166m @@ -369,13 +369,13 @@ kube-system metrics-server-8655f897d8-tnpzt 2/2 Running 0 - ***List services*** -```shell +``` kubectl get services --all-namespaces ``` `Expected Output` -```shell +``` NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 10.0.0.1 443/TCP 169m kube-system kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 169m @@ -390,11 +390,11 @@ At this point the public access is still available even though the API Kubectl q Pass the following variable to only allow 192.168.1.1/32 source IP to essentially disable Public Access. -```shell +``` terraform plan -var include_aks_nginx=true -var authorized_source_ip_list=[\"192.168.1.1/32\"] -out aks ``` -```shell +``` terraform apply "aks" ``` @@ -406,16 +406,16 @@ Retest with ZDE enabled and disabled for this network. Run terraform to open up the AKS API to public before deleting AKS resources, so you dont get locked out. ::: -```shell +``` terraform plan -var include_aks_nginx=true -var authorized_source_ip_list=[\"0.0.0.0/0\"] -out aks ``` -```shell +``` terraform apply "aks" ``` Delete all resources -```shell +``` terraform plan --destroy -var include_aks_nginx=true -out aks ``` \ No newline at end of file diff --git a/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointInitialization.md b/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointInitialization.md index fc9a37582..6cae3001c 100644 --- a/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointInitialization.md +++ b/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointInitialization.md @@ -1,6 +1,6 @@ # Endpoint Initialization -```mermaid +``` sequenceDiagram title Endpoint Initialization diff --git a/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointRegistration.md b/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointRegistration.md index 85a06ce06..4c1ea7f98 100644 --- a/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointRegistration.md +++ b/docusaurus/docs/learn/core-concepts/clients/process-sequences/EndpointRegistration.md @@ -1,6 +1,6 @@ # Endpoint Registration -```mermaid +``` sequenceDiagram title Ziti Nde Registration Flow autonumber 1 diff --git a/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md b/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md index 07852a98a..49436a1a9 100644 --- a/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md +++ b/docusaurus/docs/learn/core-concepts/clients/process-sequences/ServiceDial.md @@ -1,6 +1,6 @@ # Service Dial -```mermaid +``` sequenceDiagram title Service Dial (TCP) diff --git a/docusaurus/docs/learn/core-concepts/config-store/config-type-host-v1.md b/docusaurus/docs/learn/core-concepts/config-store/config-type-host-v1.md index dd125c9a3..88f43c766 100644 --- a/docusaurus/docs/learn/core-concepts/config-store/config-type-host-v1.md +++ b/docusaurus/docs/learn/core-concepts/config-store/config-type-host-v1.md @@ -6,7 +6,7 @@ A Config of Config Type `host.v1` configures a hosting Ziti tunneler to forward This Config forwards Ziti service traffic to a server known as `tcp:localhost:54321`. The server must be reachable at that destination from the network perspective of the device where the Ziti tunneler is running. -```json +``` { "address": "localhost", "port": 54321, @@ -16,7 +16,7 @@ This Config forwards Ziti service traffic to a server known as `tcp:localhost:54 Rather than a static destination port, this Config forwards the Ziti service traffic to the same TCP port that the initiating client was connecting to as long as it falls within the range of allowed ports. -```json +``` { "address": "localhost", "forwardPort": true, @@ -27,7 +27,7 @@ Rather than a static destination port, this Config forwards the Ziti service tra Rather than a static destination address, this Config forwards the Ziti service traffic to the same address that the initiating client was connecting to as long as it is in the list of allowed addresses. -```json +``` { "forwardAddress": true, "allowedAddresses": [ diff --git a/docusaurus/docs/learn/core-concepts/config-store/config-type-intercept-v1.md b/docusaurus/docs/learn/core-concepts/config-store/config-type-intercept-v1.md index 26bc55fb0..410e8c8f7 100644 --- a/docusaurus/docs/learn/core-concepts/config-store/config-type-intercept-v1.md +++ b/docusaurus/docs/learn/core-concepts/config-store/config-type-intercept-v1.md @@ -7,7 +7,7 @@ A Config of Config Type `intercept.v1` configures an intercepting Ziti tunneler This Config instructs the tunneler to intercept any outgoing traffic with destination `tcp:acme.example.ziti:5000`. An intercepting tunneler provides a DNS nameserver that resolves authorized Ziti services' domain names. -```json +``` { "protocols": [ "tcp" @@ -26,7 +26,7 @@ This Config instructs the tunneler to intercept any outgoing traffic with destin This Config has not only a Ziti domain name destination `acme.ziti` for which traffic is intercepted, but also a wildcard domain and an IP subnet. Additionally, there is a range of destination ports for which all packets will be intercepted if their destination address also matches. -```json +``` { "addresses": [ "acme.ziti", diff --git a/docusaurus/docs/learn/core-concepts/config-store/managing.md b/docusaurus/docs/learn/core-concepts/config-store/managing.md index f264e01b3..b97c391d6 100644 --- a/docusaurus/docs/learn/core-concepts/config-store/managing.md +++ b/docusaurus/docs/learn/core-concepts/config-store/managing.md @@ -3,7 +3,7 @@ ## Managing Configurations Here is a JSON schema, modeled on the tunneler client configuration. -```json +``` { "$id": "http://myapp.company.com/schemas/myapp.v1.config.json", "additionalProperties": false, diff --git a/docusaurus/docs/learn/core-concepts/identities/20-enrolling.md b/docusaurus/docs/learn/core-concepts/identities/20-enrolling.md index 3204c72af..30086cbda 100644 --- a/docusaurus/docs/learn/core-concepts/identities/20-enrolling.md +++ b/docusaurus/docs/learn/core-concepts/identities/20-enrolling.md @@ -29,7 +29,7 @@ Follow these steps to enroll an identity with a one-time token: **Example Usage:** -```bash +``` ziti edge enroll \ --jwt ${jwt_file} \ --out ${identity_config_file} @@ -45,12 +45,12 @@ confident you understand the risks involved in doing so. **Example Usage for `ziti-edge-tunnel` CLI** -```bash +``` # enroll from a token file ./ziti-edge-tunnel enroll --jwt ./myTunneler.jwt --identity ./myTunneler.json ``` -```bash +``` # enroll from stdin ./ziti-edge-tunnel enroll --jwt - --identity ./myTunneler.json < ./myTunneler.jwt ``` @@ -69,7 +69,7 @@ Follow these steps to enroll a 3rd Party CA - one-time token identity: **Example Usage:** -```bash +``` ziti edge enroll \ --cert ${user_certificate} \ --key ${user_private_key} \ @@ -95,7 +95,7 @@ the fully qualified address of the Ziti Controller api and `${id}` represents th **Example Usage:** -```bash +``` ziti edge enroll \ --cert ${user_certificate} \ --key ${user_private_key} \ diff --git a/docusaurus/docs/learn/core-concepts/metrics/20-file.mdx b/docusaurus/docs/learn/core-concepts/metrics/20-file.mdx index 0f13b59de..7a2adb323 100644 --- a/docusaurus/docs/learn/core-concepts/metrics/20-file.mdx +++ b/docusaurus/docs/learn/core-concepts/metrics/20-file.mdx @@ -14,7 +14,7 @@ The reporting interval is defined in the `metrics.reportInterval` property. Whil Example: -```yaml +``` metrics: reportInterval: 20s ``` @@ -23,7 +23,7 @@ Routers support an additional configuration parameter `MessageQueueSize` which i Example: -```yaml +``` metrics: reportInterval: 20s messageQueueSize: 20 // Default 10 @@ -53,7 +53,7 @@ The subscription has three components ##### Example: -```yaml +``` events: allControllerMetrics: subscriptions: @@ -89,7 +89,7 @@ For example, `name-2022-06-07T18-50-44.568.log` Write 100mb files, saving 2 of them. -```yaml +``` handler: type: file format: json @@ -103,7 +103,7 @@ Write 100mb files, saving 2 of them. Controller configuration file: -```yaml +``` metrics: reportInterval: 20s @@ -135,7 +135,7 @@ events: Router configuration files: -```yaml +``` metrics: reportInterval: 20s ``` @@ -144,7 +144,7 @@ metrics: ### intValue -```json +``` { "metric_type": "intValue", "namespace": "metrics", @@ -164,7 +164,7 @@ metrics: ### Histogram -```json +``` { "metric_type": "histogram", "namespace": "metrics", @@ -196,7 +196,7 @@ metrics: ### Timer -```json +``` { "metric_type": "timer", "namespace": "metrics", diff --git a/docusaurus/docs/learn/core-concepts/metrics/30-inspect.md b/docusaurus/docs/learn/core-concepts/metrics/30-inspect.md index aed5629e4..3baeb16af 100644 --- a/docusaurus/docs/learn/core-concepts/metrics/30-inspect.md +++ b/docusaurus/docs/learn/core-concepts/metrics/30-inspect.md @@ -8,7 +8,7 @@ The inspections framework is part of the fabric API, hosted by the controller. T The Ziti fabric CLI has support for the inspect command built in. Here's an example: -```bash +``` ziti fabric inspect '.*' metrics:json ``` diff --git a/docusaurus/docs/learn/core-concepts/metrics/40-prometheus.md b/docusaurus/docs/learn/core-concepts/metrics/40-prometheus.md index b8d9a4d54..4f6c1b9e7 100644 --- a/docusaurus/docs/learn/core-concepts/metrics/40-prometheus.md +++ b/docusaurus/docs/learn/core-concepts/metrics/40-prometheus.md @@ -16,7 +16,7 @@ The Prometheus metrics api is not bound to any interface by default. The metrics The metric api can be configured to listen on its own combination of network interface and port by adding a new section under the `web` configuration -```yaml +``` web # Binding for other Ziti APIs - name: apis @@ -68,7 +68,7 @@ web The metrics binding can be added to an existing listener in the controller. -```yaml +``` web -name: apis bindpoints: @@ -92,7 +92,7 @@ The certificate is completely stand-alone - it does not need to be signed by Zit The configuration is added as an option in the metrics binding. The file must be an x509 certificate. -```yaml +``` - binding: metrics options: { scrapeCert: "/etc/prometheus/prom-client.crt" @@ -105,7 +105,7 @@ OpenZiti can export timestamps in the Prometheus metrics. These timestamps can b Timestamps are disabled by default, and can be enabled by setting a the `includeTimestamps` option to `true` in the metrics binding: -```yaml +``` web -name: apis bindpoints: @@ -133,7 +133,7 @@ Prometheus will silently discard metrics that are older than five minutes. The `/metrics` api requires TLS configuration in Prometheus. The Prometheus scrape config must have the ziti web public key, or be configured to ignore private keys. -```yaml +``` - job_name: ziti scheme: https metrics_path: /metrics @@ -153,7 +153,7 @@ The `/metrics` api requires TLS configuration in Prometheus. The Prometheus scra It's a good idea to have metrics protected by a certificate to prevent nefarious actors from pulling metrics about your network. The Prometheus scrape configuration can be configured with a keystore for this purpose: -```yaml +``` - job_name: ziti scheme: https metrics_path: /metrics @@ -182,7 +182,7 @@ In this example you will: #### Create a cert for metric scraping -```bash +``` # Create the certificate and signing request openssl req -new -newkey rsa:2048 -nodes -keyout prom-client.key -out prom-client.csr @@ -202,7 +202,7 @@ Best practices is to use a separate metrics listener that is only accessible fro Add this text to the `web` section of your network controller configuration file -```yaml +``` - name: metrics-localhost bindPoints: - interface: 127.0.0.1:2112 @@ -219,7 +219,7 @@ Add this text to the `web` section of your network controller configuration file I use `curl` to test my keys when I set up metrics. If Ziti is configured to bind metrics to `127.0.0.1:2112` then curl command will be: -```bash +``` curl -i -k --cert /path/to/prom-client.crt --key /path/to/prom-client.key https://127.0.0.1:2112/metrics ``` @@ -238,7 +238,7 @@ The key is added to Prometheus by referencing the crt and key files from the Zit Your scrape config will look something like this: -```yaml +``` global: scrape_interval: 10s scrape_timeout: 10s diff --git a/docusaurus/docs/learn/core-concepts/metrics/80-sequence-diagram.md b/docusaurus/docs/learn/core-concepts/metrics/80-sequence-diagram.md index 6bbb33cd0..730975c5a 100644 --- a/docusaurus/docs/learn/core-concepts/metrics/80-sequence-diagram.md +++ b/docusaurus/docs/learn/core-concepts/metrics/80-sequence-diagram.md @@ -2,7 +2,7 @@ OpenZiti systems provide a wide range of metrics for the monitoring of the network services, endpoints, and processes. Some of the various metrics are visualized below to understand where they fall and what they measure in a network instance. The bulk of the remaining metrics are measuring processes within the control plane, rather than network operation. -```mermaid +``` sequenceDiagram title Metrics diff --git a/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md b/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md index 780792ae0..679ebd420 100644 --- a/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md +++ b/docusaurus/docs/learn/core-concepts/security/SessionsAndConnections.md @@ -6,7 +6,7 @@ sidebar_label: Session Diagram OpenZiti has a number of different connection and session types. It is important to understand the different scopes and uses of these connections in working with the project, developing, operating, and most importantly, troubleshooting. -```mermaid +``` sequenceDiagram title Ziti Sessions and Connections diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/10-third-party-cas.md b/docusaurus/docs/learn/core-concepts/security/authentication/10-third-party-cas.md index 4d39819e5..fb0c26ed9 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/10-third-party-cas.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/10-third-party-cas.md @@ -106,7 +106,7 @@ The fields under `externalIdClaims` is as follows: - `index` - should multiple values still be available after `location`, `matcher,` and `parser` processing the integer value here will be used from the set #### CA Create/Update REST API -```json +``` { "name": "myCA", "certPem": "—–BEGIN CERTIFICATE—–\nMIIDdTCCAHMU...\n—–END CERTIFICATE—–", diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/20-api-session-certificates.md b/docusaurus/docs/learn/core-concepts/security/authentication/20-api-session-certificates.md index f8cf6219a..26549f951 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/20-api-session-certificates.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/20-api-session-certificates.md @@ -26,7 +26,7 @@ Sensitive fields such as key usage will be ignored. Additional Ziti-specific SAN may be added. ### Request Payload -```json +``` { "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIICij...\n-----END CERTIFICATE REQUEST-----" } @@ -34,7 +34,7 @@ may be added. ### Response Payload -```json +``` { "data": { "_links": { diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/30-authentication-policies.md b/docusaurus/docs/learn/core-concepts/security/authentication/30-authentication-policies.md index 6ed274fac..f309327c8 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/30-authentication-policies.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/30-authentication-policies.md @@ -8,7 +8,7 @@ policy is not specified. Example: Authentication Policy -```json +``` { "createdAt": "2022-05-20T14:02:53.359Z", "id": "default", diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/40-certificate-management.md b/docusaurus/docs/learn/core-concepts/security/authentication/40-certificate-management.md index afe0ae786..7969a863c 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/40-certificate-management.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/40-certificate-management.md @@ -31,7 +31,7 @@ must be PEM encoded. #### Request `POST edge/client/v1/current-identity/authenticators/{id}/extend` -```json +``` { "clientCertCsr": "-----BEGIN NEW CERTIFICATE REQUEST-----\n..." } @@ -40,7 +40,7 @@ must be PEM encoded. #### Response: A new CA bundle and client certificate will be returned PEM encoded. -```json +``` { "data": { "ca": "-----BEGIN CERTIFICATE-----\nMIICZTCCAeygAwIBAgIUOoTKiY", diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/5-password-management.md b/docusaurus/docs/learn/core-concepts/security/authentication/5-password-management.md index eecaa1619..f1c3f2465 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/5-password-management.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/5-password-management.md @@ -17,7 +17,7 @@ Passwords may be reset via the [Edge Management API](docs/reference/developer/ap `POST /edge/management/v1/authenticators/` -```json +``` { "password": "" } @@ -36,7 +36,7 @@ Passwords may be reset via the [Edge Management API](/docs/reference/developer/a `POST /edge/client/v1/current-identity/authenticators/` -```json +``` { "password": "" } diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/50-external-jwt-signers.md b/docusaurus/docs/learn/core-concepts/security/authentication/50-external-jwt-signers.md index 8be496765..8d01e8296 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/50-external-jwt-signers.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/50-external-jwt-signers.md @@ -54,7 +54,7 @@ An External JWT Signer that uses a private `email` claim and matches on `externa be created as follows: `POST /edge/management/v1/ext-jwt-signers` -```json +``` { "name": "My External JWT Signer", "enabled": true, @@ -70,7 +70,7 @@ An External JWT Signer that uses the `sub` claim and matches on `id` with a x509 be created as follows: `POST /edge/management/v1/ext-jwt-signers` -```json +``` { "name": "My External JWT Signer", "enabled": true, @@ -90,7 +90,7 @@ to initiate client authentication to the target identity provider. Example Client External JWT Signer response: `GET /edge/client/v1/external-jwt-signers` -```json +``` { "data": [ { diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md b/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md index 8f2c1cfa7..453368954 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/60-identities.md @@ -20,7 +20,7 @@ a Ziti Network. This diagram does not show all entities, simply the ones tied cl the Role Attributes on an Identity are used by selectors defined on policies to act on the identity. However, the policies and selectors are not modeled here. -```mermaid +``` erDiagram Identity ||..o{ API-Session : has API-Session ||..o{ Session : has @@ -59,7 +59,7 @@ Note: This identity will not be able to authenticate It is currently not possible to create and identity without an enrollment option through the CLI. It can be completed by creating and identity then deleting the default certificate enrollment. -```bash +``` ziti edge create identity [device|service|user] ziti edge delete enrollment where "identity=" ``` @@ -68,7 +68,7 @@ ziti edge delete enrollment where "identity=" `POST /edge/management/v1/identities` -```json +``` { "name": "Roger Wilco", "isAdmin": false @@ -86,7 +86,7 @@ Note: This identity will be using the default [authentication policy](./auth) wh #### Edge Management API `POST /edge/management/v1/identities` -```json +``` { "name": "Roger Wilco", "isAdmin": false, @@ -106,7 +106,7 @@ It is currently not possible to create identities with a 3rd party certificate e #### Edge Management API `POST /edge/management/v1/identities` -```json +``` { "name": "Roger Wilco", "isAdmin": false, @@ -126,7 +126,7 @@ Note: This identity will be using the default [authentication policy](./auth) wh #### Edge Management API `POST /edge/management/v1/identities` -```json +``` { "name": "Roger Wilco", "isAdmin": false, @@ -147,7 +147,7 @@ must be defined that allows the identity to authenticate with that signer. #### Edge Management API `POST /edge/management/v1/identities` -```json +``` { "name": "Roger Wilco", "isAdmin": false, diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/70-totp.md b/docusaurus/docs/learn/core-concepts/security/authentication/70-totp.md index a008fa96f..df8353ff1 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/70-totp.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/70-totp.md @@ -45,7 +45,7 @@ Enrollment status can be checked by the client themselves through the following #### Responses: If enrolled: `HTTP 200 ok` -```json +``` { "isVerified": true } @@ -53,7 +53,7 @@ If enrolled: If enrollment started: `HTTP 200 ok` -```json +``` { "isVerified": true, "recoveryCodes": ["code1", "..."], @@ -86,7 +86,7 @@ Enrolment is completed by verifying the secret has been received by providing a codes are not treated as a valid value. `POST /edge/client/v1/current-identity/mfa/verify` -```json +``` { "code": "" } @@ -104,7 +104,7 @@ from their account as long as they have access to a recovery code or TOPT code. #### Client Removal `DELETE /edge/client/v1/current-identity/mfa` -```json +``` { "code": "" } @@ -120,7 +120,7 @@ from their account as long as they have access to a recovery code or TOPT code. At any time the current valid list of recovery codes may be viewed by the client by issuing the following request: `GET /edge/client/v1/current-identity/mfa/recovery-codes` -```json +``` { "code": "" } @@ -132,7 +132,7 @@ At any time the current valid list of recovery codes may be replaced by the clie `POST /edge/client/v1/current-identity/mfa/recovery-codes` -```json +``` { "code": "" } diff --git a/docusaurus/docs/learn/core-concepts/security/authentication/auth.md b/docusaurus/docs/learn/core-concepts/security/authentication/auth.md index ba5383389..e7096d9f3 100644 --- a/docusaurus/docs/learn/core-concepts/security/authentication/auth.md +++ b/docusaurus/docs/learn/core-concepts/security/authentication/auth.md @@ -15,7 +15,7 @@ or the Ziti [Edge Management API](docs/reference/developer/api/02-edge-managemen Below is diagram showing initial authentication for some client. The same model is used between the [Edge Client API](docs/reference/developer/api/01-edge-client-reference.mdx) and [Edge Management API](docs/reference/developer/api/02-edge-management-reference.mdx). -```mermaid +``` graph TD A[Unauthenticated] -->|Submit Primary Credentials| B{Valid?} B --> C[No] --> A @@ -153,7 +153,7 @@ Similar to JWT primary authentication, a valid JWT must be present in the `Authe `POST /edge/client/v1/authenticate?method=password` -```json +``` { "username": "my-name", "password": "my-password" @@ -166,7 +166,7 @@ Note: The TLS connection to the controller MUST use a valid client certificate `POST /edge/management/v1/authenticate?method=cert` -```json +``` {} ``` @@ -175,7 +175,7 @@ Note: The TLS connection to the controller MUST use a valid client certificate `POST /edge/client/v1/authenticate?method=ext-jwt` HTTP Header: `Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cC...` -```json +``` {} ``` @@ -183,7 +183,7 @@ HTTP Header: `Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cC...` `POST /edge/client/v1/authenticate/mfa` -```json +``` { "code": "123456" } diff --git a/docusaurus/docs/learn/core-concepts/security/authorization/auth.md b/docusaurus/docs/learn/core-concepts/security/authorization/auth.md index 8a1872cc9..4bb0d9f2b 100644 --- a/docusaurus/docs/learn/core-concepts/security/authorization/auth.md +++ b/docusaurus/docs/learn/core-concepts/security/authorization/auth.md @@ -10,7 +10,7 @@ client in the form of [Posture Checks](posture-checks.md). Authorization to connect to an Edge Router affects the Edge Router that are discoverable by a client. This will be reflected when listing a Edge Router directly and receiving a list of them during Session creation. -```mermaid +``` graph TD A[Idle] --> |Service update event| B[Check for Posture Queries] A --> |Interval check event| B diff --git a/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-edge-router-policy-cli.md b/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-edge-router-policy-cli.md index ee27d7f32..67db18d1a 100644 --- a/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-edge-router-policy-cli.md +++ b/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-edge-router-policy-cli.md @@ -9,6 +9,6 @@ To create an Edge Router Policy using the CLI issue the following commands. 1. Create an edge router policy named `my-policy` which allows all identities to use all routers. - ```bash + ``` ziti edge create edge-router-policy my-policy --identity-roles '#all' --edge-router-roles '#all' ``` diff --git a/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-edge-router-policy-cli.md b/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-edge-router-policy-cli.md index 72b47d6fb..838a8055a 100644 --- a/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-edge-router-policy-cli.md +++ b/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-edge-router-policy-cli.md @@ -8,6 +8,6 @@ To create a Service Edge Router Policy using the CLI issue the following command 1. Create a service edge router policy which allows all services to use all routers. - ```bash + ``` ziti edge create service-edger-router-policy 'my-policy' --service-roles '#all' --edge-router-roles '#all' ``` diff --git a/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-policy-cli.md b/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-policy-cli.md index eab4bd027..72c4418e1 100644 --- a/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-policy-cli.md +++ b/docusaurus/docs/learn/core-concepts/security/authorization/policies/_create-service-policy-cli.md @@ -8,6 +8,6 @@ To create a Service Policy using the CLI issue the following commands. 1. Create a service policy named `my-policy` which allows all identities to dial/connect to all services. - ```bash + ``` ziti edge create service-policy my-policy Dial --identity-roles '#all' --service-roles '#all' ``` diff --git a/docusaurus/docs/learn/core-concepts/security/authorization/posture-checks.md b/docusaurus/docs/learn/core-concepts/security/authorization/posture-checks.md index 54c679829..abd5781a1 100644 --- a/docusaurus/docs/learn/core-concepts/security/authorization/posture-checks.md +++ b/docusaurus/docs/learn/core-concepts/security/authorization/posture-checks.md @@ -13,7 +13,7 @@ Environmental state is saved as Posture Data - a set of values describing enviro to the controller via Posture Response sent from the client. Posture Responses are constructed from Posture Queries which are reported to the client per service from the controller. -```mermaid +``` sequenceDiagram Client->>+Controller: ListServices() Controller->>-Client: []Services @@ -85,7 +85,7 @@ build number will be used instead. `POST /edge/management/v1/posture-checks` -```json +``` { "typeId": "OS", "name": "windows-and-android", @@ -119,7 +119,7 @@ that are not specified will fail the check. `POST /edge/management/v1/posture-checks` -```json +``` { "typeId": "MAC", "name": "mac-list", @@ -155,7 +155,7 @@ is given a five-minute grace period before the posture check begins to fail. `POST /edge/management/v1/posture-checks` -```json +``` { "typeId": "MFA", "timeoutSeconds": 3600, @@ -191,7 +191,7 @@ sha1 fingerprints (thumbprints) of valid signing certificates. `POST /edge/management/v1/posture-checks` -```json +``` { "typeId": "PROCESS_MULTI", "name": "my-proc-multi", @@ -228,7 +228,7 @@ The `DOMAIN` Posture Check is used to verify that a Windows client has joined a `POST /edge/management/v1/posture-checks` -```json +``` { "typeId": "DOMAIN", "name": "domain-list", @@ -251,7 +251,7 @@ For troubleshooting purposes it is possible to view an identity's current Postur #### Response -```json +``` { "data": { "apiSessionPostureData": {}, @@ -308,7 +308,7 @@ For troubleshooting purposes it is possible to view the last fifty failed servic #### Response -```json +``` { "meta": {}, "data": [ diff --git a/docusaurus/docs/learn/core-concepts/security/enrollment.md b/docusaurus/docs/learn/core-concepts/security/enrollment.md index d5bf81985..1f6df6fac 100644 --- a/docusaurus/docs/learn/core-concepts/security/enrollment.md +++ b/docusaurus/docs/learn/core-concepts/security/enrollment.md @@ -11,7 +11,7 @@ available in the `enrollmentJWT` field. **Create:** `POST /edge/management/v1/edge-routers` -```json +``` { "name": "test3" } @@ -19,7 +19,7 @@ available in the `enrollmentJWT` field. **Get:** `GET /edge/management/v1/edge-routers/PYvobLGzj` -```json +``` { "data": { ..., @@ -64,7 +64,7 @@ complete enrollment. #### Edge Management API `POST /edge/management/v1/identities` -```json +``` { "name": "test-user10", "type": "User", @@ -87,7 +87,7 @@ complete enrollment. #### Edge Management API `GET /edge/management/v1/identities/-ItUkLGKUE` -```json +``` { "data": { ... @@ -122,7 +122,7 @@ OTT CA Enrollment requires that the enrolling client also has an existing client ##### Edge Management API `POST /edge/management/v1/identities` -```json +``` { "name": "test-user10", "type": "User", diff --git a/docusaurus/docs/learn/core-concepts/security/sessions.md b/docusaurus/docs/learn/core-concepts/security/sessions.md index 73ad53d8b..b7beefb2c 100644 --- a/docusaurus/docs/learn/core-concepts/security/sessions.md +++ b/docusaurus/docs/learn/core-concepts/security/sessions.md @@ -30,7 +30,7 @@ API Sessions are defined in the Client and Management Open API 2.0 specification Example `POST /edge/management/v1/authenticate` response: -```json +``` { "data": { "_links": { @@ -125,7 +125,7 @@ While partially authenticated, the API Session can only be used for a reduced se Authentication Queries are represented on an API Session the property `authQueries` which is an array. An example MFA challenge represented as an Authentication Query is provided below. -```json +``` { "authQueries": [ { @@ -171,7 +171,7 @@ the timeout has been reached, signaling an API Session removal. Activities that The API Session timeout defaults to 30 minutes and can be configured in `edge.api.sessionTimeout` in the controller configuration file. -```yaml +``` edge: api: ... diff --git a/docusaurus/docs/learn/quickstarts/browzer/example/index.md b/docusaurus/docs/learn/quickstarts/browzer/example/index.md index 928377a72..7584ccfaa 100644 --- a/docusaurus/docs/learn/quickstarts/browzer/example/index.md +++ b/docusaurus/docs/learn/quickstarts/browzer/example/index.md @@ -87,7 +87,7 @@ are many ways to solve this problem, it's up to you to pick 'the best' way.
Example Changing LetsEncrypt Permissions -```bash +``` sudo groupadd -g 2171 zitiweb sudo useradd -u 2171 -M ziggy sudo usermod -aG zitiweb ziggy @@ -99,11 +99,11 @@ sudo chmod -R g+rX /etc/letsencrypt/ You will want to enable the new group permissions in the current shell. Log out of your current session and log back in again. Doing so will enable the new group permission in your shell. After, set the `wildcard_url` variable again. Once set, verify you can access to the certificates: -```bash +``` ls -l /etc/letsencrypt/live/${wildcard_url}/ ``` You should see something similar to: -```bash +``` total 8 -rw-r--r-- 1 root zitiweb 692 Aug 17 21:12 README lrwxrwxrwx 1 root zitiweb 56 Aug 17 21:12 cert.pem -> ../../archive/browzerexample.demo.openziti.org/cert1.pem @@ -131,7 +131,7 @@ Since we have just obtained some LetsEncrypt certificates, we'll enable OpenZiti Alternative Server Certs __immediately__! To do that we'll set two new variables introduced with v0.29.0. Notice that the `${wildcard_url}` variable needs to be set if it's not already set: -```bash +``` export ZITI_PKI_ALT_SERVER_CERT="/etc/letsencrypt/live/${wildcard_url}/fullchain.pem" export ZITI_PKI_ALT_SERVER_KEY="/etc/letsencrypt/live/${wildcard_url}/privkey.pem" ``` @@ -149,12 +149,12 @@ and return here when complete. After completing the quickstart, you should be able to access the controller at both the alternate server cert url. Notice there's no need for 'insecure' (-sk) curl mode for the`${wildcard_url}` URL: -```bash +``` curl https://ctrl.${wildcard_url}:${ZITI_CTRL_EDGE_ADVERTISED_PORT} ``` and we should be able to curl to the non-alternative server url. Note for this we need to use `-sk` since this will be the self-signed PKI endpoint: -```bash +``` curl -sk https://${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}:${ZITI_CTRL_EDGE_ADVERTISED_PORT} ```
@@ -173,13 +173,13 @@ using a [web socket](https://en.wikipedia.org/wiki/WebSocket). We'll need to pro After completing the quickstart, you will have an edge router configuration file in the user's home directory. Use your favorite editor, such as [`vim`](https://en.wikipedia.org/wiki/Vim_(text_editor)) to edit the file: -```bash +``` vi $ZITI_HOME/${ZITI_NETWORK}-edge-router.yaml ``` Locate the "binding" section, and add a section that looks like this. Make sure to change the `address` and `advertise` fields accordingly to fit your `${wildcard_url}` value: -```bash +``` - binding: edge address: wss:0.0.0.0:8447 options: @@ -194,7 +194,7 @@ fields accordingly to fit your `${wildcard_url}` value: Restart the Edge Router After updating the router's configuration file you'll need to restart the router: -```bash +``` sudo systemctl restart ziti-router ``` @@ -206,7 +206,7 @@ After the router restarts you'll be able to verify the router is properly config should succeed and return a 404 message similar to the one shown below. Note port 8447 is used, if you change this port you will obviously need to change the port number to the one you chose: -```bash +``` curl https://ws.${wildcard_url}:8447 ``` @@ -242,7 +242,7 @@ First we need to decide/find an OIDC provider. Set a shell variable named `AUTH0_DOMAIN` and set it to the value shown on the "Basic Information" page in Auth0. Then set a shell variable named `AUTHO_CLIENTID`. For me, this looked like this: -```bash +``` AUTH0_DOMAIN=dev-b2q0t23rxctngxka.us.auth0.com AUTH0_CLIENTID=mKWvp7xJHWxHKPf4eol4VwZxRCmdJIMy ``` @@ -256,7 +256,7 @@ Make sure all variables listed below are set in your shell before running Now copy and paste this command to generate the browzer.env file. -```bash +``` export NODE_ENV=production export ZITI_BROWZER_BOOTSTRAPPER_LOGLEVEL=debug export ZITI_BROWZER_BOOTSTRAPPER_HOST=browzer.${wildcard_url} @@ -312,7 +312,7 @@ echo browzer env file written to: $ZITI_HOME/browzer.env Inspect the browzer.env File You should see something like: -```bash +``` browzer env file written to: /home/ubuntu/.ziti/quickstart/ip-172-31-47-200/browzer.env ``` @@ -332,7 +332,7 @@ used the "clone" approach to run my BrowZer (and ZAC). Follow one of those methods and ensure BrowZer is up and running. -```bash +``` browzer env file written to: /home/ubuntu/.ziti/quickstart/ip-172-31-47-200/browzer.env ``` @@ -347,14 +347,14 @@ created. ## Prepare the OpenZiti Network For the following steps, make sure you have all the variables set and make sure you have logged into the controller: -```bash +``` ziti edge login -u $ZITI_USER -p $ZITI_PWD -y ${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}:${ZITI_CTRL_EDGE_ADVERTISED_PORT} ```
Configure the External JWT Signer and Auth Policy -```bash +``` echo "configuring OpenZiti for BrowZer..." ziti_object_prefix=browzer-auth0 issuer=$(curl -s ${ZITI_BROWZER_OIDC_URL}/.well-known/openid-configuration | jq -r .issuer) @@ -373,7 +373,7 @@ echo "auth policy id: $auth_policy" After running the commands listed above, you should see output that confirms an `ext-jwt-signer` and `auth-policy` were created successfully. It should look similar to what is shown below. Ensure the id's for the signer and auth policy have some value and are not blank: -```bash +``` configuring OpenZiti for BrowZer... OIDC issuer : https://dev-b2q0t23rxctngxka.us.auth0.com/ OIDC jwks url : https://dev-b2q0t23rxctngxka.us.auth0.com/.well-known/jwks.json @@ -390,7 +390,7 @@ To enable access to the ZAC using BrowZer we need to make a service. Things to n HTTP port (the BrowZer Bootstrapper will provide HTTPS) and we're using the default port of 1408. Ensure the variables referenced are all set accordingly and then copy/paste these commands: -```bash +``` intercept_address="${ZITI_BROWZER_SERVICE}.ziti" intercept_port=80 offload_address=127.0.0.1 @@ -415,7 +415,7 @@ createService ``` Verify the commands all succeed (no errors shown) and the output looks similar to this after running: -```bash +``` New config brozac.host.config created with id: 5i85SF4pnehz1LEjJNvCtH New config brozac.int.config created with id: 2p8xuev7Vb9NzuZoEGi4tq New service brozac created with id: 5Ry0BOMr6VJGQjF51LdDxv @@ -435,13 +435,13 @@ after the user logs into the OIDC provider. If your OIDC provider doesn't provid learn/explore/understand how the OIDC provider you're using works. It's out of scope of this document to provide that sort of insight. Set a variable named `ZITI_BROWZER_IDENTITIES` and assign it an email address you plan to use: -```bash +``` ZITI_BROWZER_IDENTITIES="clint.dovholuk@company.name" ``` After create a __space__ delimited list (one value/email is fine too), copy and paste the following command: -```bash +``` echo "creating users specified by ZITI_BROWZER_IDENTITIES: ${ZITI_BROWZER_IDENTITIES}" for id in ${ZITI_BROWZER_IDENTITIES}; do ziti edge create identity user "${id}" --auth-policy ${auth_policy} --external-id "${id}" -a "${ZITI_BROWZER_SERVICE}.dialers" @@ -452,7 +452,7 @@ ziti edge update identity "${ZITI_ROUTER_NAME}" -a "${ZITI_BROWZER_SERVICE}.bind ``` After you run that command you should see output looking similar to this: -```bash +``` creating users specified by ZITI_BROWZER_IDENTITIES: clint.dovholuk@company.name New identity clint.dovholuk@company.name created with id: hmnQByTn3 ``` @@ -464,7 +464,7 @@ New identity clint.dovholuk@company.name created with id: hmnQByTn3 This is it! This is the moment we've been working for. Copy and paste this command to echo to the screen the url to test out and let's see ZAC protected by BrowZer!!! -```bash +``` echo " " echo "now go to: https://${ZITI_BROWZER_VHOST}:${ZITI_BROWZER_BOOTSTRAPPER_LISTEN_PORT} and see your ${ZITI_BROWZER_SERVICE}!" echo " " @@ -472,7 +472,7 @@ echo " " ### If Needed, BrowZer Bootstrapper Logs -```bash +``` journalctl -fu browzer-bootstrapper ``` @@ -480,7 +480,7 @@ journalctl -fu browzer-bootstrapper ## Cleaning up and Trying Again To clean everything up and try it all over (if you need to) run these commands: -```bash +``` sudo systemctl stop browzer-bootstrapper sudo systemctl stop ziti-controller sudo systemctl stop ziti-router diff --git a/docusaurus/docs/learn/quickstarts/browzer/index.md b/docusaurus/docs/learn/quickstarts/browzer/index.md index 0cff1f0b1..9d562ce3a 100644 --- a/docusaurus/docs/learn/quickstarts/browzer/index.md +++ b/docusaurus/docs/learn/quickstarts/browzer/index.md @@ -47,7 +47,7 @@ Using the OIDC discovery endpoint, discover the `issuer` and `jwks_uri` from the CLI, create the external jwt. Shown below is a `bash` example. Replace the values accordingly. Capture the returned identity, it will be necessary after creating the external jwt signer: -```bash +``` issuer="__issuer_id_here__" jwks_uri="__jwks_uri_here__" audience="__audience_here__" @@ -75,7 +75,7 @@ with a new authentication policy, as shown. Once you understand how authenticati then you can make an informed decision if you want to modify the default authentication policy or not ::: -```bash +``` ext_jwt_signer="__ext_jwt_signer_id_from_above__" ziti edge create auth-policy \ "auth-policy-name-here" \ @@ -92,7 +92,7 @@ policy. In this example, a new identity will be created and the associated OIDC provider will be expected to provide a bearer token which has an `email` claim with the value `ziggy@openziti.io` and names the identity `openziti_ziggy`: -```bash +``` identity_name="openziti_ziggy" auth_policy="__auth_policy_id_from_above__" external_id="ziggy@openziti.io" @@ -121,7 +121,7 @@ them. To run using Docker, you can either reference the environment variables (s * `ZITI_BROWZER_BOOTSTRAPPER_KEY_PATH`: the associated key for the ZITI_BROWZER_BOOTSTRAPPER_CERTIFICATE_PATH * `ZITI_BROWZER_BOOTSTRAPPER_TARGETS`: A json block representing the services to enable BrowZer for. -```bash +``` NODE_ENV: production ZITI_BROWZER_RUNTIME_LOGLEVEL: debug ZITI_BROWZER_RUNTIME_HOTKEY: alt+F12 @@ -179,7 +179,7 @@ system administration. ::: ### Example Docker Command -```bash +``` docker run \ --name ziti-browzer-bootstrapper \ --rm -v /etc/letsencrypt:/etc/letsencrypt \ @@ -209,12 +209,12 @@ to start automatically on failure or reboot. If you have used the ["clone from GitHub"](#cloning-from-github) approach, you have sourced the `ziti-cli-functions.sh` helper script, and have the environment variables set from the quickstart installation you can execute a single function to create a systemd unit file: `createBrowZerSystemdFile`. Execute this now and you'll see something like: -```bash +``` Ziti BrowZer Bootstrapper systemd file written to: /home/ubuntu/.ziti/quickstart/ip-172-31-47-200/browzer-bootstrapper.service ``` Once created, you can copy that file and `enable` the unit with systemd: -```bash +``` createBrowZerSystemdFile sudo cp "${ZITI_HOME}/browzer-bootstrapper.service" /etc/systemd/system sudo systemctl daemon-reload @@ -224,7 +224,7 @@ sudo systemctl enable --now browzer-bootstrapper
Verify BrowZer Started -```bash +``` systemctl status browzer-bootstrapper --no-pager --lines 0 ``` @@ -232,7 +232,7 @@ systemctl status browzer-bootstrapper --no-pager --lines 0 Example systemctl Output You should see output that looks similar to this. Notice the "Active" status is (running) and not failed/restarting etc: -```bash +``` ● browzer-bootstrapper.service - A systemd unit file for the Ziti BrowZer Bootstrapper Loaded: loaded (/etc/systemd/system/browzer-bootstrapper.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2023-08-18 12:52:54 UTC; 1min 24s ago diff --git a/docusaurus/docs/learn/quickstarts/network/help/reset-quickstart.md b/docusaurus/docs/learn/quickstarts/network/help/reset-quickstart.md index baf4c5911..4f675a361 100644 --- a/docusaurus/docs/learn/quickstarts/network/help/reset-quickstart.md +++ b/docusaurus/docs/learn/quickstarts/network/help/reset-quickstart.md @@ -7,13 +7,13 @@ You may want to re-run `expressInstall` with different parameters or because a r 1. Delete the express install directory. Delete is forever, so make sure you're deleting the right thing. - ```bash + ``` rm -rI "${ZITI_HOME}" # probably a sub-directory of ~/.ziti/quickstart/ ``` 1. If the current shell environment was configured by the express install you may unset vars named like `ZITI_`. This will prepare your current shell environment to set up and re-run `expressInstall`. - ```bash + ``` unsetZitiEnv ``` diff --git a/docusaurus/docs/learn/quickstarts/network/hosted.md b/docusaurus/docs/learn/quickstarts/network/hosted.md index c3c51eec8..042864bce 100644 --- a/docusaurus/docs/learn/quickstarts/network/hosted.md +++ b/docusaurus/docs/learn/quickstarts/network/hosted.md @@ -50,11 +50,11 @@ of your instance. It is possible to use an IP address, but a DNS name is a more The quickest and easiest thing to do, is find your external DNS name and set it into the `EXTERNAL_DNS` environment variable. You may skip setting `EXTERNAL_DNS` if you don't need to configure the advertised DNS Subject Alternative Name (SAN). For example, -```bash +``` export EXTERNAL_DNS="acme.example.com" ``` -```bash +``` export EXTERNAL_IP="$(curl -s eth0.me)" export ZITI_CTRL_EDGE_IP_OVERRIDE="${EXTERNAL_IP}" export ZITI_ROUTER_IP_OVERRIDE="${EXTERNAL_IP}" @@ -71,7 +71,7 @@ As with any script that is downloaded and run from the internet, we recommend yo the script before running it locally. This script is provided as a convenience method for installing an environment quickly and easily. -```bash +``` source /dev/stdin <<< "$(wget -qO- https://get.openziti.io/ziti-cli-functions.sh)"; expressInstall ``` @@ -80,14 +80,14 @@ source /dev/stdin <<< "$(wget -qO- https://get.openziti.io/ziti-cli-functions.sh This assumes you already ran `expressInstall` on a Linux server. If it's available on your system, then it is recommended to use `systemd` to manage your controller and router processes. This is useful to make sure the controller can restart automatically should you shutdown/restart the server. To generate the `systemd` unit files, run: -```bash +``` createControllerSystemdFile createRouterSystemdFile "${ZITI_ROUTER_NAME}" ``` Example output: -```bash +``` $ createControllerSystemdFile Controller systemd file written to: /home/ubuntu/.ziti/quickstart/ip-172-31-23-18/ip-172-31-23-18-edge-controller.service @@ -104,14 +104,14 @@ you are enabling systemd, use `systemctl` to start/stop the components. During t were started using the helper scripts to complete the installation. Both should not be running, but before you run the controller and router with `systemd` you need to stop them if they're currently running: -```bash +``` stopRouter stopController ``` Example output: -```bash +``` $ stopRouter INFO: Router stopped. @@ -121,7 +121,7 @@ INFO: Controller stopped. After the `systemd` service units are generated, you can then install them by running: -```bash +``` sudo cp "${ZITI_HOME}/${ZITI_CTRL_NAME}.service" /etc/systemd/system/ziti-controller.service sudo cp "${ZITI_HOME}/${ZITI_ROUTER_NAME}.service" /etc/systemd/system/ziti-router.service sudo systemctl daemon-reload @@ -133,14 +133,14 @@ Now, both the controller and the edge router will restart automatically if the m After a few seconds you can then run these commands and verify systemd has started the processes and see the status: -```bash +``` sudo systemctl -q status ziti-controller --lines=0 --no-pager sudo systemctl -q status ziti-router --lines=0 --no-pager ``` Example output: -```bash +``` $ sudo systemctl -q status ziti-controller --lines=0 --no-pager ● ziti-controller.service - Ziti-Controller Loaded: loaded (/etc/systemd/system/ziti-controller.service; disabled; vendor preset: enabled) @@ -166,13 +166,13 @@ $ sudo systemctl -q status ziti-router --lines=0 --no-pager If you log out and log back in again you can source the *.env file located in `ZITI_HOME`. -```bash +``` source ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env ``` Example output: -```bash +``` $ source ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env adding /home/ubuntu/.ziti/quickstart/ip-10-0-0-1/ziti-bin/ziti-v0.20.2 to the path diff --git a/docusaurus/docs/learn/quickstarts/network/local-docker-compose.md b/docusaurus/docs/learn/quickstarts/network/local-docker-compose.md index 04f1e4eb8..868b5d066 100644 --- a/docusaurus/docs/learn/quickstarts/network/local-docker-compose.md +++ b/docusaurus/docs/learn/quickstarts/network/local-docker-compose.md @@ -19,7 +19,7 @@ First, grab the compose file from the Using curl that would look like this: -```bash +``` curl -so docker-compose.yaml https://get.openziti.io/dock/docker-compose.yml ``` @@ -27,11 +27,11 @@ Next, grab the default [environment file](https://get.openziti.io/dock/.env) or just make a file in this folder that looks like this: -```bash +``` curl -so .env https://get.openziti.io/dock/.env ``` or, if you would prefer to make your .env file manually, create a file in some way such as using the command shown below: -```text +``` cat > .env < Hello World @@ -304,7 +304,7 @@ Hello World ``` Don't forget - you can also access this from the exported port 80 on your local machine too! -```bash +``` curl http://localhost:80 
 Hello World
diff --git a/docusaurus/docs/learn/quickstarts/network/local-kubernetes.md b/docusaurus/docs/learn/quickstarts/network/local-kubernetes.md
index f8bdd9b6c..2497112c1 100644
--- a/docusaurus/docs/learn/quickstarts/network/local-kubernetes.md
+++ b/docusaurus/docs/learn/quickstarts/network/local-kubernetes.md
@@ -39,13 +39,13 @@ Your computer running `minikube` needs to resolve these three domain names. They
 
 1. Enable localhost binding in WSL.
 
-   ```cmd
+   ```
    %USERPROFILE%\.wslconfig
    ```
 
    Add `localhostforwarding=true` to the `[wsl2]` section like this.
 
-   ```ini
+   ```
    [wsl2]
    # Turn off default connection to bind WSL 2 localhost to Windows localhost
    localhostforwarding=true
@@ -55,32 +55,32 @@ Your computer running `minikube` needs to resolve these three domain names. They
 
    Edit the system hosts file.
 
-   ```cmd
+   ```
    %SYSTEMROOT%\system32\drivers\etc\hosts
    ```
 
    Add this line to the system hosts file.
 
-   ```ini
+   ```
    # miniziti
    127.0.0.1  miniziti-controller.miniziti.internal  miniziti-router.miniziti.internal  miniziti-console.miniziti.internal
    ```
 
 1. Restart WSL.
 
-   ```powershell
+   ```
    wsl --shutdown
    ```
 
 1. In WSL, verify that Docker restarted successfully.
 
-   ```bash
+   ```
    docker ps
    ```
 
    If Docker has restarted then you'll see your running containers, if any. If you don't have any running containers then you'll only see the headings, like this. This is a healthy result and you can skip to the next numbered step.
 
-   ```bash
+   ```
    $ docker ps
    CONTAINER ID   IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
    ```
@@ -89,26 +89,26 @@ Your computer running `minikube` needs to resolve these three domain names. They
 
    You can verify that the `docker-desktop-data` instance is running with this PowerShell command.
 
-   ```powershell
+   ```
    wsl -l -v
    ```
 
    Example output:
 
-   ```powershell
+   ```
    % wsl -l -v
    FIXME: paste output here showing WSL, docker-desktop, docker-desktop-data running
    ```
 
 1. In WSL, verify that localhost is bound. You know it's working if you see the *.ziti DNS names in `/etc/hosts` duplicated from Windows.
 
-   ```bash
+   ```
    grep ziti /etc/hosts
    ```
 
    It should look like this.
 
-   ```bash
+   ```
    $ grep ziti /etc/hosts
    127.0.0.1    miniziti-controller.miniziti.internal miniziti-router.miniziti.internal  miniziti-console.miniziti.internal
    ```
@@ -121,7 +121,7 @@ Your computer running `minikube` needs to resolve these three domain names. They
    You will likely be prompted by `minikube tunnel` for your WSL user's password, but this prompt may not occur immediately. This grants permission for the tunnel to add a route to the minikube node IP.
    :::
 
-   ```bash
+   ```
    minikube --profile miniziti start
    minikube --profile miniziti tunnel
 
@@ -134,7 +134,7 @@ In macOS, `minikube` sets up localhost port forwarding to the IP of the Docker c
 
 1. Add the DNS names to your system hosts file.
 
-   ```bash
+   ```
    sudo tee -a /etc/hosts <<< "127.0.0.1  miniziti-controller.miniziti.internal  miniziti-router.miniziti.internal  miniziti-console.miniziti.internal"
    ```
 
@@ -146,7 +146,7 @@ In macOS, `minikube` sets up localhost port forwarding to the IP of the Docker c
    You will likely be prompted by `minikube tunnel` for your macOS user's password, but this prompt may not occur immediately. This grants permission for the tunnel to add a route to the minikube node IP.
    :::
 
-   ```bash
+   ```
    minikube --profile miniziti start
    minikube --profile miniziti tunnel
 
@@ -157,7 +157,7 @@ In macOS, `minikube` sets up localhost port forwarding to the IP of the Docker c
 
 On Linux, the IP of the `minikube` node running in Docker is routeable via the bridge interface created by `minikube`. Create a "miniziti" profile if you haven't, and obtain the node's external IP for your hosts file.
 
-```bash
+```
 minikube --profile miniziti start
 sudo tee -a /etc/hosts <<< "$(minikube --profile miniziti ip) miniziti-controller.miniziti.internal  miniziti-router.miniziti.internal  miniziti-console.miniziti.internal"
 ```
@@ -180,7 +180,7 @@ It's recommended that you read the script before you run it. It's safe to re-run
 

 Be sure to complete the DNS setup steps above before running this command.
 
-```bash
+```
 bash ./miniziti.bash
 ```
 
@@ -195,7 +195,7 @@ This section explains the actions performed by the `miniziti.bash` script.You ne
 
 First, let's create a brand new `minikube` profile named "miniziti".
 
-```bash
+```
 minikube --profile miniziti start
 ```
 
@@ -204,7 +204,7 @@ minikube --profile miniziti start
 :::info
 You can always restore the KUBECONFIG context from this Minikube quickstart like this:
 
-```bash
+```
 minikube --profile miniziti update-context
 ```
 
@@ -212,20 +212,20 @@ minikube --profile miniziti update-context
 
 Let's do a quick test of the current KUBECONFIG context.
 
-```bash
+```
 kubectl cluster-info
 ```
 
 A good result looks like this (no errors).
 
-```bash
+```
 # macOS and Linux look like this
 $ kubectl cluster-info
 Kubernetes control plane is running at https://192.168.49.2:8443
 CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
 ```
 
-```bash
+```
 # Windows with WSL looks like this
 $ kubectl cluster-info
 Kubernetes control plane is running at https://127.0.0.1:49439
@@ -239,14 +239,14 @@ You will need two Minikube addons:
 1. `ingress`: installs the Nginx ingress controller. Ingresses provide access into the cluster and are the only things exposed to networks outside the cluster. This is required by the miniziti script, but the Helm charts can be configured to use other ingress controllers.
 1. `ingress-dns`: provides a DNS server that can answer queries about the cluster's ingresses, e.g. "miniziti-controller.miniziti.internal" which will be created when you install the OpenZiti Controller Helm chart.
 
-```bash
+```
 minikube --profile miniziti addons enable ingress
 minikube --profile miniziti addons enable ingress-dns
 ```
 
 OpenZiti will need SSL passthrough, so let's patch the `ingress-nginx` deployment to enable that feature.
 
-```bash
+```
 kubectl patch deployment "ingress-nginx-controller" \
    --namespace ingress-nginx \
    --type='json' \
@@ -276,7 +276,7 @@ Now your miniziti cluster is ready for some OpenZiti!


 
 You need to install the required [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD) for the OpenZiti Controller.
 
-```bash
+```
 kubectl apply \
    --filename https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.crds.yaml
 kubectl apply \
@@ -287,7 +287,7 @@ kubectl apply \
 
 Add the OpenZiti Helm Repo
 
-```bash
+```
 helm repo add "openziti" https://openziti.io/helm-charts/
 ```
 
@@ -297,7 +297,7 @@ Let's create a Helm release named "miniziti-controller" for the OpenZiti Control
 
 1. Install the Controller chart
 
-   ```bash
+   ```
    helm install "ziti-controller" openziti/ziti-controller \
       --namespace ziti-controller --create-namespace \
       --set clientApi.advertisedHost="miniziti-controller.miniziti.internal" \
@@ -306,7 +306,7 @@ Let's create a Helm release named "miniziti-controller" for the OpenZiti Control
 
 1. This may take a few minutes. Wait the controller's pod status progress to "Running." You can get started on the DNS set up in the next section, but you need the controller up and running to install the router.
 
-   ```bash
+   ```
    kubectl wait deployments "ziti-controller" \
       --namespace ziti-controller \
       --for condition=Available=True \
@@ -319,7 +319,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Add the *.ziti forwarder to the end of the value of `Corefile` in CoreDNS's configmap. Don't forget to substitute the real IP from `minikube --profile miniziti ip` if you get something different than "192.168.49.2", and be mindful to keep the indentation the same as the default `.:53` handler.
 
-   ```bash
+   ```
    # 1. Edit the configmap.
    # 2. Save the file.
    # 3. Exit the editor.
@@ -327,7 +327,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
       --namespace kube-system
    ```
 
-   ```nginx
+   ```
        miniziti.internal:53 {
           errors
           cache 30
@@ -337,7 +337,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
    It should look like this.
 
-   ```yaml
+   ```
    apiVersion: v1
    data:
    Corefile: |
@@ -382,7 +382,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Delete the running CoreDNS pod so a new one will pick up the Corefile change you just made.
 
-   ```bash
+   ```
    kubectl get pods \
       --namespace kube-system \
       | awk '/^coredns-/ {print $1}' \
@@ -392,7 +392,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Verify that *.ziti DNS names are resolvable from inside your cluster. This is required for your pods to communicate with the OpenZiti Controller's advertised address.You will know it's working because you see the same IP address in the response as when you run `minikube --profile miniziti ip`.
 
-   ```bash
+   ```
    kubectl run "dnstest" --rm --tty --stdin --image=busybox --restart=Never -- \
          nslookup miniziti-controller.miniziti.internal
    ```
@@ -401,7 +401,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Log in to OpenZiti.
 
-   ```bash
+   ```
    kubectl get secrets "ziti-controller-admin-secret" \
                --namespace ziti-controller \
                --output go-template='{{index .data "admin-password" | base64decode }}' \
@@ -412,7 +412,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Create a Router with role "public-routers" and save the enrollment one-time-token as a temporary file.
 
-   ```bash
+   ```
    ziti edge create edge-router "miniziti-router" \
       --role-attributes "public-routers" \
       --tunneler-enabled \
@@ -421,7 +421,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Install the Router Chart.
 
-   ```bash
+   ```
    helm install "ziti-router" openziti/ziti-router \
       --namespace ziti-router --create-namespace \
       --set-file enrollmentJwt=/tmp/miniziti-router.jwt \
@@ -438,11 +438,11 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Verify the new router is "online=true"
 
-   ```bash
+   ```
    ziti edge list edge-routers
    ```
 
-   ```bash
+   ```
    # example output
    $ ziti edge list edge-routers
    ╭────────────┬─────────────────┬────────┬───────────────┬──────┬────────────────╮
@@ -457,7 +457,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Install the chart
 
-   ```bash
+   ```
    helm install "ziti-console" openziti/ziti-console \
       --namespace ziti-console --create-namespace  \
       --set ingress.advertisedHost=miniziti-console.miniziti.internal \
@@ -469,7 +469,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
    You'll see an Nginx 503 error while the console is deploying.
 
-   ```bash
+   ```
    kubectl wait deployments "ziti-console" \
       --namespace ziti-console \
       --for condition=Available=True \
@@ -478,7 +478,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 1. Get the admin password on your clipboard.
 
-   ```bash
+   ```
    kubectl get secrets "ziti-controller-admin-secret" \
       --namespace ziti-controller \
       --output go-template='{{"\nINFO: Your OpenZiti Console http://miniziti-console.miniziti.internal password for \"admin\" is: "}}{{index .data "admin-password" | base64decode }}{{"\n\n"}}'
@@ -490,7 +490,7 @@ Configure CoreDNS in the miniziti cluster. This is necessary no matter which hos
 
 Here's a BASH script that runs several `ziti` CLI commands to illustrate a minimal set of identities, services, and policies.
 
-```bash
+```
 ziti edge create identity device "miniziti-client" \
     --jwt-output-file /tmp/miniziti-client.jwt --role-attributes httpbin-clients
 
@@ -525,7 +525,7 @@ ziti edge enroll /tmp/httpbin-host.jwt
 
 This Helm chart installs an OpenZiti fork of `go-httpbin`, so it doesn't need to be accompanied by an OpenZiti Tunneler. We'll use it as a demo API to test the OpenZiti Service you just created named "httpbin-service".
 
-```bash
+```
 helm install "miniziti-httpbin" openziti/httpbin \
    --set-file zitiIdentity=/tmp/httpbin-host.json \
    --set zitiServiceName=httpbin-service
@@ -542,14 +542,14 @@ Follow [the instructions for your tunneler OS version](https://openziti.io/docs/
 
 As soon as identity enrollment completes you should have a new OpenZiti DNS name available to this device. Let's test that with a DNS query.
 
-```bash
+```
 # this DNS answer is coming from the OpenZiti Tunneler, e.g. Ziti Desktop Edge
 nslookup httpbin.miniziti.private
 ```
 
 ## Test the Demo API Service
 
-```bash
+```
 # macOS or Linux, including WSL
 curl -sSf -XPOST -d ziti=awesome http://httpbin.miniziti.private/post | jq .data
 ```
@@ -568,7 +568,7 @@ Now that you've successfully tested the OpenZiti Service, check out the various
    1. Hint: the apiserver's address is "kubernetes.default.svc:443" inside the cluster.
    1. Hint: After you create the configs, service, and policies, grant "Bind" permission for the service to "miniziti-router" by adding a role.
 
-      ```bash
+      ```
       # the role you add needs to match the bind policy's identity roles
       ziti edge update identity "miniziti-router" \
          --role-attributes k8sapi-hosts
@@ -585,13 +585,13 @@ Now that you've successfully tested the OpenZiti Service, check out the various
 
    Edit the system hosts file.
 
-   ```cmd
+   ```
    %SYSTEMROOT%\system32\drivers\etc\hosts
    ```
 
    Remove this line.
 
-   ```ini
+   ```
    # miniziti
    127.0.0.1  miniziti-controller.miniziti.internal  miniziti-router.miniziti.internal  miniziti-console.miniziti.internal
    ```
@@ -601,7 +601,7 @@ Now that you've successfully tested the OpenZiti Service, check out the various
 
 1. Remove the `mini*.ziti` names from `/etc/hosts`.
 
-   ```bash
+   ```
    sudo sed -iE '/miniziti.*\.internal/d' /etc/hosts
    ```
 
@@ -610,7 +610,7 @@ Now that you've successfully tested the OpenZiti Service, check out the various
 
 1. Remove the `mini*.ziti` names from `/etc/hosts`.
 
-   ```bash
+   ```
    sudo sed -iE '/miniziti.*\.internal/d' /etc/hosts
    ```
 
@@ -619,7 +619,7 @@ Now that you've successfully tested the OpenZiti Service, check out the various
 
 2. Delete the cluster.
 
-   ```bash
+   ```
    minikube --profile miniziti delete
    ```
 
diff --git a/docusaurus/docs/learn/quickstarts/network/local-no-docker.md b/docusaurus/docs/learn/quickstarts/network/local-no-docker.md
index c0e18b35c..3d1bfd07e 100644
--- a/docusaurus/docs/learn/quickstarts/network/local-no-docker.md
+++ b/docusaurus/docs/learn/quickstarts/network/local-no-docker.md
@@ -28,7 +28,7 @@ are the default ports the edge router will use.
 
 Running the latest version of Ziti locally is as simple as running this one command:
 
-```bash
+```
     source /dev/stdin <<< "$(wget -qO- https://get.openziti.io/ziti-cli-functions.sh)"; expressInstall
 ```
 
@@ -48,13 +48,13 @@ edge-router.
 
 ## Start Your Controller
 
-```bash
+```
 startController
 ```
 
 Example output:
 
-```bash
+```
 $ startController
 ziti-controller started as process id: 1286. log located at: /home/vagrant/.ziti/quickstart/bullseye/bullseye.log
 ```
@@ -73,12 +73,12 @@ You can see what your value is set to by running
 `$(hostname -s):1280`. Make sure the controller is available by trying to curl to the address, and then start the edge router. 
 
 
-```bash
+```
 curl -sk "https://${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}:${ZITI_CTRL_EDGE_ADVERTISED_PORT}"
 ```
 
 Example output: 
-```bash
+```
 {"data":{"apiVersions":{"edge":{"v1":{"apiBaseUrls":["https://your.hostname:1280/edge/client/v1"],"path":"/edge/client/v1"}},"edge-client":{"v1":{"apiBaseUrls":["https://your.hostname:1280/edge/client/v1"],"path":"/edge/client/v1"}},"edge-management":{"v1":{"apiBaseUrls":["https://your.hostname:1280/edge/management/v1"],"path":"/edge/management/v1"}}},"buildDate":"2023-06-23T15:08:25Z","revision":"65d1dda821a3","runtimeVersion":"go1.20.5","version":"v0.28.4"},"meta":{}}
 ```
 
@@ -87,13 +87,13 @@ Example output:
 Now that the controller is ready, you can start the edge router created with the 'express' process. You can start this 
 router locally by running:
 
-```bash
+```
 startRouter
 ```
 
 Example output:
 
-```bash
+```
 $ startRouter
 Express Edge Router started as process id: 1296. log located at: /home/vagrant/.ziti/quickstart/bullseye/bullseye-edge-router.log
 ```
@@ -103,14 +103,14 @@ Again, this will default to using `$(hostname -s)` as the host name and port 302
 
 ### Stopping the Controller and Router
 
-```bash
+```
 stopRouter 
 stopController 
 ```
 
 Example output:
 
-```bash
+```
 $ stopRouter 
 INFO: Router stopped.
 
@@ -123,7 +123,7 @@ INFO: Controller stopped.
 At this point you should have a functioning [Ziti Network](/learn/introduction/index.mdx). The script 
 you sourced provides another function to login to your network. Try this now by running `zitiLogin`. You should see 
 something similar to this:
-```bash
+```
 $ zitiLogin
 Token: 40d2d280-a633-46c9-8499-ab2e005dd222
 Saving identity 'default' to ${HOME}/.ziti/quickstart/My-Mac-mini/ziti-cli.json
@@ -134,7 +134,7 @@ You can now use the `ziti` CLI to interact with Ziti!. The
 to your path, alias `ziti` if you like. Let's try to use this command to see if the edge router is online by running:
 `"${ZITI_BIN_DIR-}/ziti" edge list edge-routers`.
 
-```bash
+```
 $ "${ZITI_BIN_DIR-}/ziti" edge list edge-routers
 id: rhx6687N.P    name: My-Mac-mini    isOnline: true    role attributes: {}
 results: 1-1 of 1
@@ -146,7 +146,7 @@ Horray! Our edge router shows up and is online!
 
 You can try out creating and running a simple echo service through ziti by running the `first-service` tutorial.
 
-```bash
+```
 $ "${ZITI_BIN_DIR-}/ziti" demo first-service
 ```
 
@@ -171,7 +171,7 @@ Please realize that if you change these variables each of the "hostname" variabl
 Here is an example which allows you to put all the files into a folder called: `${HOME}/.ziti/quickstart/newfolder`, uses
 a host named 'localhost', and uses ports 8800 for the edge controller and 9090 for the edge router:
 
-```bash
+```
 ZITI_NETWORK="newfolder"; \
 ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=localhost; \
 ZITI_CTRL_EDGE_ADVERTISED_PORT=8800; \
@@ -187,7 +187,7 @@ source the "env" file that is placed into the location you specified. This file
 `$HOME/.ziti/quickstart/$(hostname)/$(hostname).env`. You can source this file to place the environment variables back
 into your shell.
 
-```bash
+```
 source $HOME/.ziti/quickstart/$(hostname)/$(hostname).env
 ```
 
diff --git a/docusaurus/docs/learn/quickstarts/network/local-with-docker.md b/docusaurus/docs/learn/quickstarts/network/local-with-docker.md
index 7b1db5235..3ce7b398b 100644
--- a/docusaurus/docs/learn/quickstarts/network/local-with-docker.md
+++ b/docusaurus/docs/learn/quickstarts/network/local-with-docker.md
@@ -24,7 +24,7 @@ Running Ziti locally via Docker will require you to create a "named volume" in d
 will be saved.
 
 Create the named volume now using this command:
-```bash
+```
 docker volume create myPersistentZitiFiles
 ```
 
@@ -34,7 +34,7 @@ Other containers on the Docker network will **need** to address the controller.
 a network alias. This forces you to add the container to a network which is not the default network. 
 
 Create the docker network now using this command:
-```bash
+```
 docker network create myFirstZitiNetwork
 ```
 
@@ -62,7 +62,7 @@ we'll use `-it` to make seeing the output from the logs easier.
 Here's an example which will use the Docker network named "myFirstZitiNetwork" and expose the controller to your local
 computer on port 1280 (the default port).
 
-```bash
+```
 docker run \
   --name ziti-controller \
   -e ZITI_CTRL_ADVERTISED_ADDRESS=ziti-edge-controller \
@@ -83,7 +83,7 @@ as well as authorization of services and routers using ([service edge router pol
 The docker-based quickstart doesn't perform these steps automatically. Run the initialization container one time, after 
 starting the controller as shown
 
-```shell
+```
 docker run \
   --network myFirstZitiNetwork \
   --network-alias ziti-controller-init-container \
@@ -105,7 +105,7 @@ The first noticeable difference is that we need to pass in the name of the edge
 network, the name supplied needs tobe addressable by clients.  Also notice the port exported is port 3022. This is the
 default port used by edge routers. 
 
-```bash
+```
 docker run \
   --name ziti-edge-router-1 \
   -e ZITI_ROUTER_NAME=ziti-edge-router-1 \
@@ -123,7 +123,7 @@ docker run \
 
 If you want to create a second edge router, you'll need to override the router port, don't forget to export that port too
 
-```bash
+```
 docker run \
   --name ziti-edge-router-2 \
   -e ZITI_ROUTER_NAME=ziti-edge-router-2 \
@@ -162,7 +162,7 @@ the router did indeed come online and is running as you expect. To do this, we'l
 command and `exec` into the machine. First, you'll need to know your Docker container name which you can figure out by
 running `docker ps`.
 
-```bash
+```
 $ docker ps
 
 CONTAINER ID   IMAGE                 COMMAND                  CREATED          STATUS          PORTS
@@ -177,7 +177,7 @@ container: `docker exec -it xenodochial_cori /bin/bash`
 
 Once in the container, I can now issue `zitiLogin` to authenticate the `ziti` CLI.
 
-```bash
+```
 zitiLogin
 Token: b16f182f-88b3-4fcc-9bfc-1e32319ca486
 Saving identity 'default' to /persistent/ziti-cli.json
@@ -186,7 +186,7 @@ Saving identity 'default' to /persistent/ziti-cli.json
 And finally, once authenticated I can test to see if the edge router is online in the controller and as you'll see, the
 `isOnline` property is true!
 
-```bash
+```
 ziti@a33d58248d6e:/persistent$ ziti edge list edge-routers
 id: qNZyqZEix3    name: ziti-edge-router-1    isOnline: true    role attributes: {}
 results: 1-1 of 1
diff --git a/docusaurus/docs/learn/quickstarts/services/kubernetes-service.md b/docusaurus/docs/learn/quickstarts/services/kubernetes-service.md
index 472f09225..5d8f7741c 100644
--- a/docusaurus/docs/learn/quickstarts/services/kubernetes-service.md
+++ b/docusaurus/docs/learn/quickstarts/services/kubernetes-service.md
@@ -9,7 +9,7 @@ This is a quick example for tunneling to a Kubernetes workload with OpenZiti tha
 
 1. Create OpenZiti configs, service, and policies for the Hello demo deployment.
 
-    ```bash
+    ```
     ziti edge create identity device "hello-host" \
         --jwt-output-file /tmp/hello-host.jwt --role-attributes hello-hosts
 
@@ -39,7 +39,7 @@ This is a quick example for tunneling to a Kubernetes workload with OpenZiti tha
 
    This chart is a regular, non-OpenZiti demo server deployment. Next we'll connect it to our OpenZiti Network with an OpenZiti Tunneler deployment.
 
-    ```bash
+    ```
     helm install "hello-toy" openziti/hello-toy \
         --namespace hello-toy --create-namespace \
         --set serviceDomainName=minihello
@@ -47,7 +47,7 @@ This is a quick example for tunneling to a Kubernetes workload with OpenZiti tha
 
 1. Deploy an OpenZiti Tunneler Pod.
 
-    ```bash
+    ```
     helm install "ziti-host" openziti/ziti-host \
         --namespace hello-toy \
         --set-file zitiIdentity=/tmp/hello-host.json
@@ -55,7 +55,7 @@ This is a quick example for tunneling to a Kubernetes workload with OpenZiti tha
 
 1. Wait for deployment.
 
-    ```bash
+    ```
     kubectl wait deployments "ziti-host" \
         --namespace hello-toy \
         --for condition=Available=True \
diff --git a/docusaurus/docs/learn/quickstarts/services/ztha.md b/docusaurus/docs/learn/quickstarts/services/ztha.md
index efd3f7c85..7f2696fe1 100644
--- a/docusaurus/docs/learn/quickstarts/services/ztha.md
+++ b/docusaurus/docs/learn/quickstarts/services/ztha.md
@@ -72,7 +72,7 @@ followed either the [Local - No Docker](/learn/quickstarts/network/local-no-dock
 [Host Ziti Anywhere](/learn/quickstarts/network/hosted.md) quickstart, you should have a file that can be sourced. Here is an example of 
 my personal "Local - No Docker" result when sourcing that file:
 
-```shell
+```
 $ source ~/.ziti/quickstart/$(hostname -s)/$(hostname -s).env
 
 adding /home/cd/.ziti/quickstart/sg3/ziti-bin/ziti-v0.25.6 to the path
@@ -83,7 +83,7 @@ the env file which adds `ziti` to your path will be sourced for you as well.
 
 Here's an example command using `docker` to exec into the controller container:
 
-```shell
+```
 $ docker exec -it docker_ziti-controller_1 bash
 
 adding /var/openziti/ziti-bin to the path
@@ -134,7 +134,7 @@ Note that step 7 below requires you to have set the variable named `http_server_
 with the tunneler option (`-t`) enabled. This means that edge-router is configured to serve as a tunneller. Run `ziti edge list 
 identities` to find the name of the identity associated to the router.
 
-```shell
+```
 # login to your controller - replace the host/port with the correct value
 ziti edge login localhost:1280
 
diff --git a/docusaurus/docs/learn/quickstarts/zac/index.md b/docusaurus/docs/learn/quickstarts/zac/index.md
index 268248f57..f8820616d 100644
--- a/docusaurus/docs/learn/quickstarts/zac/index.md
+++ b/docusaurus/docs/learn/quickstarts/zac/index.md
@@ -39,22 +39,22 @@ you can perform the following steps.
 
 1. Clone the ziti-console repo from github:
 
-   ```bash
+   ```
    git clone https://github.com/openziti/ziti-console.git "${ZITI_HOME}/ziti-console"
    ```
 
 1. Install Node modules:
 
-   ```bash
+   ```
    cd "${ZITI_HOME}/ziti-console"
    npm install
-   ````
+   ```
 
 1. Use the ziti-controller certificates for the Ziti Console:
 
    Link a server certificate into the `ziti-console` directory. Your web browser won't recognize it, but it's sufficient for this exercise to have server TLS for your ZAC session.
 
-   ```bash
+   ```
    ln -s "${ZITI_PKI}/${ZITI_CTRL_EDGE_NAME}-intermediate/certs/${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}-server.chain.pem" "${ZITI_HOME}/ziti-console/server.chain.pem"
    ln -s "${ZITI_PKI}/${ZITI_CTRL_EDGE_NAME}-intermediate/keys/${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}-server.key" "${ZITI_HOME}/ziti-console/server.key"
    ```
@@ -64,7 +64,7 @@ you can perform the following steps.
    you need to in order to get the necessary function. Either inspect the script and find the function, download and source it,
    or source it directly from the internet (direct sourcing from internet shown below)
 
-   ```bash
+   ```
    source /dev/stdin <<< "$(wget -qO- https://get.openziti.io/ziti-cli-functions.sh)"
    createZacSystemdFile
    sudo cp "${ZITI_HOME}/ziti-console.service" /etc/systemd/system
@@ -74,7 +74,7 @@ you can perform the following steps.
 
    If you do not have systemd installed or if you just wish to start ZAC you can simply issue:
 
-   ```bash
+   ```
    node "${ZITI_HOME}/ziti-console/server.js"
    Initializing TLS
    TLS initialized on port: 8443
@@ -84,7 +84,7 @@ you can perform the following steps.
 1. [Optional] If using systemd - verify the Ziti Console is running by running the systemctl command
    `sudo systemctl status ziti-console --lines=0 --no-pager`
 
-   ```bash
+   ```
    $ sudo systemctl status ziti-console --lines=0 --no-pager
     ● ziti-console.service - Ziti-Console
     Loaded: loaded (/etc/systemd/system/ziti-console.service; disabled; vendor preset: enabled)
@@ -109,7 +109,7 @@ the OpenZiti Network you can copy the certificates generated when the controller
 Shown is an example which copies the certs from the OpenZiti container and uses them with ZAC. We'll copy the files
 from the docker named volume `myPersistentZitiFiles` and put them into a folder at `$HOME/.ziti/zac-pki`.
 
-```bash
+```
 mkdir -p $HOME/.ziti/zac-pki
 
 docker run -it --rm --name temp \
@@ -129,7 +129,7 @@ With the certificates copied, you will be able to start the ZAC using one Docker
 will expose the ZAC http and https ports to your local computer so that you can access the ZAC from outside of Docker.
 If you customized any of these paths, you'll need to replace the paths specified accordingly (the '-v' lines).
 
- ```bash
+ ```
  docker run --rm \
         --name zac \
         -p 1408:1408 \
diff --git a/docusaurus/docs/reference/30-configuration/controller.md b/docusaurus/docs/reference/30-configuration/controller.md
index 33147c020..6d6230a48 100644
--- a/docusaurus/docs/reference/30-configuration/controller.md
+++ b/docusaurus/docs/reference/30-configuration/controller.md
@@ -49,7 +49,7 @@ services.
 
 Example Minimum Controller Configuration:
 
-```yaml
+```
 v: 3
 
 db: ctrl.db
@@ -103,14 +103,14 @@ This includes the protocol(s) used for router connections and how those connecti
 
 Example w/o options:
 
-```yaml
+```
 ctrl:
   listener: tls:127.0.0.1:6262
 ```
 
 Example w/ options:
 
-```yaml
+```
 ctrl:
   listener: tls:127.0.0.1:6262
   options:
@@ -128,7 +128,7 @@ or different drive. This section is required.
 
 Example:
 
-```yaml
+```
 db: /mnt/fast-drive/db/ctrl.db
 ```
 
@@ -146,7 +146,7 @@ The `edge` section also has the following subsections:
 
 Example Minimum Edge:
 
-```yaml
+```
 edge:
   enrollment:
     signingCert:
@@ -156,7 +156,7 @@ edge:
 
 Example Fully Defined:
 
-```yaml
+```
 edge:
   api:
     activityUpdateInterval: 90s
@@ -294,7 +294,7 @@ or `amqp`):
 
 Example JSON File Logger:
 
-```yaml
+```
 events:
   jsonLogger:
     subscriptions:
@@ -319,7 +319,7 @@ events:
 
 Example amqp Logger:
 
-```yaml
+```
 events:
   amqpLogger:
     subscriptions:
@@ -348,7 +348,7 @@ the [`health-checks` API](#web).
     - `timeout` - (optional, 15s) how long to wait for a transaction before timing out
     - `initialDelay` - (optional, 15s) how long to wait on startup before performing the first check
 
-```yaml
+```
 healthChecks:
   boltCheck:
     interval: 30s
@@ -417,7 +417,7 @@ careful consideration.
     - `path` - (required) the path to output the memprof data
     - `intervalMs` (optional, 15s) the frequency to output memprof data
 
-```yaml
+```
 profile:
   cpu:
     path: /home/user1/tmp/ctrl.cpu.pprof
@@ -464,7 +464,7 @@ The raft section enables running multiple controllers in a cluster.
   full snapshot. This is a cluster wide value and should be consistent across nodes in the cluster.
   Otherwise the value from the most recently started controller will win.
 
-```yaml
+```
 raft:
   bootstrapMembers:
     - tls:127.0.0.1:6262
@@ -494,7 +494,7 @@ environments without careful consideration.
 
 - `path` - (required) the file to output decoded messages to
 
-```yaml
+```
 trace:
   path: /var/opt/open.ziti.ctrl.trace
 ```
@@ -520,6 +520,6 @@ Each API may have their own options, but currently do not.
 The `v` section is used to detect if the version file is supported by the OpenZiti binary read it.
 The current and only supported value is "3".
 
-```yaml
+```
 v: 3
 ```
diff --git a/docusaurus/docs/reference/30-configuration/conventions.md b/docusaurus/docs/reference/30-configuration/conventions.md
index e35fd5141..bc4c78757 100644
--- a/docusaurus/docs/reference/30-configuration/conventions.md
+++ b/docusaurus/docs/reference/30-configuration/conventions.md
@@ -40,7 +40,7 @@ syntax `${VARIABLE}` is used.
 
 Example:
 
-```yaml
+```
 db: ${ZITI_DATA}/db/ctrl.db
 ```
 
@@ -85,7 +85,7 @@ present on the host machine. This allows for access to hardware backed private k
 
 Example Identity Section (Client & Server use same key):
 
-```yaml
+```
 identity:
   cert: "file:ctrl-client.cert.pem"
   server_cert: "pem:-----BEGIN CERTIFICATE-----\nMIIEtzCCAp+gAwIBAgICEA0wDQYJKoZIhvcNAQELBQAwgYsxCzAJBgNVBAYTAlVT..."
@@ -145,7 +145,7 @@ defined in code and exposed on multiple interfaces/networks through configuratio
 
 Example:
 
-```yaml
+```
 web:
   - name: all-apis-localhost
     bindPoints:
@@ -173,7 +173,7 @@ web:
 
 The structure of the `web` section is an array of API exposure options:
 
-```yaml
+```
 web:
   - name: API Exposure 1
     ...
diff --git a/docusaurus/docs/reference/30-configuration/router.md b/docusaurus/docs/reference/30-configuration/router.md
index 6641c831f..0907df305 100644
--- a/docusaurus/docs/reference/30-configuration/router.md
+++ b/docusaurus/docs/reference/30-configuration/router.md
@@ -62,7 +62,7 @@ on-ramp connections over the mesh.
 
 Example Minimum Router Configuration:
 
-```yaml
+```
 v: 3
 
 identity:
@@ -128,7 +128,7 @@ The `ctrl` section configures how the router will connect to the controller.
 
 Example:
 
-```yaml
+```
 ctrl:
   endpoint: tls:127.0.0.1:6262
 ```
@@ -156,7 +156,7 @@ routers at least one valid SAN must be provided.
 
 Example:
 
-```yaml
+```
 csr:
   country: US
   province: NC
@@ -185,7 +185,7 @@ is an array of objects that configures individual dialers specified by the prope
 
 Example:
 
-```yaml
+```
 dialers:
   - binding: binding1
     options:
@@ -217,7 +217,7 @@ fabric only" and
 
 Example:
 
-```yaml
+```
 edge: {}
 ```
 
@@ -253,7 +253,7 @@ a router.
 
 Example:
 
-```yaml
+```
 forwarder:
   latencyProbeInterval: 1000
 ```
@@ -279,7 +279,7 @@ status is available by exposing the `health-checks` API in the `web` section.
 
 Example:
 
-```yaml
+```
 healthChecks:
   ctrlPingCheck:
     interval: 30s
@@ -355,7 +355,7 @@ the [`transport` section](#transport). For both
 
 Example:
 
-```yaml
+```
 link:
   dialers:
     - binding: transport
@@ -381,7 +381,7 @@ client will use to connect to the listener.
 - `options` - (optional) options specified by the component specifically in addition to
   the [shared options](./conventions.md#xgress-options)
 
-```yaml
+```
 listeners:
   - binding: edge
     address: tls:0.0.0.0:3022
@@ -397,7 +397,7 @@ When generating a router configuration with `ziti create config router edge` the
 enabled with default mode `host`. This mode continually configures the router's tunnel to reverse
 proxy the list of services that are authorized by Bind Service Policy.
 
-```yaml
+```
 listeners:
   - binding: tunnel
     options:
@@ -409,7 +409,7 @@ will take effect when the router is restarted. For example, this configures the
 transparently proxy all services authorized by Dial Service Policy and provide a nameserver. This
 mode also enables the reverse proxy features of `host` mode.
 
-```yaml
+```
 listeners:
   - binding: tunnel
     options:
@@ -420,7 +420,7 @@ listeners:
 In this example the router's tunnel is configured to provide a forward proxy listener for a list of
 service, TCP port pairs. This mode also enables the reverse proxy features of `host` mode.
 
-```yaml
+```
 listeners:
   - binding: tunnel
     options:
@@ -440,7 +440,7 @@ The `metrics` section controls how metrics are communicated to the connection co
 - `intervalAgeThreshold` - (optional, 80s) how old a batch of metrics must be before it's eligible
   to be sent to the controller
 
-```yaml
+```
 metrics:
   reportInterval: 1m
   messageQueueSize: 10
@@ -454,7 +454,7 @@ without careful consideration.
 
 - `path` - (required) the file to output decoded messages to
 
-```yaml
+```
 trace:
   path: /var/opt/open.ziti.router.trace
 ```
@@ -465,7 +465,7 @@ The `transport` section is for advanced configuration of underlay protocols. It
 applies to an internally tuned TCP protocol named Transwarp and is tuned using `westworld3`
 configuration options. This section should largely be unnecessary outside of development.
 
-```yaml
+```
 transport:
   westworld3:
     profile_version: 1
@@ -492,7 +492,7 @@ careful consideration.
     - `path` - (required) the path to output the memprof data
     - `intervalMs` (optional) the frequency to output memprof data (default 15s)
 
-```yaml
+```
 profile:
   cpu:
     path: /home/user1/tmp/ctrl.cpu.pprof
@@ -516,6 +516,6 @@ Each API may have their own options, but currently do not.
 The `v` section is used to detect if the version file is supported by the OpenZiti binary read it.
 The current and only supported value is "3".
 
-```yaml
+```
 v: 3
 ```
diff --git a/docusaurus/docs/reference/deployments/02-router/01-deployment.md b/docusaurus/docs/reference/deployments/02-router/01-deployment.md
index 0d774c55b..22463a6e9 100644
--- a/docusaurus/docs/reference/deployments/02-router/01-deployment.md
+++ b/docusaurus/docs/reference/deployments/02-router/01-deployment.md
@@ -43,7 +43,7 @@ The router loads its configuration from a YAML file. You may use the `ziti creat
 
 The `identity.key` field in the config behaves differently for routers. If a file exists in the path indicated by `key` then the key will be used during router enrollment. If it does not exist then a unique key will be generated.
 
-```yaml
+```
 identity:
     cert:                 "~/.ziti/config/certs/router01.zitinetwork.example.org.cert"
     server_cert:          "~/.ziti/config/certs/router01.zitinetwork.example.org.server.chain.cert"
@@ -59,17 +59,17 @@ The life cycle of a router begins by calling the controller's management API to
 
 Creating a router yields a one-time enrollment token that you may store as a JWT file. Enrollment consumes the token and facilitates issuing a client certificate for the router, establishing cryptographic trust with the controller.
 
-```bash
+```
 ziti router enroll config.yaml --jwt token.jwt
 ```
 
 ### Run Router {#router-run}
 
-```bash
+```
 ziti router run config.yaml
 ```
 
-```ini
+```
 # /etc/systemd/system/ziti-router.service
 [Unit]
 Description=Ziti Router
diff --git a/docusaurus/docs/reference/deployments/02-router/02-configuration.md b/docusaurus/docs/reference/deployments/02-router/02-configuration.md
index 6d457a33d..80bb8e6c0 100644
--- a/docusaurus/docs/reference/deployments/02-router/02-configuration.md
+++ b/docusaurus/docs/reference/deployments/02-router/02-configuration.md
@@ -17,7 +17,7 @@ Commented out options with `#` tag are generated by the template but not used fo
 
 This is a network side dialing only router with edge. It does not listen for connections from other routers. Set environmental variables to match this type of deployment, and run the command shown.
 
-```bash
+```
 ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=controller01.zitinetwork.example.org
 ZITI_CTRL_ADVERTISED_PORT=80
 ZITI_ROUTER_ADVERTISED_ADDRESS="192.168.10.11"
@@ -37,7 +37,7 @@ ZITI_ROUTER_IDENTITY_CA="~/.ziti/config/certs/${ROUTER_NAME}.cas"
 
 ## Generated Configuration
 
-```yaml
+```
 v: 3
 
 identity:
@@ -115,7 +115,7 @@ forwarder:
 
 This is a network side dialing only router with edge and tunneler( i.e. gateway mode). It does not listen for connections from other routers. Set environmental variables to match this type of deployment, and run the command shown.
 
-```bash
+```
 ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=controller01.zitinetwork.example.org
 ZITI_CTRL_ADVERTISED_PORT=80
 ZITI_ROUTER_ADVERTISED_ADDRESS="192.168.10.11"
@@ -136,7 +136,7 @@ ZITI_ROUTER_IDENTITY_CA="~/.ziti/config/certs/${ROUTER_NAME}.cas"
 
 ## Generated Configuration
 
-```yaml
+```
 v: 3
 
 identity:
@@ -214,7 +214,7 @@ forwarder:
 
 This is a network side dialing and listening router with edge. It listens for connections from other routers. The host firewall needs to be opened to allow connections through. In this example code, the listen ports are 80 and 443. Set environmental variables to match this type of deployment, and run the command shown.
 
-```bash
+```
 ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=controller01.zitinetwork.example.org
 ZITI_CTRL_ADVERTISED_PORT=80
 ZITI_ROUTER_NAME=router01.zitinetwork.example.org
@@ -232,7 +232,7 @@ ZITI_ROUTER_IDENTITY_CA="~/.ziti/config/certs/${ROUTER_NAME}.cas"
 
 ## Generated Configuration
 
-```yaml
+```
 v: 3
 
 identity:
diff --git a/docusaurus/docs/reference/deployments/02-router/04-cli-mgmt.md b/docusaurus/docs/reference/deployments/02-router/04-cli-mgmt.md
index b5dba92c9..cb917d95e 100644
--- a/docusaurus/docs/reference/deployments/02-router/04-cli-mgmt.md
+++ b/docusaurus/docs/reference/deployments/02-router/04-cli-mgmt.md
@@ -27,7 +27,7 @@ The router creation command is described with the minimum required options to cr
 
 
 
-```bash
+```
 ziti edge create edge-router $ROUTER_NAME \
                             --jwt-output-file $ROUTER_NAME.jwt
 ```
@@ -40,7 +40,7 @@ ziti edge create edge-router $ROUTER_NAME \
 In other words, only connections destined for this router will be routed to it by the smart routing algorithm. `--tunneler-enabled or just -t` flag indicates the tunnel mode.
 :::
 
-```bash
+```
 ziti edge create edge-router $ROUTER_NAME \
                             --jwt-output-file $ROUTER_NAME.jwt \
                             --tunneler-enabled --no-traversal 
@@ -49,7 +49,7 @@ ziti edge create edge-router $ROUTER_NAME \
 
 
 
-```bash
+```
 ziti edge create edge-router $ROUTER_NAME \
                             --jwt-output-file $ROUTER_NAME.jwt
 ```
@@ -59,13 +59,13 @@ ziti edge create edge-router $ROUTER_NAME \
 
 ### List Routers
 
-```bash
+```
 ziti edge list edge-routers
 ```
 
 ### Delete Router
 
-```bash
+```
 ziti edge delete edge-routers $ROUTER_NAME
 ziti edge delete edge-routers $ROUTER_ID
 ```
@@ -74,7 +74,7 @@ ziti edge delete edge-routers $ROUTER_ID
 
 For the more detail options list, please refer to the [Flags Section](#flags).
 
-```bash
+```
 ziti edge update edge-router $ROUTER_NAME [flags]
 ziti edge update edge-router $ROUTER_ID [flags]
 ```
@@ -83,27 +83,27 @@ ziti edge update edge-router $ROUTER_ID [flags]
 
 - App-Data can be used to set key/value pair to be used in addressable terminator service for example.
 
-```bash
+```
 --app-data stringToString   Custom application data (default [])
 --app-data "fqdn"="aksprod-cae02995.eastus2.azmk8s.io"
 ```
 
 - Router cost can be used to influence the smart routing to not use this router for service traversal unless no other paths are available.
 
-```bash
+```
 --cost uint16               Specifies the router cost. Default 0.
 --cost 300
 ```
 
 - No-traversal flag means no service traversal through this router at all. Only the service termination or origination can be completed on it.
 
-```bash
+```
 --no-traversal              Disallow traversal for this edge router. Default to allowed(false).
 ```
 
 - The role attribute flag allows to set a list of attributes that can be referenced by all policies for dialing and/or hosting services.
 
-```bash
+```
 -a, --role-attributes strings   Set role attributes of the edge router. Use --role-attributes '' to set an empty list
  --role-attributes 'example,example2,example3'
 ```
diff --git a/docusaurus/docs/reference/developer/api/index.md b/docusaurus/docs/reference/developer/api/index.md
index b242bb5a7..8aa5b4e3f 100644
--- a/docusaurus/docs/reference/developer/api/index.md
+++ b/docusaurus/docs/reference/developer/api/index.md
@@ -23,7 +23,7 @@ It is essential to build your application with respect to the specification of y
 
 `GET /`
 
-```json
+```
 {
     "data": {
         "apiVersions": {
@@ -85,7 +85,7 @@ APIs, Edge Client and Management included, to listen on any combination of netwo
 
 #### Example Controller Edge Configuration Section {#edge-configuration-section}
 
-```yaml
+```
 edge:
   api:
     #(optional, default 90s) Alters how frequently heartbeat and last activity values are persisted
@@ -132,7 +132,7 @@ The `web` section of the controller is based off of the [xweb](https://github.co
 a single configuration section to be used to compose multiple APIs across any number of network interfaces. Understanding
 the xweb configuration format is essential for success with configuring the `web` section in the controller.
 
-```yaml
+```
 # web - optional
 # Defines webListeners that will be hosted by the controller. Each webListener can host many APIs and be bound to many
 # bind points.
diff --git a/docusaurus/docs/reference/developer/api/shared-api-capabilities.md b/docusaurus/docs/reference/developer/api/shared-api-capabilities.md
index 60cd66ee3..2cacf5ea5 100644
--- a/docusaurus/docs/reference/developer/api/shared-api-capabilities.md
+++ b/docusaurus/docs/reference/developer/api/shared-api-capabilities.md
@@ -4,7 +4,7 @@
 
 All responses from APIs have the following outer envelope:
 
-```json
+```
 {
   "data": ...,
   "meta": {...},
@@ -18,7 +18,7 @@ information about the requested entity that may be useful to clients (e.g. pagin
 
 The `error` section contains errors in the following format:
 
-```json
+```
 {
   "code": "string constant error code",
   "message": "string human readable value",
@@ -28,7 +28,7 @@ The `error` section contains errors in the following format:
 
 The `cause` field can either be another nested `error` or a `field error`:
 
-```json
+```
 {
   "field": "the name of the field",
   "reason": "a message explaining the issue",
diff --git a/docusaurus/docs/reference/tunnelers/linux/index.md b/docusaurus/docs/reference/tunnelers/linux/index.md
index 9c5913325..e0048e03f 100644
--- a/docusaurus/docs/reference/tunnelers/linux/index.md
+++ b/docusaurus/docs/reference/tunnelers/linux/index.md
@@ -53,7 +53,7 @@ Architectures available:
 Please read this script to ensure it is safe before running it.
 :::
 
-```bash
+```
 curl -sSLf https://get.openziti.io/tun/scripts/install-ubuntu.bash | bash
 ```
 
@@ -72,7 +72,7 @@ curl -sSLf https://get.openziti.io/tun/scripts/install-ubuntu.bash | bash
 
 This example subscribes you to the Ubuntu `focal` repo which will work well in most cases. Alternatively, you may refer to the table to find the Ubuntu release name that is the contemporary of your Debian release. Then, substitute the Ubuntu release name for `focal` in the `/etc/apt/sources.list.d/openziti.list` file.
 
-```bash
+```
 (
 set -euo pipefail
 
@@ -93,20 +93,20 @@ sudo apt install ziti-edge-tunnel
 2. Place a copy of the enrollment token JWT file in the `/opt/openziti/etc/identities` directory.
 2. Set the filemode and owner so that members of group `ziti` will be able to read and delete the token file.
 
-  ```bash
+  ```
   sudo chown -cR :ziti        /opt/openziti/etc/identities
   sudo chmod -cR ug=rwX,o-rwx /opt/openziti/etc/identities
   ```
 
 2. Enable and start the service
 
-    ```bash
+    ```
     sudo systemctl enable --now ziti-edge-tunnel.service
     ```
 
 2. The process needs to be restarted if the contents of `/opt/openziti/etc/identities` change.
 
-    ```bash
+    ```
     sudo systemctl restart ziti-edge-tunnel.service
     ```
 
@@ -132,7 +132,7 @@ Architectures available:
 
 Use this repo with var `$releasever` on CentOS 7, Rocky 8-9, and RHEL 7-9.
 
-```ini
+```
 [OpenZiti]
 name=OpenZiti
 baseurl=https://packages.openziti.org/zitipax-openziti-rpm-stable/redhat$releasever/$basearch
@@ -152,7 +152,7 @@ Architectures available:
 
 * x86_64
 
-```ini
+```
 [OpenZiti]
 name=OpenZiti
 baseurl=https://packages.openziti.org/zitipax-openziti-rpm-stable/redhat8/$basearch
@@ -172,7 +172,7 @@ Architectures available:
 
 * x86_64
 
-```ini
+```
 [OpenZiti]
 name=OpenZiti
 baseurl=https://packages.openziti.org/zitipax-openziti-rpm-stable/redhat8/$basearch
@@ -190,20 +190,20 @@ repo_gpgcheck=1
 2. Place a copy of the enrollment token JWT file in the `/opt/openziti/etc/identities` directory.
 2. Set the filemode and owner so that members of group `ziti` will be able to read and delete the token file.
 
-  ```bash
+  ```
   sudo chown -cR :ziti        /opt/openziti/etc/identities
   sudo chmod -cR ug=rwX,o-rwx /opt/openziti/etc/identities
   ```
 
 2. Enable and start the service
 
-    ```bash
+    ```
     sudo systemctl enable --now ziti-edge-tunnel.service
     ```
 
 2. The process needs to be restarted if the contents of `/opt/openziti/etc/identities` change.
 
-    ```bash
+    ```
     sudo systemctl restart ziti-edge-tunnel.service
     ```
 
@@ -213,7 +213,7 @@ repo_gpgcheck=1
 
 You'll need to install the `wget` and `unzip` commands to use this example.
 
-```bash
+```
 wget -q "https://github.com/openziti/ziti-tunnel-sdk-c/releases/latest/download/ziti-edge-tunnel-Linux_$(uname -p).zip" \
   && unzip ./ziti-edge-tunnel-Linux_$(uname -p).zip \
   && rm ./ziti-edge-tunnel-Linux_$(uname -p).zip \
@@ -229,7 +229,7 @@ You will need the token file or its contents to enroll. Enrollment is the act of
 
 ### Run the Manually Installed Binary
 
-```bash
+```
 ziti-edge-tunnel run \
   --identity-dir /opt/openziti/etc/identities
 ```
diff --git a/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-options.md b/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-options.md
index 394883e9d..8f1a065b8 100644
--- a/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-options.md
+++ b/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-options.md
@@ -15,22 +15,22 @@ For more information about configuring the underlying Ziti C SDK with environmen
 
 You can start `ziti-edge-tunnel` with different options, some of the most commonly used options are listed below.
 
-```bash
+```
 # Load a single identity.
 --identity 
 ```
 
-```bash
+```
 # Load all identities in a dir, ignoring files with a .bak or .original filename suffix.
 --identity-dir 
 ```
 
-```bash
+```
 # Set log level, higher is more verbose (default level 3 means INFO).
 --verbose N
 ```
 
-```bash
+```
 # Set service polling interval in seconds (default 10).
 --refresh N
 ```
@@ -46,14 +46,14 @@ There are two run modes:
 
 `ziti-edge-tunnel run` provides a transparent proxy and nameserver. The nameserver may be configured to be authoritative (the default) or recursive with command-line option `--dns-upstream`. `systemd-resolved`, if enabled, automatically configures the Ziti nameserver. You may inspect the configuration with these commands.
 
-```bash
+```
 resolvectl dns     # inspect the association of tun device and nameserver
 resolvectl domain  # inspect the configuration of query routing domains
 ```
 
 If any interface has a wildcard routing domain configured, `ziti-edge-tunnel` will also configure its tun with a wildcard routing domain. If no other interface has a wildcard routing domain configured, neither will the `ziti-edge-tunnel` tun.
 
-```bash
+```
 # Specify the tun interface address and the subnet to which Service domain names are resolved (default 100.64.0.1/10). The nameserver address is always the tun interface address +1, default is 100.64.0.2.
 --dns-ip-range 
 ```
diff --git a/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-troubleshooting.md b/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-troubleshooting.md
index f143d7698..bac8c195d 100644
--- a/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-troubleshooting.md
+++ b/docusaurus/docs/reference/tunnelers/linux/linux-tunnel-troubleshooting.md
@@ -11,13 +11,13 @@ The simplest step you can take toward a diagnosis is to reduce the minimum messa
 
 If you change your package repo subscription or install the same DEB or RPM package from another source, excluding normal upgrades and downgrades, then it may be necessary to reload the systemd service unit definitions:
 
-  ```bash
+  ```
   sudo systemctl daemon-reload
   ```
 
 You may read the logs in the systemd journal.
 
-```bash
+```
 journalctl -xeu ziti-edge-tunnel.service
 ```
 
@@ -25,12 +25,12 @@ journalctl -xeu ziti-edge-tunnel.service
 
 You may inspect the loaded identity and router info for a running `ziti-edge-tunnel` by dumping it to stdout or the systemd journal with an IPC command, or you may signal to dump the identities' info to a file.
 
-  ```bash
+  ```
   # dump identities info to std our journal if systemd unit with IPC command
   ./ziti-edge-tunnel dump
   ```
 
-  ```bash
+  ```
   # dump identities info to a file and inspect
   sudo pkill -USR1 -f ziti-edge-tunnel
   less /tmp/ziti-dump.964315.dump
@@ -42,7 +42,7 @@ If the tunneller is crashing then it may be crucial to collect and analyze the c
 
   You can see how dump files are handled by inspecting this file, which is from Ubuntu 20.10.
 
-  ```bash
+  ```
   $ cat /proc/sys/kernel/core_pattern
   |/usr/share/apport/apport %p %s %c %d %P %E
   ```