openziti / helm-charts

various helm charts for openziti-test-kitchen projects

OpenZiti Helm Charts

This is a repository of Helm charts for use with OpenZiti on Kubernetes.

These files are published from a GitHub repo as a GitHub pages site here.

Use this Repo

Subscribe

$ helm repo add openziti https://docs.openziti.io/helm-charts/
"openziti" has been added to your repositories

Chart Highlights

Charts for Workloads

These charts help cluster workloads access or provide a Ziti service.

• ziti-host: Ziti tunnel pod for hosting services (ingress only)
• ziti-edge-tunnel: Ziti tunnel daemonset for accessing services (intercept node egress)

Charts for Self-Hosting Ziti

• ziti-controller
• ziti-router

Charts that Deploy a Ziti-enabled Application

• httpbin: Ziti fork of the REST testing server
• prometheus: Ziti fork of Prometheus
• reflect: A Ziti original. This app echoes the bytes it receives and is useful for testing Ziti.

Maintainers

This repo uses GitHub Actions to automate the following tasks:

1. Generate Helm docs for each chart in the repo.
2. Package and index the charts and publish the new Helm repo index and READMEs to GitHub Pages.
3. Label pull requests for generating release notes (label notes-ignore excludes a PR from notes)

Troubleshooting a Missing Chart

In case a chart release is missing from the Helm index, you can run the following commands to resolve the issue locally.

For this example, support the httpbin chart release version 0.1.2 exists in GitHub, but is missing from the Helm index. The solution is to run Chart Releaser locally to package and index the chart.

git checkout gh-pages
cr package ./charts/httpbin
cr index --owner openziti --git-repo helm-charts --index-path .

Contribute

1. Clone this repo.
2. Optionally, to customize the auto-generated README.md file, add a helm-docs template named README.md.gotmpl in the chart directory.
3. Wait for GitHub bot to generate Helm docs in your branch, or run helm-docs --chart-search-root ./charts/my-new-chart/ locally
4. Send PR targeting main.
5. Wait for GitHub bot to bump chart versions if necessary, i.e., if anything in the chart dir changed since latest tag and the chart version is already released.
6. Merging to main runs GitHub Actions to package and index the charts and publish the new Helm repo index and READMEs to GitHub Pages.

You may verify changes are present in the Helm index: https://docs.openziti.io/helm-charts/index.yaml.

helm-charts's Issues

.github/workflows/deploy.yml is never triggered

name: Deploy

on:
  push:
    branches:
      - master

The only trigger is a push to branch master which does not exist.

prometheus servicemonitor

The Prometheus Operator needs a ServiceMonitor resource to know where to scrape Ziti metrics. In the controller chart, provide appropriate labels and match selectors and the ServiceMonitor resource if Prometheus is enabled with a boolean value.

auto-bump charts' app version when releases drop

enable cert auth for default admin

https://openziti.discourse.group/t/admin-life-cycle-from-password-to-long-lived-cert/1127/7?u=qrkourier

browZer support - 3rd party server certs for controller

This enables the controller to handle edge requests from agentless browZer clients which are never pre-configured with a trust bundle, and only trust 3rd party server certs.

It's a feature of the controller to present an alternative server cert when the edge client is requested by a distinctive domain name (SNI selected).

This issue tracks progress on this piece of the browZer puzzle, and is only necessary because no one has yet used browZer with a Ziti network controller hosted in K8s.

Resolving this issue may be as simple as documenting a way to configure the controller's alt certs with Helm input values.

This is related to the router issue to support browZer.

update this project's description and homepage

These are no longer accurate for this project:

various helm charts for openziti-test-kitchen projects
docs.openziti.io/helm-charts/

Integration with External Secrets Operator

As we want to define the admin credentials for the OpenZiti controller in AWS Secret Manager and sync them to EKS using the ESO, we need an option to specify the name of the secret, which the helm chart should refer to for the admin credentials - instead of creating the secret on its own.

In general we favor the approach of generating secrets out of the cluster with cryptographically secure password generators - like using the AWS Secret Managers https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetRandomPassword.html method :)

controller deployment times out waiting for ready

There must be a problem with the latest controller chart version because miniziti always times out waiting for the deployment to be ready.

install the latest zrok chart as a testing baseline

It was necessary to comment out the zrok baseline in the miniziti.yml workflow because needed bugfixes existed only in a branch. This is a reminder to resume installing the latest released zrok chart first as a baseline, then to upgrade with the checked out branch, then run tests.

draft release notes

Add a changelog to each release, e.g., with the Release Drafter Action.

add CI test for the node proxy daemonset chart

#130 introduces a daemonset chart to provide a node proxy using ziti-edge-tunnel. We need to deploy this chart in the minikube cluster in CI and exercise a service through the node proxy.

test charts' renderings for coherence per type of deployment

There's little assurance that the charts' renderings are coherent for a given set of input values. The current minikube test assures only that helm upgrade succeeds for a single set of input values.

This limited test doesn't protect against rending invalid manifests for a different set of input values. For example, the minikube test specifies ingress resources for the nginx controller, but another valid set of input values that does not use ingress at all may still render as an invalid configuration.

The CUE framework seems to have what we'd need to enforce a spec for a particular manifest, possibly a set of manifests, and a higher-level tool that leverages CUE is https://timoni.sh/ and may be worth looking at.

I found Timoni mentioned in Reddit: https://www.reddit.com/r/kubernetes/comments/1be15b8/comment/kuu6bco/?utm_source=share&utm_medium=web2x&context=3 in the context of a discussion about the disadvantages of templating YAML manifests with Helm.

Any work we do in this area must be transferable to a future where an OpenZiti Operator is generating manifests, supplying input values to Helm, or both.

feature request: Create a ziti-stack helm chart

Hi @qrkourier,

It would be beneficial having a stack Helm chart which configures the complete OpenZiti stack at once instead of defining every Helm release separately.
This is the best approach which would simplify the deployment massively. One could define a chart Meta-Version which define a version bundle for ziti-console, ziti-controller, ziti-router which can be tested to be working well together, similar to what kube-prometheus-stack does for a prometheus environment.

zrok chart is non-functional

Based on commit history and the current state of main, this chart appears to be right in the middle of a refactor. From what I gather, everything is in the process of being separated into separate controller/frontend files. I knocked out about five issues just to see if I could get it going but I would need to understand some intent before proceeding.

Also, I don't want to do a bunch of work if someone has already continued further than what's represented in the github repo.

Is it possible to get status on this? If I can get a braindump of the desired direction, I'd help finish up the work.

Simplify adding args like --verbose

Add an input like additionalArgs to simplify passing command line flags like --verbose to ziti deployments and tunnelers

browZer support - router WebSocket edge binding

Ziti Router can provide a wss:// listener for browZer clients. Improve the router chart to support this feature and provide a config sample or guide in the chart README so it'll be auto-published in Ziti docs.

Helm chart for `ziti-edge-tunnel run` transparent proxy

Hi,
I would like to ask if you are interested about having a new helm chart here for my use case. I need openziti/ziti-edge-tunnel running as DaemonSet, aka. transparent proxy modus or ziti-edge-tunnel run.

Let me know your thoughts! If yes, I would be submitting a PR soon.

Thank you!

controller chart: trust-manager ClusterRole name collision

It would be helpful to have the ability to install a dedicated trust-manager with the ziti-controller because trust-manager can only have one "trusted namespace", and it needs to either be inside the same namespace as the controller or be configured to trust the controller's namespace. The trust-manager chart always creates a ClusterRole named "trust-manager", but it might be possible to override

{{ include "trust-manager.name" . }}

in https://github.com/cert-manager/trust-manager/blob/main/deploy/charts/trust-manager/templates/clusterrole.yaml#L6

ziti-router - fresh install fails

Hi,

I just tried to install a new ziti-router instance on a fresh node, but the Helm installation failed:

Helm release "openziti/core-router" was created, but failed to initialize completely. Use Helm CLI to investigate.: failed to become available within allocated timeout. Error: Helm Release openziti/core-router: context deadline exceeded

I started digging into it a bit, and from what I see:

• The router pod for the deployment is stuck in ContrainerCreating state due to:

  Warning  FailedMount  5s (x15 over 14m)    kubelet            MountVolume.SetUp failed for volume "ziti-router-identity" : secret "core-router-identity" not found

• From what I understand there is a post-install hook here https://github.com/openziti/helm-charts/blob/main/charts/ziti-router/templates/post-install-hook.yaml responsible for creating the -identity secret

AFAIK the post-install hook get's executed after all other resources are created and ready - but the deployment won't get ready as it's missing the secret. A chicken/egg issue?

trust-manager Bundle only has root CAs

Ziti needs a bundle of trust chains so it can publish well-known certs to edge clients. There's a bug in the Helm chart template that causes the bundle to contain only root CAs, not the intermediate CAs that issue leaf cert. These are needed too.

The reason is that cert-manager concatenates the issuer cert chain in the tls.crt key of the K8s Secret where key and cert material are strored, and always places the root CA in ca.crt. I mistakenly believed the ca.crt key in a leaf cert's K8s Secret would contain its issuer's cert, but in fact it is the root CA's cert.

The solution is to refactor the Bundle resource template that is used to compose the trust bundle that's mounted on the path referenced in the controller config property identity.ca.

Specifically, the Bundle resource needs to aggregate the tls.crt key from each issuer instead of aggregating ca.crt from the leaf and intermediate as it does currently.

optionally create a router when deploying the controller

It's highly likely that a controller deployment is immediately followed by a router deployment. We can simplify and facilitate this by automatically provisioning a router in the Ziti mgmt API and storing the token as a K8s secret.

The implementation will involve Helm hooks and simple shell scripts to be executed by the resulting Job resources that are scheduled during life cycle events.

trust-manager trust namespace must align with controller namespace

This necessary alignment presents a pitfall encountered at least once in #133

The requirement is that trust-manager must have exactly one namespace from which it sources secrets and configmaps to compose Bundle resources, so that namespace must be the one where ziti-controller is installed.

The solution is probably a template check that will fail during Helm release upgrade/install when the following conditions are met:

1. trust-manager sub-chart is enabled
2. the trust-manager trust namespace property does not exactly match the controller's namespace

implement zrok tls

The next zrok release can terminate TLS on the controller API/GUI and frontend.

Test as is or add the necessary input values and template conditionals to express that zrok should use a certificate provided by an issuer like Cert Manager.

Adding a CM annotation to zrok's ingress will cause the certificate to be issued, but zrok's deployments need to mount the cert when it becomes available and the zrok configs needs to use the tls: prefix and source the appropriate file paths.

https://github.com/openziti/zrok/blob/v0.4.23/CHANGELOG.md?plain=1#L11

install Cert Manager's CRDs with a Helm pre hook

The controller chart depends on Cert Manager and Trust Manager CRDs, e.g., Issuer, Certificate, and Bundle. It's currently necessary to pre-install the CRDs because sub-charts can not provide the CRDs that a parent chart requires.

Add a controller pre (install, upgrade) hook that installs required CRDs and API versions unless installed and compatible.

This needs to be done for CM and TM unless related: #196 is completed to eliminate the TM dependency.

handle enrollment with identity from SPIRE agent

We need to know the best way to inject an identity from SPIRE to a pod. One way is to run spire-agent in the container. There may be a SPIRE Operator we can use.

Once the best way is identified we need to handle that identity during ziti-host pod startup to establish a pattern for charts that represent an endpoint (SDK or tunneler).

This could mean conditionally performing the external CA enrollment with the external CA JWT and the cert and key provided by SPIRE.

add health checks to controller and router charts

K8s will use each type of probe if we make them available. A successful probe means:

1. startup: the app is finished starting up, go ahead and try the readiness probe
2. readiness: the app is ready to receive incoming requests, tell the LB to begin forwarding to the pod
3. liveness: the app is healthy and still has capacity for more requests, keep sending and don't restart me right now

Ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

zrok - create a default user account

zrok has a new feature for administratively creating an account.

This issue tracks changing the chart to create an account "default" and saving the enable token in a k8s secret.

❯ ./dist/amd64/linux/zrok admin create account
Error: accepts 3 arg(s), received 0
Usage:
  zrok admin create account <configPath}> <email> <password> [flags]

Flags:
  -h, --help   help for account

Global Flags:
  -p, --panic     Panic instead of showing pretty errors
  -v, --verbose   Enable verbose logging

[ERROR]: an error occurred (accepts 3 arg(s), received 0)

Update controller chart options to use single port for deployment

To use single port to utilize ALPN protocol. Here is what I did to use the existing options to get it working

clientApi:
  advertisedHost: ctrl-hm.dariuszski.dev
  advertisedPort: 443
  containerPort: 8443
  service:
    type: ClusterIP
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      kubernetes.io/ingress.allow-http: "false"
      nginx.ingress.kubernetes.io/ssl-passthrough: "true"
webBindingPki:
  enabled: false
managementApi:
  advertisedHost: ctrl-hm.dariuszski.dev
  service:
    enabled: false
  containerPort: 8443
ctrlPlane:
  advertisedHost: ctrl-hm.dariuszski.dev
  service:
    enabled: false
  containerPort: 8433

I get the following error, so I think the options can be optimized not to have to configure 3 different container ports.

$helm install  --namespace ziti ctrl-hm     openziti/ziti-controller     --values ./controller-values.yaml --kube-context $CLUSTER3 --set image.tag=0.34.1
**W0329 14:58:24.195672    9319 warnings.go:70] spec.template.spec.containers[0].ports[2]: duplicate port definition with spec.template.spec.containers[0].ports[0]**
NAME: ctrl-hm
LAST DEPLOYED: Fri Mar 29 14:58:21 2024
NAMESPACE: ziti
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
This is the first install of release ctrl-hm.


You have chart version 0.8.3 and app version 0.32.2.

To learn more about the release, try:

  $ helm status ctrl-hm -n ziti
  $ helm get all ctrl-hm -n ziti

  This deployment provides an OpenZiti controller to manage an OpenZiti network.

add a chart for openziti/go-httpbin

Make gh-pages branch lightweight

Hi @qrkourier,

I found out the gh-pages branch here is a clone of the main branch, but actually it is not necessary, and only needs to have the index.yaml, and the README.md file. OTOH, the index.yaml does not need to be present at main.

(ziti-controller/templates/configmap.yaml:276): unexpected ")" in command

We have this error from helm deploying ziti-controller: (ziti-controller/templates/configmap.yaml:276): unexpected ")" in command

I checked it and we have this right parenthesis a little weird in line 276 and 339

address: {{ .Values.managementApi.advertisedHost | default printf "%s-mgmt.%s.svc.%s" .Release.Name .Release.Namespace .Values.ca.clusterDomain)

ziti-* charts

The features I'm requesting are generally useful for anyone that might use this helm chart, but we specifically need them for incorporating a Spire setup into Ziti.
We need to be able to set the following values in each ziti-* helm chart.

• image repository
• image name
• image tag
• an optional image SHA
• imagePullSecrets
• extra volumes
• volume mounts

replace Trust Manager's Bundle CRD dependency with new K8s built-in ClusterTrustBundle

refs:

• https://kubernetes.io/docs/concepts/storage/projected-volumes/#clustertrustbundle
• #112 (comment)

handle router client cert renewal

Ziti router automatically renews its client certificate but can not save the file because the certificate lives in a read-only file mount from a K8s secret.

Possible solutions include:

• guidance for treating routers as cattle and orchestrating a helm install with new enrollment more often than client certs expire
• a Kubernetes Controller or life cycle hook that updates the K8s secret with new client cert

Relevant discussion and controller architecture sketch in GitHub issue: openziti/ziti#993 (comment)

ziti edge login options are changing

Update the zitiLogin script mounted on the controller container to use the new option for specifying the trusted certificate bundle.

ref: #103

The Ziti Controller Helm Chart Hangs During Install

I started playing with the helm charts, and I tried to install the ziti-controller.

Unfortunately, the initContainer never succeeds, but hangs on a configmap:

MountVolume.SetUp failed for volume "ziti-controller-ctrl-plane-cas" : configmap "ziti-controller-ctrl-plane-cas" not found

I installed the chart with this command:

helm upgrade --install ziti-controller openziti/ziti-controller --namespace ziti-controller --create-namespace --values values.yaml

install the miniziti test script from new location

miniziti.bash has moved to https://github.com/openziti/ziti/blob/release-next/quickstart/kubernetes/miniziti.bash and this repo's "deploy this branch's charts to minikube" will start consuming the quickstart release version from a stable, shortened URL like https://get.openziti.io/qs/kubernetes/miniziti.bash.

Helm life-cycle hooks/Jobs not run

Are you perchance wrapping helm CLI with a something like an Ansible module or TF provider? I've noticed that some wrappers do not fire the hooks unless wait=false, which is not intuitive, and I don't understand why this is necessary. There is a long-running GitHub issue about it.

The workaround is to unset wait and atomic when creating or upgrading the Helm Release. The helm CLI default settings seem to work fine, but when wrapping Helm I've noticed that hooks don't fire without the additional setting. Let me know if you have any ideas for making this more robust.

EDIT: It's starting to make sense why we're seeing what we're seeing. The default for Helm CLI is wait=false, and post-install and post-upgrade don't run when wait=true. It's because those Jobs are only scheduled after the main app pod is "ready," which can't happen until after those Jobs run, so it's a pickle. Maybe those hooks need to be pre-install and pre-upgrade. I don't recall now what forced me to use post-x at the time, but the constraint may have only applied to certain charts, not all. I'll investigate.

re: forum topic - https://openziti.discourse.group/t/deploying-router-on-k8s-via-helm-gives-identity-secret-mount-error/1795/7

configmap "ziti-controller-ctrl-plane-cas" not found in ziti-controller-0.2.6

After upgrading ziti-controller from 0.2.4 to 0.2.6, the ziti-controller pod did not start up:

  Warning  FailedMount  32s (x8 over 95s)  kubelet            MountVolume.SetUp failed for volume "ziti-controller-ctrl-plane-cas" : configmap "ziti-controller-ctrl-plane-cas" not found

Reason was that the "Bundle" object created with trust-manager had the following "target" configuration:

  target:
    configMap:
      key: ctrl-plane-cas.crt
    namespaceSelector:
      matchLabels:
        openziti.io/namespace: enabled

...when no namespace was labeled with this label/value pair. I manually, as a workaround did this:

kubectl label ns openziti openziti.io/namespace=enabled

Than the configmap was created immediately, and ziti-router started just fine.

As a solution for this, should the values.yaml be changed to contain something like this?

trust-manager:
  # -- install the trust-manager subchart to provide CRD Bundle
  enabled: false
  app:
    trust:
      # -- trust-manager needs to be configured to trust the namespace in which
      # the controller is deployed so that it will create the Bundle resource
      # for the ctrl plane trust bundle
      namespaceSelector:
        kubernetes.io/metadata.name: openziti

and template this into the currently hardcoded section of templates/ca-bundle.yaml? Currently, in ca-bundle.yaml there is the label selector hardcoded, and the values' trust-manager.app.trust.namespace is not being used anywhere in the templates. Seems it has been left over in one of the latest commits.

support Gateway API

The so-called "Ingress v2" is the K8s Gateway API (v1beta1). The chart should remain agnostic to the passthrough ingress provider. A sample K8s manifest and Helm values files demonstrating how to deploy the OpenZiti Controller behind a Gateway would be helpful.

stop binding "fabric" to the mgmt web listener

Ziti controller will merge the fabric mgmt and edge mgmt web bindings. When this happens the controller chart should stop binding "fabric" to the mgmt web listener.

Operator feature: orchestrate link groups by cluster horizon

The new router link groups feature enables a topology like this, spanning the fabric across clusters via their Ingress to Ziti routers that are dual-homed in both a public and cluster-internal link group.

The result is a resilient, efficient Ziti fabric inside each cluster, probably one router per node, and a scaled set of "public" routers that are advertising two link listeners each: one public, one cluster-internal.

Current trust-bundle (ca-bundle.yaml) produces duplicate root CA entries

Currently, the ca-bundle has duplicate entries for each Root CA.

openssl storeutl -noout -text -certs ctrl-plane-cas.crt
0: Certificate
Certificate:
    Data:
        ...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ziti-controller-ctrl-plane-root
        Validity
            Not Before: Jun 30 12:36:32 2023 GMT
            Not After : Jul  7 12:36:32 2033 GMT
        Subject: CN=ziti-controller-ctrl-plane-root
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
    ...
    Signature Algorithm: ecdsa-with-SHA256
	...
1: Certificate
Certificate:
    Data:
        ...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ziti-controller-ctrl-plane-root
        Validity
            Not Before: Jun 30 12:36:32 2023 GMT
            Not After : Jul  7 12:36:32 2033 GMT
        Subject: CN=ziti-controller-ctrl-plane-root
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
    ...            
    Signature Algorithm: ecdsa-with-SHA256
	...
2: Certificate
Certificate:
    Data:
        ...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=tds-openziti-base-controller-edge-root
        Validity
            Not Before: Jun 30 12:36:34 2023 GMT
            Not After : Jul  7 12:36:34 2033 GMT
        Subject: CN=tds-openziti-base-controller-edge-root
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
    ...
    Signature Algorithm: ecdsa-with-SHA256
3: Certificate
Certificate:
    Data:
        ...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=tds-openziti-base-controller-edge-root
        Validity
            Not Before: Jun 30 12:36:34 2023 GMT
            Not After : Jul  7 12:36:34 2033 GMT
        Subject: CN=tds-openziti-base-controller-edge-root
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
    ...            
    Signature Algorithm: ecdsa-with-SHA256
	...
4: Certificate
Certificate:
    Data:
        ...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ziti-controller-web-root
        Validity
            Not Before: Jun 30 12:36:32 2023 GMT
            Not After : Jul  7 12:36:32 2033 GMT
        Subject: CN=ziti-controller-web-root
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
    ...
    Signature Algorithm: ecdsa-with-SHA256
    ...
5: Certificate
Certificate:
    Data:
       ...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ziti-controller-web-root
        Validity
            Not Before: Jun 30 12:36:32 2023 GMT
            Not After : Jul  7 12:36:32 2033 GMT
        Subject: CN=ziti-controller-web-root
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
    ...
    Signature Algorithm: ecdsa-with-SHA256
    ...
Total found: 6

Solution:
Remove the following secrets from the trust-bundle:

• secret:
  name: {{ include "ziti-controller.fullname" . }}-ctrl-plane-identity-secret
  key: ca.crt
• secret:
  name: {{ include "ziti-controller.fullname" . }}-web-identity-secret
  key: ca.crt
• secret:
  name: {{ include "ziti-controller.fullname" . }}-admin-client-secret
  key: ca.crt

Also it would be good to directly include the root certs and not the intermediate ones - although this produces the same output , but it improves readability and clarity a lot. So the outcome would be that there are just the Root CA certs for ctrl-plane, web-identity and edge-signing.

GitHub pages index.html failed to update after merge to main

I expected to see my changes in https://openziti-test-kitchen.github.io/helm-charts/ after merging to main. The Actions succeeded including the GitHub Pages bot publishing action.

consider adding enrollment life cycle hooks to node proxy daemonset chart

ziti-edge-tunnel chart requires an enrolled identity, and it would simplify orchestration if a JWT could be supplied instead. Consider adding Helm life cycle hooks to handle enrollment and creating a Secret resource for the private key, at least. The schema of a JSON identity file allows for a file:// URI (or absolute path without URI scheme) for any of key, cert, or ca bundle. The key could be referenced at a mount point representing the K8s Secret, and the JSON file itself could live in a PVC. That way, the tunnel process would have the option to renew the certificate and rewrite the JSON file, which wouldn't contain any secrets.

#130

move non-variable values to named templates

Some Helm chart values should have been named templates instead of values. The difference is that values are variables that you can set when you create a release, i.e. install the chart, whereas named templates are set automatically.

For example, in the ziti-controller chart, there are a bunch of variables/values like these that never need to be set:

# -- a directory included in the init and run containers' executable search path
execMountDir:   /usr/local/bin   # read-only mountpoint for executables (must be in image's executable search PATH) 
# -- exec by init container
initScriptFile: ziti-controller-init.bash
# -- admin profile script file
zitiLoginScript: zitiLogin
# -- ziti shell rc mountpoint where zitirc.bash is projected
zitiShellProfileDir: /etc/profile.d
# -- ziti shell rc filename
zitiShellProfileSript: ziti-profile.bash
# -- read-only mountpoint where configFile and various read-only identity dirs are projected
configMountDir: /etc/ziti
# -- filename of the controller configuration file
configFile:     ziti-controller.yaml
# -- writeable mountpoint where the controller will create dbFile during init
dataMountDir:   /persistent
# -- name of the BoltDB file
dbFile:         ctrl.db
# -- read-only mountpoint for run container to read the ctrl plane trust bundle created during init
ctrlPlaneCaDir: ctrl-plane-cas
# -- filename of the ctrl plane trust bundle
ctrlPlaneCasFile: ctrl-plane-cas.crt

These can become named templates because the chart needs to use the value in multiple places, but it's not all that valuable to be able to set an alternative value when the chart is installed. As a result, these are cluttering up the values.yaml file and the README that documents these.

Here's an example of how it should be done:

Add named templates to the file "templates/_helpers.tpl" like this:

{{- define "ziti-controller.ctrlPlaneCasFile" -}}
ctrl-plane-cas.crt
{{- end }}

Then, in any template that references the old value, replace:

{{ .Values.ctrlPlaneCasFile }}

with

{{ include "ziti-controller.ctrlPlaneCasFile" . }}

Then, for each value that you convert to a named template, you can remove its default value and documentation comment from the file "values.yaml."

When you push your branch to GitHub the documentation README will be automatically generated and you'll see the default values were removed by the automation.

console chart: better support for cert-manager

The console chart sets up server TLS if a secret name is provided and assumes the secret is managed by the issuer. Deployment will fail if the named secret doesn't exist. If secretName isn't defined and ingress is enabled the Kubernetes Ingress Controller Fake Certificate is bound to the service.

It's already possible to configure verifiable server cert if the cluster has a Let's Encrypt cluster issuer. This is accomplished by adding annotations to the ingress like this Helm values.yaml example:

ingress:
  enabled: true
  ingressClassName: nginx
  annotations:
    cert-manager.io/cluster-issuer: ${cluster_issuer}
  advertisedHost: ${console_domain_name}.${domain_name}
  tlsSecret: ${console_release}-tls-secret

Add support for cert-manager. We can do this by adding a value ingress.cluster-issuer. The value is used to annotate the ingress:

metadata:
  annotations:
    cert-manager.io/cluster-issuer: {{ .Values.ingress.cluster-issuer }}

If a cluster issuer with that name doesn't exist, one is created. This way, you'll get an unverifiable cert from the designated issuer at the very least, and if you already have a ClusterIssuer set up with ACME then it simplifies the needed Helm values.

ziti-edge-tunnel: ImagePullBackOff upgrading the image

Hi @qrkourier,

We face an issue upgrading the ziti-edge-tunnel helm chart, where it sometimes works, and sometimes not as the tunnel was already killed and there is no way of pulling the new image.

DISCLAIMER: We mirror the container registries as described here via the very same tunnel, because the clusters does not have internet.

The first proposal would be to switch values.image.pullPolicy from Always to IfNotPresent here.

The second one, and the more interesting one, would be adding some kind of pre-pull mechanism, which would be default disabled of course. The options I see here, but I still not tested it as I want to hear your thoughts, are:

1. A fake initContainer which pulls the very same image.
2. Add a pre-puller as DaemonSet as described here.

Let me know what you think, and I can start working this out.

Thank you!

add a chart for hosting cluster services with a tunneler

ziti-edge-tunnel run-host can host cluster services i.e. provide cluster ingress via Ziti

bash-4.4# zitiLogin Error: unknown flag: --cert

I'm seeing the following error when running the zitiLogin command in the ziti-controller container.

bash-4.4# zitiLogin
Error: unknown flag: --cert
Usage:
  ziti edge login my.controller.hostname[:port]/path [flags]

Flags:
      --ca string             additional root certificates used by the Ziti Edge Controller
  -i, --cli-identity string   Specify the saved identity you want the CLI to use when connect to the controller with
  -c, --client-cert string    A certificate used to authenticate
  -k, --client-key string     The key to use with certificate authentication
  -e, --ext-jwt string        A JWT from an external provider used to authenticate
  -h, --help                  help for login
      --ignore-config         If set, does not use value from the config file for hostname or username. Values must be entered or will be prompted for.
  -j, --output-json           Output the full JSON response from the Ziti Edge Controller
      --output-request-json   Output the full JSON request to the Ziti Edge Controller
  -p, --password string       password to use for authenticating to the Ziti Edge Controller, if -u is supplied and -p is not, a value will be prompted for
      --read-only             marks this login as read-only. Note: this is not a guarantee that nothing can be changed on the server. Care should still be taken!
      --timeout int           Timeout for REST operations (specified in seconds) (default 5)
  -t, --token string          if an api token has already been acquired, it can be set in the config with this option. This will set the session to read only by default
  -u, --username string       username to use for authenticating to the Ziti Edge Controller 
      --verbose               Enable verbose logging
  -y, --yes                   If set, responds to prompts with yes. This will result in untrusted certs being accepted or updated.


unknown flag: --cert

This is me looking at the zitiLogin script.

bash-4.4# which zitiLogin
/usr/local/bin/zitiLogin
bash-4.4# vim
bash-4.4# vim /usr/local/bin/zitiLogin 


ziti edge login "${ZITI_MGMT_API}" --yes \
  --username "${ZITI_ADMIN_USER}" \
  --password "${ZITI_ADMIN_PASSWORD}" \
  --cert "${ZITI_CTRL_PLANE_CA}/ctrl-plane-cas.crt"