Allow deployment with manually installed TLS Secrets

DEPLOYMENT.md

@@ -170,7 +170,9 @@ or [mino](https://github.com/helm/charts/tree/master/stable/minio#configuration)
 | `app.ingress.enabled`                | Enable install of ingress                        | false                                                   |
 | `app.ingress.host`                   | Hostname to associate ingress with               | servicex.ssl-hep.org                                    |
 | `app.ingress.defaultBackend`         | Name of a service to send requests to internal endpoints to | default-http-backend                         |
-| `app.ingress.clusterIssuer`          | Name of the ClusterIssuer to use which will be used to obtain a TLS certificate | letsencrypt-staging      |
+| `app.ingress.tls.enabled`            | Enable TLS for ServiceX API Ingress resource     | false                                                   |
+| `app.ingress.tls.secretName`         | Name of TLS Secret used for ServiceX API server  | `{{.Release.Name}}-app-tls`                             |
+| `app.ingress.tls.clusterIssuer`      | Specify a ClusterIssuer if using cert-manager    | -                                                       |
 | `app.resources`                      | Pass in Kubernetes pod resource spec to deployment to change CPU and memory | { }                          |    
 | `app.slackSigningSecret`             | Signing secret for Slack application             | -
 | `app.newSignupWebhook`               | Slack webhook URL for new signups                | -

docs/deployment/production.md

@@ -22,7 +22,7 @@ is of limited value. We will now update `values.yaml` to add external ingress.
 ### Adding an Ingress to the ServiceX app
 
 Configure an Ingress resource for the ServiceX API server by adding the 
-following section to your `values.yaml`:
+following section to your values file:
 ```yaml
 app:
     ingress:
@@ -45,59 +45,112 @@ app:
 ```
 and you deployed the helm chart with
 ```
-helm install -f values.yaml --version v1.0.0-rc.3 xaod ssl-hep/servicex
+helm install -f values.yaml --version v1.0.0-rc.3 my-release ssl-hep/servicex
 ```
-then the instance's URL would be `xaod.servicex.ssl-hep.org`.
+then the instance's URL would be `my-release.servicex.ssl-hep.org`.
 
 You should also make sure the host has a DNS A record pointing this 
 subdomain at the external IP address of your ingress controller.
 
 ### Adding an Ingress to Minio
 ServiceX stores files in a Minio object store which is deployed as a 
-subchart. The helm chart for Minio has it's own support for an Ingress,
+subchart. The Helm chart for Minio has it's own support for an Ingress,
 which we can activate like so:
 
 ```yaml
 minio:
   ingress:
     enabled: true
     hosts:
-    - xaod-minio.servicex.ssl-hep.org
+    - my-release-minio.servicex.ssl-hep.org
 ```
 
-Unlike the ServiceX Ingress, the subchart doesn't know the 
-name of our deployment, so you need to correctly set the deployment name in 
-the Minio Ingress address. It should be set to 
-`<helm release name>-minio.<app.ingress.host value>`.
+Unlike the ServiceX Ingress, the subchart doesn't know the name of our 
+deployment, so you need to hardcode it in the Minio Ingress host
+(this is a current limitation of the Minio chart). 
+The value should be `<helm release name>-minio.<app.ingress.host value>`.
 
-## Securing the deployment
-If you wish, you could deploy these values and have a ServiceX instance that
-is not secured but is reachable via the public URL.
-This is okay for a sneak peek, but not recommended for long-lived deployments, 
-since your grid certs will be usable by anyone on the Internet.
 
-To prevent this, ServiceX supports an authentication system which requires 
-new users to create accounts with your ServiceX deployment by authenticating 
-to Globus with the identity provider of their choice 
-(such as CERN or their university).
+## Configuring Ingress resources to use TLS
+It's a good idea to enable TLS for both of these Ingress resources.
+There are two ways to do this: you can either obtain certificates and
+install the TLS Secrets manually, or you can use the 
+[cert-manager](https://cert-manager.io/docs/) Kubernetes add-on to 
+issue certificates and create the Secrets automatically.
+Separate guides for both options are provided below.
+
+Either way, the first step is to set `app.ingress.tls.enabled` to `true`.
+
+### Without cert-manager
+First, obtain a TLS certificate and private key for each Ingress 
+(two pairs in total).
+This can be done using a trusted Certificate Authority (CA), such as 
+[Let's Encrypt](https://letsencrypt.org/).
+Make sure that each certificate Common Name matches the hostname of the 
+corresponding Ingress.
+
+Once you have your certs, you can install them to your cluster as [TLS Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets):
+
+`kubectl create secret tls <secret_name> --cert=<cert path> --key=<key path>`
 
-### Obtain a TLS Certificate
-Globus Auth requires your deployment to be served over HTTPS.
-To obtain a TLS certificate, complete the following steps:
+By default, the ServiceX chart looks for a Secret named 
+`<helm release name>-app-tls`. You can specify a different name in your values 
+using `app.ingress.tls.secretName`.
 
-- Install the [cert-manager](https://cert-manager.io/docs/) Kubernetes add-on.
-- Deploy one or more ClusterIssuers.
+Your final values should look something like:
+```yaml
+app:
+  ingress:
+    enabled: true
+    host: servicex.ssl-hep.org
+    tls:
+      enabled: true
+      secretName: my-release-app-tls
+```
+
+Adding TLS to the Minio subchart is slightly different.
+The configuration is as follows:
+```yaml
+minio:
+  ingress:
+    enabled: true
+    annotations:
+      kubernetes.io/ingress.class: nginx
+    hosts:
+    - my-release-minio.servicex.ssl-hep.org
+    tls:
+    - hosts:
+      - my-release-minio.servicex.ssl-hep.org
+      secretName: my-release-minio-tls
+```
+Remember to replace `my-release` and `servicex.ssl-hep.org` with your Helm release name and app ingress host, respectively. 
+Here, you must specify a secret name; there is no default.
+
+### With cert-manager
+Alternately, you can let cert-manager handle the TLS certificates.
+To use it, complete the following steps:
+- [Install cert-manager](https://cert-manager.io/docs/installation/kubernetes/)
+on your cluster if it's not already installed.
+- Deploy one or more ClusterIssuers, or check that one is already present. 
 The Let's Encrypt staging and production ClusterIssuers are recommended.
-- In `values.yaml`, set `app.ingress.clusterIssuer` to the name of the
-ClusterIssuer you'd like to use. The default value is `letsencrypt-prod`.
-Bear in mind that this is subject to
-[rate limits](https://letsencrypt.org/docs/rate-limits/),
+- In `values.yaml`, set `app.ingress.tls.clusterIssuer` to the name of the
+ClusterIssuer you'd like to use (e.g. `letsencrypt-prod`).
+Browsers will trust `letsencrypt-prod` automatically, but bear in mind that 
+it's subject to [rate limits](https://letsencrypt.org/docs/rate-limits/),
 so it's best to use `letsencrypt-staging` for development.
 
+Your values should now look like:
+```yaml
+app:
+  ingress:
+    tls:
+      enabled: true
+      clusterIssuer: letsencrypt-prod
+```
+
 For more information, see the cert-manager [guide to securing nginx-ingress](https://cert-manager.io/docs/tutorials/acme/ingress).
 
-TLS can also be enabled for Minio. To do so using cert-manager and the 
-Let's Encrypt ClusterIssuer, use the following configuration:
+To enable TLS for Minio, use the following configuration:
 ```yaml
 minio:
   ingress:
@@ -107,16 +160,31 @@ minio:
       cert-manager.io/cluster-issuer: letsencrypt-prod
       acme.cert-manager.io/http01-edit-in-place: "true"
     hosts:
-    - xaod-minio.servicex.ssl-hep.org
+    - my-release-minio.servicex.ssl-hep.org
     tls:
     - hosts:
-      - xaod-minio.servicex.ssl-hep.org
-      secretName: xaod-minio-tls
+      - my-release-minio.servicex.ssl-hep.org
+      secretName: my-release-minio-tls
 ```
-Remember to replace `xaod` and `servicex.ssl-hep.org` with your Helm release 
-name and app ingress host, respectively.
+Once again, remember to replace `my-release` and `servicex.ssl-hep.org` with 
+your Helm release name and app ingress host, respectively.
+
+## Securing the deployment with authentication
+If you wish, you could deploy these values and have a ServiceX instance that
+is not secured but is reachable via the public URL.
+This is okay for a sneak peek, but not recommended for long-lived deployments, 
+since your grid certs will be usable by anyone on the Internet.
+
+To prevent this, ServiceX supports an authentication system which requires 
+new users to create accounts with your ServiceX deployment by authenticating 
+to Globus with the identity provider of their choice 
+(such as CERN or their university).
+
 
 ### Setting up Globus Auth
+Globus Auth requires your deployment to be served over HTTPS,
+so make sure you have completed the TLS section above.
+
 Visit [developers.globus.org](https://developers.globus.org) 
 and select ___Register your app with Globus___. 
 Create a project for ServiceX and within that project click on 
@@ -131,7 +199,7 @@ profile
 
 The redirect URL will be your host followed by `/auth-callback`.
 In the earlier example, the redirect would be
-`https://xaod.servicex.ssl-hep.org/auth-callback`.
+`https://my-release.servicex.ssl-hep.org/auth-callback`.
 If you want to use port-forwarding, also include
 `http://localhost:5000/auth-callback`.
 
@@ -174,23 +242,27 @@ a tool like Postman or curl.
 To set this up, complete the following steps **before deploying** ServiceX:
 
 - Create a secure Slack channel in your workspace (suggested name: `#servicex-signups`), accessible only to developers or administrators of ServiceX. 
-- Go to https://api.slack.com/apps and click **Create New App**. Fill in ServiceX as the name and choose your workspace. If you are going to make multiple ServiceX deployments, 
+- Go to https://api.slack.com/apps and click **Create New App**. 
+Fill in ServiceX as the name and choose your workspace. 
+If you are going to make multiple ServiceX deployments, 
 you may want a more descriptive name, such as "ServiceX xAOD".
-- Scroll down to the App Credentials section and find your Signing Secret. Copy this value and place it in your `values.yaml` file as `app.slackSigningSecret`.
+- Scroll down to the App Credentials section and find your Signing Secret. 
+Copy this value and place it in your values file as `app.slackSigningSecret`.
 - Scroll up to the feature list, click on Incoming Webhooks, and click the switch to turn them on.
 - Click the **Add New Webhook to Workspace** button at the bottom, choose your signups channel, and click the **Allow** button.
-- Copy the Webhook URL and store it in `values.yaml` under `app.newSignupWebhook`.
+- Copy the Webhook URL and store it in your values under `app.newSignupWebhook`.
 - After completing the rest of the configuration, deploy ServiceX.
 - Go back to the [Slack App dashboard](https://api.slack.com/apps) and choose the app you created earlier. In the sidebar, click on Interactivity & Shortcuts under Features.
-- Click the switch to turn Interactivity on. In the Request URL field, enter the base URL for the ServiceX API, followed by `/slack`, e.g. `https://xaod.servicex.ssl-hep.org/slack`. Save your changes.
+- Click the switch to turn Interactivity on. In the Request URL field, enter the base URL for the ServiceX API, followed by `/slack`, e.g. 
+`https://my-release.servicex.ssl-hep.org/slack`. Save your changes.
 - You're all set! ServiceX will now send interactive Slack notifications to your signups channel whenever a new user registers.
 
 ### Email Notifications
 ServiceX can send email notifications to newly registered users via 
 [Mailgun](https://www.mailgun.com/) once their access has been approxed by an 
 administrator. To enable this, obtain a Mailgun API key and 
 [verified domain](https://documentation.mailgun.com/en/latest/quickstart-sending.html#verify-your-domain) 
-and set `app.mailgunApiKey` and `app.mailgunDomain` in your `values.yaml`.
+and set `app.mailgunApiKey` and `app.mailgunDomain` in your values file`.
 
 ## Scaling
 We are still experimenting with various configurations for deploying a scaled-up

servicex/templates/app/ingress.yaml

@@ -4,19 +4,19 @@ kind: Ingress
 metadata:
   annotations:
     kubernetes.io/ingress.class: nginx
-    {{- if .Values.app.ingress.clusterIssuer }}
-    cert-manager.io/cluster-issuer: {{ .Values.app.ingress.clusterIssuer }}
+    {{- if .Values.app.ingress.tls.clusterIssuer }}
+    cert-manager.io/cluster-issuer: {{ .Values.app.ingress.tls.clusterIssuer }}
     acme.cert-manager.io/http01-edit-in-place: "true"
     {{- end }}
   labels:
     app: {{ .Release.Name }}-servicex
   name: {{ .Release.Name }}-servicex
 spec:
-  {{- if .Values.app.ingress.clusterIssuer }}
+  {{- if .Values.app.ingress.tls.enabled }}
   tls:
   - hosts:
     - {{ .Release.Name }}.{{ .Values.app.ingress.host }}
-    secretName: {{ .Release.Name }}-tls
+    secretName: {{ tpl .Values.app.ingress.tls.secretName . }}
   {{- end }}
   rules:
   - host: {{ .Release.Name }}.{{ .Values.app.ingress.host }}

servicex/values.yaml

@@ -45,7 +45,11 @@ app:
     enabled: false
     host: servicex.ssl-hep.org
     defaultBackend: default-http-backend
-    clusterIssuer: letsencrypt-prod
+    tls:
+      enabled: false
+      secretName: "{{.Release.Name}}-app-tls"
+      # Specify a ClusterIssuer if using cert-manager:
+      clusterIssuer:
 
   # RabbitMQ can take up to one minute to start up. Simplify app startup by waiting for it
   rabbitmq: