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
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
, duration10s
, URIscheme://user:passwd@host:port
may require quotation or other special handling when rendered in a template and written to a configuration file.