Improve KAS TLS UX

What does this MR do?

Adds a global value to help enabling TLS for KAS endpoints.

This will reduce the amount of configuration one needs to do as described in https://docs.gitlab.com/charts/charts/gitlab/kas/index.html#chart-configuration-values.

It also removes a leftover typo draft documentation, which talked about kas.tls.host. This attribute does not exist. It was created in a draft MR, then removed in the same MR, but we forgot to remove the draft documentation about it, which accidentally got merged.

Omnibus counterpart: gitlab-org/omnibus-gitlab#7368

Needed values diff

.internal-ca: &internal-ca gitlab-internal-tls-ca # The secret name you used to share your TLS CA.
.internal-tls: &internal-tls gitlab-internal-tls # The secret name you used to share your TLS certificate.

certmanager-issuer:
  email: your.email@gitlab.com

global:
  certificates:
    customCAs:
    - secret: *internal-ca
  hosts:
    domain: gitlab.example.com # Your gitlab domain
+  kas:
+    tls:
+      enabled: true
+      secretName: *internal-tls
+      caSecretName: *internal-ca
-  appConfig:
-    gitlab_kas:
-      internalUrl: "grpcs://RELEASE-kas.NAMESPACE.svc:8153" # Replace RELEASE and NAMESPACE with your chart's release and namespace 
-
-gitlab:
-  kas:
-    privateApi:
-      tls:
-        enabled: true
-        secretName: *internal-tls
-    customConfig:
-      api:
-        listen:
-          certificate_file: /etc/kas/tls.crt
-          key_file: /etc/kas/tls.key
-      agent:
-        listen:
-          certificate_file: /etc/kas/tls.crt
-          key_file: /etc/kas/tls.key
-        kubernetes_api:
-          listen:
-            certificate_file: /etc/kas/tls.crt
-            key_file: /etc/kas/tls.key
-    ingress:
-      annotations:
-        nginx.ingress.kubernetes.io/backend-protocol: https
-        nginx.ingress.kubernetes.io/proxy-ssl-name: RELEASE-kas.NAMESPACE.svc # Replace RELEASE and NAMESPACE with your chart's release and namespace
-        nginx.ingress.kubernetes.io/proxy-ssl-secret: NAMESPACE/CA-SECRET-NAME # Replace NAMESPACE and CA-SECRET-NAME with your chart's namespace and CA secret name. The same you used for &internal-ca.
-        nginx.ingress.kubernetes.io/proxy-ssl-verify: on

Important for testing

During this implementation we found out a regression on KAS when enabling TLS. To test this change one needs to use an older KAS tag, which is before the regression:

gitlab:
  kas:
    image:
      tag: "92cbdb9e7a7f7b27e50ad44e578e87598759a57a"

UPDATE: The above tag change is not necessary anymore, as the fix already reached master.

---

Here is the full values.yaml that I've used to test this change. Remember to set:

• your own email for cert manager.
• GitLab host.
• Self-signed certificates following docs that we're adding here.

.internal-ca: &internal-ca gitlab-internal-tls-ca
.internal-tls: &internal-tls gitlab-internal-tls

certmanager-issuer:
  email: YOUR@EMAIL.COM

global:
  certificates:
    customCAs:
    - secret: *internal-ca
  workhorse:
    tls:
      enabled: true
  gitaly:
    tls:
      enabled: true
      secretName: *internal-tls
  gitlabVersion: v15.7.0
  image:
    pullPolicy: Always
  hosts:
    domain: YOUR.DOMAIN.COM
  kas:
    tls:
      enabled: true
      secretName: *internal-tls
      caSecretName: *internal-ca
gitlab:
  webservice:
    tls:
      enabled: true
      secretName: *internal-tls
    metrics:
      tls:
        enabled: true
        secretName: *internal-tls
    workhorse:
      tls:
        secretName: *internal-tls
        verify: true
        caSecretName: *internal-ca
      monitoring:
        ## by default, the Workhorse metrics are not enabled.
        exporter:
          enabled: true
          tls:
            enabled: true
  gitlab-exporter:
    tls:
      enabled: true
      secretName: *internal-tls
  sidekiq:
    metrics:
      tls:
        enabled: true
        secretName: *internal-tls
  gitlab-pages:
    metrics:
      tls:
        enabled: true
        secretName: *internal-tls

After the chart is installed with TLS enabled, one just needs to:

• Install an agent on an empty project and configure it to use the CI/CD workflow.
• Create a .gitlab-ci.yml to send any Kubernetes API request.

Related issues

#3843 (closed)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.