fusionauth / charts Goto Github PK

View Code? Open in Web Editor NEW

25.0 14.0 26.0 935 KB

Public helm charts

Home Page: https://fusionauth.io

License: Apache License 2.0

Mustache 100.00%

fusionauth helm helm-charts helm-chart kubernetes k8s

charts's Introduction

FusionAuth Helm Chart

FusionAuth is a modern platform for Customer Identity and Access Management (CIAM). FusionAuth provides APIs and a responsive web user interface to support login, registration, localized email, multi-factor authentication, reporting, and much more.

Installation

See the chart README for detailed information.

Releasing the Chart

Release the chart by pushing a new tag.

git tag 1.0.0
git push origin main --tags

To default to a new version of FusionAuth, update these 4 files with the new version number:

chart/README.md
chart/Chart.yaml
chart/examples/minikube/values.yaml
chart/values.yaml

⚠️ Users must always be able to override the default version in the chart by setting image.tag.

charts's People

Contributors

Stargazers

Watchers

charts's Issues

upgrade from 0.8.1 to 0.9.2 failed

I have the database passwords set in an existing secret existingSecret: fusionauth-db, when updating from chart 0.8.1 to 0.9.2 the silent database update process failed on the pod, complaining that pgsql required a password but none was supplied.

changing back to 0.8.1 resolved the issue.

I tried removing the password line that is set to empty string, but the validation failed.

database:
  existingSecret: fusionauth-db
  host: XXXXXXXXXXXXXXXXX
  name: fusionauth
  password: ''

Add extraVolumeMounts and extraVolumes to store custom css

Hi,

I would like to be able to mount an additional volume on
/usr/local/fusionauth/fusionauth-app/web/custom

If the Helm chart had extraVolumeMounts and extraVolumes I could do this.

example on values.yaml

extraVolumes: []
##  - name: custom-css-data
##    persistentVolumeClaim:
##      claimName: custom-css-data

extraVolumeMounts: []
##   - name: custom-css-data
##     mountPath: /usr/local/fusionauth/fusionauth-app/web/custom

initContainers: wait-for-db is missing the terminal/shell argument

Under master branch chart/templates/deployment.yaml, the initContainers: wait-for-db is now using the multiarch image => busybox:latest

initContainers:
        - name: wait-for-db
          image: "{{ .Values.initImage.repository }}:{{ .Values.initImage.tag }}"
          args:
            - >
              set -x;
              while [[ "$(nc -zv '{{- .Values.database.host -}}' {{ .Values.database.port }} &> /dev/null; echo $?)" != 0 ]]; do
                echo '.'
                sleep 15;
              done

This throws an error saying that "no such file or directory".
The solution is to identify and add the kind of terminal (or shell) that is available on the busybox:latest image by using

$ docker inspect busybox:latest

"Cmd": [
                "/bin/sh",
                "-c",
                "#(nop) ",
                "CMD [\"sh\"]"
            ]

Then modify the chart/templates/deployment.yaml by specifying the correct available shell for busybox image as following:

initContainers:
        - name: wait-for-db
          image: "{{ .Values.initImage.repository }}:{{ .Values.initImage.tag }}"
         args:
            - /bin/sh
            - -c
              set -x;
              while [[ "$(nc -zv '{{- .Values.database.host -}}' {{ .Values.database.port }} &> /dev/null; echo $?)" != 0 ]]; do
                echo '.'
                sleep 15;
              done

This solution works. I can create a pull request if I am in the right direction.

Setting replicas greater than 1, could not login

Can you confirm increasing the number of replicas (pods) should work? When I had it set to 3 replicas could not login. Immediately after the wizard, I was kicked into an infinite loop at the oauth screen. I know I was using the correct credentials because when I didn't, I saw a validation error. I recreated the deployment setting replicas to 1 and it worked. Want to confirm.

Is there per-process, in-memory caching perhaps that would be breaking support for multiple replicas?

Using our own out of chart PostgreSQL and Elasticsearch.

Allow specification of dnsConfig in the deployment

As a workaround for FusionAuth/fusionauth-containers#54 we would like to specify dnsConfig in the deployment, but the chart does not allow it.
(I can imagine that there may be other reasons why you'd want to specify it on specific clusters)

dnsConfig:
  options:
    - name: ndots
      value: "1"

Unable to install in MicroK8s/Kubernetes 1.18: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1"

ceefour@amanah:~/project/fusionauth-trial$ sudo microk8s helm3 repo add fusionauth https://fusionauth.github.io/charts

ceefour@amanah:~/project/fusionauth-trial$ sudo microk8s helm3 install -v5 fusionauth fusionauth/fusionauth
I0414 15:18:28.311174    2962 discovery.go:214] Invalidating discovery information
Error: unable to build kubernetes objects from release manifest: [unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1", unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta1", unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta2"]

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"7879fc12a63337efff607952a323df90cdc7a335", GitTreeState:"clean", BuildDate:"2020-04-08T17:38:50Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

$ sudo microk8s helm3 version
version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

Seems to be caused by newer Kubernetes (1.18) not accepting resource versions apps/v1beta1 and apps/v1beta2.

Unknown field "test" in io.k8s.api.core.v1.PodTemplateSpec

I am using the latest chart (helm repo update) repo to deploy fusionauth using helm v3 and am getting an error.

$ helm version
version.BuildInfo{Version:"v3.3.0", GitCommit:"8a4aeec08d67a7b84472007529e8097ec3742105", GitTreeState:"dirty", GoVersion:"go1.14.7"}

helm install fusionauth fusionauth/fusionauth \
	--namespace iam --create-namespace \
	--set nodeSelector."k3s\\.io/hostname"=rpi-kube-master \
	--set database.user=postgres \
	--set database.password=postgres \
	--set database.root.user=postgres \
	--set database.root.password=postgres \
	--set database.host=postgresql.db \
	--set database.port=5432 \
	--set database.name=fusionauth \
	--set service.type=NodePort \
	--set search.engine=elasticsearch \
	--set search.host=elasticsearch-master.db \
	--set search.port=9200 \
	--set image.repository=docker.io/jerryhopper/fusionauth-app \
	--set image.tag=latest \
	--set image.pullPolicy=IfNotPresent \
	--set ingress.enabled=true

Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec.template): unknown field "test" in io.k8s.api.core.v1.PodTemplateSpec

Hosts must be explicitly set to the full service names

The only way I was able to get this chart working, was by using the inherited PostgreSQL and Elasticsearch. However, even that required me to set the hosts explicitly:

database:
    host: "fusionauth-postgresql.default.svc.cluster.local"
    port: 5432
    tls: false
    name: fusionauth
    user: localhost
    password: localhost
    root:
      user: localhost
      password: localhost

  search:
    protocol: http
    host: "fusionauth-elasticsearch-client.default.svc.cluster.local"
    port: 9200
    # user: ""
    # password: ""

Leaving the hosts as "" would fail the pod init connecting to Elasticsearch.

Trying to use our own Elasticsearch and PostgreSQL caused a slew of others problems.

Register chart repository with artifacthub.io

Hi,

first thank you for this great work (FusionAuth as well as the helm chart)!

I have a small suggestion: It took a while for me to find your helm chart. The main search portal for finding helm charts is https://artifacthub.io/. I would like to ask and to suggest, if you would be willing to register your helm chart repository on that site, so that your helm chart can be found more easily. What do you think about that?

Best regards
Matthias

ElasticSearch credentials appear to be discarded or ignored during provisioning

I am using the latest helm chart and passing in the connection string for our Elastic server. However during provisioning I receive a 401 http response and it appears the credentials were dropped from the connection string. Has anyone seen this before? This is with FusionAuth 1.19.7. I did not have this problem with 1.16.1. If I login to the fusionAuth pod I can see the credential string setup properly as the SEARCH_SERVERS and I can manually connect to ElasticSearch using it:

SEARCH_SERVERS=http://elastic:V9Q1nbqUK82caeche6514i0i@elasticsearch-cluster-es-http:9200
(that is a temporary password)

2020-09-23 12:57:55.025 PM INFO com.inversoft.search.ElasticRestClientHelper - Connecting to Elasticsearch at [http://elasticsearch-cluster-es-http:9200]
2020-09-23 12:57:55.614 PM INFO com.inversoft.maintenance.search.ElasticsearchMaintenanceModeSearchService - Missing search index [fusionauth_user]
2020-09-23 12:57:55.620 PM INFO com.inversoft.search.ElasticRestClientHelper - Connecting to Elasticsearch at [http://elasticsearch-cluster-es-http:9200]
2020-09-23 12:57:55.685 PM ERROR com.inversoft.maintenance.search.ElasticsearchMaintenanceModeSearchService - Failed to create index [fusionauth_user]. Reason + [org.elasticsearch.client.ResponseException: method [GET], host [http://10.20.30.99:9200], URI [/], status line [HTTP/1.1 401 Unauthorized]

Please let me know what other information you need and I can submit it.

Ingress falls back into wrong api version for recent k8s versions

Describe the bug
I am trying to set up the fusionauth chart using the ingress option. On a clean installation, I run into the problem that the ingress uses an api which is not compatible with my kubernetes installation.

Docker version and underlying OS

Running on macOS, virtualbox-driver for minikube, kubernetes:

kubectl version
>> Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.1", GitCommit:"632ed300f2c34f6d6d15ca4cef3d3c7073412212", GitTreeState:"clean", BuildDate:"2021-08-19T15:38:26Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"darwin/amd64"}
>> Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.1", GitCommit:"632ed300f2c34f6d6d15ca4cef3d3c7073412212", GitTreeState:"clean", BuildDate:"2021-08-19T15:39:34Z", GoVersion:"go1.16.7", Compiler:"gc", Platform:"linux/amd64"}

To Reproduce
Steps to reproduce the behavior:

helm install fa-test fusionauth/fusionauth --set database.user=fusionauth --set database.password=fusionauth --set database.host=fusionauthdb --set search.engine=database --set ingress.enabled=true
>> Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Ingress" in version "extensions/v1beta1"

Expected behavior
I guess the new api version is no longer networking.k8s.io/v1beta1 but networking.k8s.io/v1 and therefore following part in the _helper:

{{/*
Set apiVersion for ingress
*/}}
{{- define "fusionauth.ingressApiVersion" -}}
{{- if .Capabilities.APIVersions.Has "networking.k8s.io/v1beta1" -}}
networking.k8s.io/v1beta1
{{- else -}}
extensions/v1beta1
{{- end -}}
{{- end -}}

falls back into the even older api.

Otherwise there is not much difference between this ingress definition and the standard one obtained by helm create ….

Improvement: Env vars should be moved to configmap

Given that FusionAuth is highly configurable via environment variables, it makes sense to move these variables into a separate ConfigMap, which is then consumed by the pod.

Not so much an issue, but an improvement.

Explicitly define image version tags

Is your feature request related to a problem? Please describe.
Using an image tag of latest can cause problems when dependent images introduce breaking changes or when a cached, older version of the image is used. Explicitly defining image tags allows us to ensure that what we test is what will be deployed.

Describe the solution you'd like
Use a specific image tag for all containers, specifically the busybox image used for our initContainers.

Flag to disable disallowAlg http://www.w3.org/2000/09/xmldsig#rsa-sha1

Due to upgrading to the latest version of FusionAuth 1.42.0, this following issue affects us and our end users. FusionAuth/fusionauth-site#1202

Is there a Helm flag to disable disallowAlg http://www.w3.org/2000/09/xmldsig#rsa-sha1? We need a automated way of making this change to support our legacy SAML customers.

Proxy Configuration Warning

Describe the bug
Proxy Configuration Warning after installation using the official helm chart on GKE
The warning is shown in the Admin dashboard ,as following:

It appears that FusionAuth is running behind a proxy server and your configuration is not correct.

Your browser reported a request origin that is not equal to the actual HTTP request. Because these are not equal we will fail CSRF (Cross Site Request Forgery) validation when you submit a form that is using the POST method. If you attempt to create an Application, API key, User, etc you will receive an Unauthorized message.

Reported request origin:
https://example.com

Actual request origin:
https://example.com:9011

The following X-Forwarded- HTTP request headers were detected on the request:
X-Forwarded-Proto: https

To correct the origin, add the following request headers through your proxy configuration:
X-Forwarded-Port: 443

I can view all resources but cannot make any changes on the instance except via the API

Docker version and underlying OS
GKE 1.22

To Reproduce
Steps to reproduce the behavior:
Follow the installation steps in the official repo

Expected behavior
The system should work as expected when deployed using the official repo

Logs (please share snips of applicable logs)
Nothing

Additional context
I am using certificate provisioned by GCP added to the ingress service as annotation

Annotations support for FusionAuth ServiceAccount

Is your feature request related to a problem? Please describe.
We want to communicate with Elasticsearch with EKS ServiceAccount throught IAM roles, for that serviceaccount must have annotations about IAM role it must assume, right now chart is only creating ServiceAccount but there is no possibility to add annotations. I can add feature but as i see in README history, this repo is no longer maintained by community.

Describe alternatives you've considered
We are deploying helm with terraform so creating serviceaccount and rolebindings outside helm chart is possible but as helm is controlling deployment pods wont be available to use terraform created serviceaccount

fusionauth pod refusing connection on HTTP port 9011 (Readiness & Liveness probe failed)

I managed to "start" the helm chart using postgresql and elasticsearch externally configured, as described in https://about.lovia.life/handbook/technology/fusionauth/ .

However the fusionauth pod is always crashing and I can't get the HTTP UI 9011 to work.

Problem is, the logs don't give any meaningful clue:

ceefour@amanah:~/project/fusionauth-trial$ kubectl logs $POD_NAME
16-Apr-2020 19:15:04.730 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: [/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
16-Apr-2020 19:15:16.132 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-9011"]
16-Apr-2020 19:15:16.534 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read
16-Apr-2020 19:15:17.331 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["https-jsse-nio-9013"]

https://fusionauth.io/docs/v1/tech/troubleshooting hints to look at log files but no hint on where to look in Docker/Kubernetes environment. (suggestion: Update the docs to troubleshoot Docker & Kubernetes)

I also tried raising memory limits to 1000Mi, but still no improvement.

describe po:

Containers:
  fusionauth:
    Container ID:   containerd://4e15f320075247acab7ba212272ac30a30bee57ce90db875676f096d478f0421
    Image:          fusionauth/fusionauth-app:latest
    Image ID:       docker.io/fusionauth/fusionauth-app@sha256:4b5e8fe66dbc796a04a8936e69c89901049a8ba11d63a89111691ae9b7b2ea48
    Port:           9011/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Fri, 17 Apr 2020 02:13:50 +0700
    Ready:          False
    Restart Count:  0
    Limits:
      cpu:     100m
      memory:  1000Mi
    Requests:
      cpu:      100m
      memory:   1000Mi
    Liveness:   http-get http://:http/ delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get http://:http/ delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      DATABASE_USER:              fusionauth
      DATABASE_PASSWORD:          ***
      DATABASE_ROOT_PASSWORD:     ***
      DATABASE_ROOT_USER:         postgres
      DATABASE_URL:               jdbc:postgresql://postgresql.default.svc.cluster.local:5432/fusionauth
      FUSIONAUTH_SEARCH_SERVERS:  http://elasticsearch-elasticsearch-coordinating-only.default.svc.cluster.local:9200
      FUSIONAUTH_MEMORY:          512M
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-252p8 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  default-token-252p8:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-252p8
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  29s                default-scheduler  Successfully assigned default/fusionauth-c75cdb6d7-qqssj to amanah
  Normal   Pulled     29s                kubelet, amanah    Container image "darthcabs/tiny-tools:1" already present on machine
  Normal   Created    29s                kubelet, amanah    Created container wait-for-db
  Normal   Started    29s                kubelet, amanah    Started container wait-for-db
  Normal   Pulled     28s                kubelet, amanah    Container image "darthcabs/tiny-tools:1" already present on machine
  Normal   Created    28s                kubelet, amanah    Created container wait-for-search
  Normal   Started    28s                kubelet, amanah    Started container wait-for-search
  Normal   Pulled     27s                kubelet, amanah    Container image "fusionauth/fusionauth-app:latest" already present on machine
  Normal   Created    27s                kubelet, amanah    Created container fusionauth
  Normal   Started    27s                kubelet, amanah    Started container fusionauth
  Warning  Unhealthy  10s (x2 over 20s)  kubelet, amanah    Readiness probe failed: Get http://10.1.87.57:9011/: dial tcp 10.1.87.57:9011: connect: connection refused
  Warning  Unhealthy  7s (x2 over 17s)   kubelet, amanah    Liveness probe failed: Get http://10.1.87.57:9011/: dial tcp 10.1.87.57:9011: connect: connection refused

Any help & suggestion is very appreciated.

Follows up #11.

New Release?

0.9.4 was recently released from this repo, but isn't yet available in the https://fusionauth.github.io/charts/ repository - any ETA on this? Thanks.

Update image tag as part of the FusionAuth release process to keep it tracking with latest

Search port required even when search is set to database

When using search: engine: database the chart enforces that port be an integer. It should not validate this field since the comment above says:

search.port -- Port to use when connecting to elasticsearch. Ignored when search.engine is NOT elasticsearch

Error: UPGRADE FAILED: values don't meet the specifications of the schema(s) in the following chart(s):
fusionauth:
- search.port: Invalid type. Expected: integer, given: string

Relevant block in my values.yaml

  search:
    # search.engine -- Defines backend for fusionauth search capabilities. Valid values for engine are 'elasticsearch' or 'database'.
    engine: database
    # search.engine -- Protocol to use when connecting to elasticsearch. Ignored when search.engine is NOT elasticsearch
    protocol: ""
    # search.host -- Hostname or ip to use when connecting to elasticsearch. Ignored when search.engine is NOT elasticsearch
    host: ""
    # search.port -- Port to use when connecting to elasticsearch. Ignored when search.engine is NOT elasticsearch
    port:
    # search.user -- Username to use with basic auth when connecting to elasticsearch. Ignored when search.engine is NOT elasticsearch
    # user: ""
    # search.password -- Password to use with basic auth when connecting to elasticsearch. Ignored when search.engine is NOT elasticsearch
    # password: ""

Support MySQL database

Currently the chart is hardcoded to use PostgreSQL.

It would be great if it also supports MySQL and hopefully MariaDB as well (FusionAuth/fusionauth-issues#327, FusionAuth/fusionauth-issues#367).

FusionAuth wants to be a K8S Operator

Is your feature request related to a problem? Please describe.
No k8s yaml to submit which creates fusionauth stuff.

Is your feature request related to a way you would like fusionauth extended? Please describe.
Yes, Fusionauth has the perfect kind of data for a k8s operator.

Describe the solution you'd like
Kubernetes Operator for FusionAuth

Describe alternatives you've considered
Make my own, erm, that's hard to do.
Only option is lame hacky ci scripts posting curl requests.

key rootpassword in Secret fusionauth/fusionauth-credentials should be optional

For managed Database services, the fusionauth documentation states that the root password configuration option should not be specified, see ; https://fusionauth.io/docs/v1/tech/guides/silent-mode/

Though, using this chart without specifying database.root.password results in a database config error.

This chart should be fixed so that database.root.password is optional.

Support for setting resources.requests in initContainers

Is your feature request related to a problem? Please describe.

Can you add support for passing resources.requests into both the initContainers wait-for-db and wait-for-search? We require specifying a resources.requests for every single pod we deploy and currently there is no way to provide this.

See: https://github.com/FusionAuth/charts/blob/master/chart/templates/deployment.yaml#L35

busybox:latest -- toomanyrequests work around

As I understand, if I provide authentication to Docker Hub I can get around the rate limits on pulling busybox. I tried adding imagePullSecrets to the initImage block, but I am still getting:

Failed to pull image `busybox:latest": rpc error: code = Unknown desc = Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

Example:

# This image should contain `nc` and a shell of some kind to do a simple loop.
initImage:
  # initImage.repository -- Docker image to use for initContainers
  repository: busybox
  # initImage.repository -- Tag to use for initContainers docker image
  tag: latest
  imagePullSecrets:
    - regcred

regcred is a secret that contains valid Docker Hub credentials.

Please create a helm charts for the latest FusionAuth version 1.32.1

Since one week the version 1.31.1 of FusionAuth is available. https://fusionauth.io/docs/v1/tech/release-notes/#version-1-32-1
But the Helm Charts are still stuck on 1.30.1.

Can you please create a new FusionAuth Helm Charts which supports the latest version of FusionAuth?

Thanks a lot in advance.
Christian

Create default tenant id and root api key using kickstart not working

I am attempting to create default tenant id 9a39129e-0789-4a88-a66f-73f058ea6d2b and root api key using the kickstart functionality:

  kickstart:
    enabled: true
    data:
      kickstart.json: |
        {
          "variables": {
            "defaultTenantId": "9a39129e-0789-4a88-a66f-73f058ea6d2b"
          },
          "apiKeys": [{
            "key": "somesupersecretapikeyhere",
            "description": "Root API Key"
          }]
        }

However after the pods come up, and I log into the web ui the default tenant id is not 9a39129e-0789-4a88-a66f-73f058ea6d2b and there are no api keys created.

Strange behaviour when use an existing secret and databbase root password

If we use an existing secret to store credentials, the modifications included in #43 forces us to add a dummy database root password.

This behaviour is a bit strange, maybe would be better to add a new helm value to force the environment mapping, or change the way the secrets are included as environment variables, ie, map a secret as environment variables directly: https://kubernetes.io/docs/concepts/configuration/secret/#use-cases

Helm chart points to a broken point release

Helm chart is still referencing 1.15.6, which has a SAML regression fixed in 1.15.7.

Documentation error

In the configuration table it lists tlsMode shouldn't that be database.tlsMode?

apiVersion bumped to 2?

Why is Helm api version changed to apiVersion: v2 in the latest commit? Does that mean Helm version 2 is no longer supported?

Chart advice

It is possible to put Postgres and Elasticsearch back in the chart and use a bool for enable: etc to pull in as needed. This creates a chart that can be spun up fully without external dependencies or allow external instances. Just an opinion.

Also what is the desired result for these sections. They do not work as one expects

To use an existing secret, set existingSecret to the name of the secret. We expect two keys: password and rootpassword
existingSecret: "" <----- If this is filled in then the next fields should be ignored, not required
user: ""
password: ""

These credentials are used for bootstrapping the database
root:
user: "" <----- if the secret is filled in then this should be ignored (?)
password: ""

search:
Valid values for engine are 'elasticsearch' or (if you are using fusionauth >= 1.16.0-rc.1) 'database'.
engine: elasticsearch <----- If you place database here should this not cause the host field to be ignored?
protocol: http
host: ""

If seems to me that the helm chart needs more attention. The trend is moving away from docker to using full orchestration on the desktop to use Kubernetes. Docker by itself is great for doing actual development of said product but the evolution is towards providing the following supported options, docker, Kubernetes manifest, Kubernetes Helm. Manfiset and Helm tend to get ignored because many have trouble creating them for some reason.

Advise on what you want the expected behavior to be in the Helm chart and I will develop these further and submit a pull request

Support valueFrom/secretKeyRef

Especially for:

database.password
database.root.password

Currently these values has to be specified to helm chart literally.

It'd be great if we can say:

secretName: fusionauth

database:
  passwordSecretKey: mariadb-password
  root:
    passwordSecretKey: mariadb-root-password

And the generated template will use valueFrom/secretKeyRef.

ARM64v8 - Raspberry Pi compatible docker image/Chart

I want to deploy fusionAuth onto ARM64v8 - Raspberry Pi 4. So far I have tried
helm install fusionauth fusionauth/fusionauth \ --set database.user=fusionauth \ --set database.password=fusionauth \ --set database.root.user=postgres \ --set database.root.password=postgres \ --set database.host=postgresql.db \ --set database.port=5432 \ --set search.engine=database \ --set image.repository=fusionauth/fusionauth-app \ --set image.tag=latest

This gives the following error, from container log => container "fusionauth" in pod "fusionauth-97988bb4d-596zp" is waiting to start: PodInitializing

postgres db container is already up, running and accessible with k8s cluster,

Failed to fetch https://github.com/FusionAuth/charts/index.yaml : 404 Not Found

helm repo add fusionauth https://github.com/FusionAuth/charts
Error: Looks like "https://github.com/FusionAuth/charts" is not a valid chart repository or cannot be reached: Failed to fetch https://github.com/FusionAuth/charts/index.yaml : 404 Not Found

Helm not able to evaluate hosts value when upgrading to the latest version

Describe the bug
Trying to upgrade from v0.9.3 to 0.10.3. After executing helm upgrade ... command, I get an error from helm which most likely is related to parsing the values.yaml file.

Error: UPGRADE FAILED: template: fusionauth/templates/ingress.yaml:31:18: executing "fusionauth/templates/ingress.yaml" at <.host>: can't evaluate field host in type interface {}

values.yaml file (Ingress part):

ingress:
   annotations:
     ...
   enabled: true
   hosts:
     - fusion.example.com
   paths:
     - "/"
  tls:
    - hosts:
        - fusion.example.com
      secretName: fusionauth-tls

According to the documentations, everything about the values.yaml file seems about right. Although, going through the list of commits for the ingress.yaml file, it seems like 5fb917a has recently changed the structure of that file a bit. I believe that commit might have caused this issue.

To Reproduce
Write the ingress part of your values.yaml with a similar structure to what's mentioned above and then try to upgrade your release to the latest version.

Expected behavior
Properly upgrade the fusionauth release to the latest version (0.10.3) without any problems.

Missing implementation for org.primeframework.mvc.workflow.MVCWorkflow

Description

After deploying a clean installation of FusionAuth with the current Helm Chart, FusionAuth complains about a missing implementation for org.primeframework.mvc.workflow.MVCWorkflow.

(Istio is installed in the cluster. It doesn't matter if the FusionAuth pods have Istio sidecars injected. Enabling/Disabling the injection of sidecars has no effect on the described error.)

2020-11-13 7:40:58.320 AM ERROR org.primeframework.mvc.servlet.PrimeFilter - Error encountered
com.google.inject.ConfigurationException: Guice configuration errors:

1) No implementation for org.primeframework.mvc.workflow.MVCWorkflow was bound.
  while locating org.primeframework.mvc.workflow.MVCWorkflow

1 error  
	at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1120)
	at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1078)
	at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1131)
	at org.primeframework.mvc.servlet.PrimeFilter.doFilter(PrimeFilter.java:77)
	at com.inversoft.maintenance.servlet.MaintenanceModePrimeFilter.doFilter(MaintenanceModePrimeFilter.java:59)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at com.inversoft.servlet.UTF8Filter.doFilter(UTF8Filter.java:27)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:615)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1626)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.base/java.lang.Thread.run(Thread.java:832)

Affects versions

FusionAuth 1.19.8

Steps to reproduce

Prepare

Create namespace fusionauth
kubectl create namespace fusionauth
(Optional) Enable automatic Istio sidecar injection
kubectl label namespace fusionauth istio-injection=enabled
Install Postgresql in namespace fusionauth and ElasticSearch in namespace elastic
Enable Authentication in Elastic
Configure Elasticsearch users

Reproduce

Install FusionAuth

helm install fusionauth fusionauth/fusionauth
    --set database.root.user=postgres
    --set database.root.password=<Hidden>
    --set database.user=postgres
    --set database.password=<Hidden>
    --set database.host=postgresql-postgresql-0.postgresql-headless.fusionauth.svc.cluster.local
    --set search.host=elasticsearch-master-0.elasticsearch-master-headless.elastic.svc.cluster.local
    --set search.user=elastic
    --set search.password=<Hidden>
    --namespace fusionauth

Look into the logs of elasticsearch container

Platform

OS: Docker and Kubernetes running on Ubuntu 18.04 LTS

Additional context

The InitContainers succeed. Both, ElasticSeach and Postgresql, are reachable from FusionAuth.

Removing all Helm Charts (ES, Postgres, FusionAuth) incl. removing the PVCs and reinstalling doesn't change anything.

Don't hardcode busybox registry in test-connection.yaml

Is it possible to not hardcode the busybox Docker image in https://github.com/FusionAuth/charts/blob/master/chart/templates/tests/test-connection.yaml#L15 and use the parent initImage:repository value if defined. If not defined, fallback to using the hardcoded busybox.

The reason is we are using isolation and it requires all the Docker containers be hosted on our private registry. As it currently stands, we don't have a way to override the registry for this.

Set root API key via secret

Is your feature request related to a problem? Please describe.

I'd like to use a Kubernetes secret to store the default root API key used with Kickstart. Is this possible?

Currently I have to hard-code it in the values.yaml and I can't use Helm variables or functions:

kickstart:
    enabled: true
    data:
      kickstart.json: |
        {
          "variables": {
          },
          "apiKeys": [{
            "key": "api-key-here",
            "description": "Root API Key"
          }]
        }

undefined variable "$extraPaths

When trying to install I am getting the error:

Error: parse error in "fusionauth/charts/fusionauth/templates/ingress.yaml": template: fusionauth/charts/fusionauth/templates/ingress.yaml:33: undefined variable "$extraPaths"

My values.yaml is:

  replicaCount: 3

  elasticsearch:
    enabled: false
    imageTag: 6.8.6
    master:
      name: master

  postgresql:
    # if enabled = false you need to set database.host
    enabled: false
    image:
      tag: 9.6.15
    postgresqlUsername: localhost
    postgresqlPassword: localhost

  image:
    repository: fusionauth/fusionauth-app
    tag: 1.14.0
    pullPolicy: IfNotPresent

  nameOverride: ""
  fullnameOverride: ""

  service:
    type: ClusterIP
    port: 9011

  database:
    host: "postgres-master.default.svc.cluster.local"
    port: 5432
    name: fusionauth
    user: localhost
    password: localhost
    root:
      user: localhost
      password: localhost

  search:
    protocol: http
    host: "elasticsearch-master.default.svc.cluster.local"
    port: 9200
    # user: ""
    # password: ""

  environment:
  # Database env DATABASE_USER, DATABASE_PASSWORD, DATABASE_ROOT_USER, DATABASE_ROOT_PASSWORD, DATABASE_URL will be
  # defined in database
    FUSIONAUTH_MEMORY: 256M
    # FUSIONAUTH_API_KEY: test
    # Its important to add /kickstart/<file> as prefix to your kickstart file else it won't work! All other files
    # will be mounted below /kickstart/
    # FUSIONAUTH_KICKSTART: /kickstart/kickstart.json
  kickstart:
    enabled: false
    data: {}
      # kickstart.json: |
      #    {
      #      "variables": {
      #        "defaultTenantId": "d7d09513-a3f5-401c-9685-34ab6c552453",
      #        "adminEmail": "[email protected]",
      #        "adminPassword": "password",
      #      },
      #      "apiKeys": [
      #        {
      #          "key": "bf69486b-4733-4470-a592-f1bfce7af580",
      #          "description": "Core API Key"
      #        }
      #      ],
      #      "requests": [
      #        {
      #          "method": "POST",
      #          "url": "/api/user/registration",
      #          "body": {
      #            "user": {
      #              "email": "#{adminEmail}",
      #              "password": "#{adminPassword}"
      #            },
      #            "registration": {
      #              "applicationId": "#{FUSIONAUTH_APPLICATION_ID}",
      #              "roles": [
      #                "admin"
      #              ]
      #            }
      #          }
      #        }
      #      ]
      #    }
      # setup-password.html: |
      #    <div>Test</div>
      # setup-password.txt: |
      #    Hallo

  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: traefik
      kubernetes.io/tls-acme: "true"
    paths: []
    # Define complete path objects, will be inserted before regular paths. Can be useful for things like ALB Ingress Controller actions
    extraPaths: []
    hosts:
      - example.com
    tls:
      - hosts:
        - example.com

  resources: {}
    # We usually recommend not to specify default resources and to leave this as a conscious
    # choice for the user. This also increases chances charts run on environments with little
    # resources, such as Minikube. If you do want to specify resources, uncomment the following
    # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
    # limits:
    #  cpu: 100m
    #  memory: 128Mi
    # requests:
    #  cpu: 100m
    #  memory: 128Mi

  nodeSelector: {}

  tolerations: []

  affinity: {}