⚠️ Repo Archive Notice

As of Nov 13, 2020, charts in this repo will no longer be updated. For more information, see the Helm Charts Deprecation and Archive Notice, and Update.

Gangway

An application that can be used to easily enable authentication flows via OIDC for a kubernetes cluster.

DEPRECATION NOTICE

This chart is deprecated and no longer supported.

TL;DR

helm install stable/gangway

Introduction

The chart deploys an instance of Gangway into a Kubernetes cluster using the Helm package manager.

This chart will do the following:

• Create a deployment of gangway within your Kubernetes Cluster.

Installing the Chart

To install the chart with the release name my-release:

helm install --name my-release stable/gangway

Due to the nature of OIDC configuration, deploying the chart without at least some of the values being set will not result in a functioning application. See the Configuration section below for more information.

Configuration

The following table lists the configurable parameters of the external-dns chart and their default values.

All values under the gangway top level object are passed directly to the Gangway container via a yaml config file. The contents of that object in values.yaml are lifted directly from the Gangway documentation.

At a minimum you must configure any of the values marked as required in the table below.

You will likely want to expose Gangway to your users somehow, possibly by way of an ingress, the values below would be a way of doing this with the Traefik ingress controller, this assumes TLS offload is happening at the load balancer:

ingress:
enabled: true
annotations:
    kubernetes.io/ingress.class: traefik
path: /
hosts:
    - gangway.your-domain.com
tls: []

Note about gangway.sessionKey

The chart will auto generate a random value for gangway.sessionKey when you install the chart. Gangway uses this via the Gorilla Secure Cookie Go library to encrypt the contents of cookies sent to the users browser. Relying on the autogeneration is acceptable in testing environments, however in production you are strongly advised to provide your own random value for this variable. If you do not and you subsequently update your Helm deployment this key will be regenerated. This has the impact that any cookies in your users browsers from before the upgrade, will have been encrypted with the old key, which Gangway no longer has. Therefore when they browse to your Gangway url they will get an error when they attempt to login. The only solution to that issue is to have the user delete all the gangway cookies from their browser. You have been warned!

Specifying Values

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

$ helm upgrade --install --wait my-release \
    --set ingress.enabled=true \
    stable/gangway

Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example,

$ helm upgrade --install --wait my-release stable/gangway -f values.yaml

Tip: You can copy the default values.yaml and make any required edits in there

SSL Configuration

1. Edit values.yaml

   1. Set gangway.serveTLS to true.
   2. Set livenessProbe.scheme and readinessProbe.scheme to HTTPS.

2. Pass the TLS configuration to Gangway:

   • Either by pasting the certificate and private key in the values.yaml like:
   yamlCopy

   tls:
     certData: |
       -----BEGIN CERTIFICATE-----
       ...
       -----END CERTIFICATE-----
     keyData: |
       -----BEGIN ENCRYPTED PRIVATE KEY-----
       ...
       -----END ENCRYPTED PRIVATE KEY-----
   

   • Or by specifying an existing secret in the values.yaml like:
   yamlCopy

   ...
   tls:
     existingSecret: my-tls-secret
   ...
   

   NB: The secret must contain two entries, tls.crt and tls.key; it will be mounted into /etc/gangway/tls/ and e.g. /etc/gangway/tls/tls.crt is the default path for gangway.certFile. Otherwise adjust gangway.certFile and gangway.keyFile accordingly.