Skip to content

Makes TLS communication between KAS pods possible

João Alexandre Cunha requested to merge feat/adds-kas-to-kas-tls-configuration into master

What does this MR do?

KAS pods talks to other KAS pods through the private_api. TLS communication between them was implemented in gitlab-org/cluster-integration/gitlab-agent!741 (merged) and gitlab-org/cluster-integration/gitlab-agent!754 (merged). The TLS configuration for the kas binary happens through these 3 new configs:

private_api:
  listen:
    certificate_file: "/foo/bar/tls.crt"
    key_file: "/foo/bar/tls.key"
    ca_certificate_file: "/foo/bar/ca.crt"

and also, the user is expected to provide an OWN_PRIVATE_API_HOST env variable, with a host that should be added to the /foo/bar/tls.crt SANs.

The proposed solution here is:

  1. Rely on the existing internal TLS mechanism that adds support to the chart to share and mount trusted CAs across GitLab chart components.
  2. Add support to gitlab.kas.privateApi.tls.enabled and gitlab.kas.privateApi.tls.secretName chart values, so that we can:
    • Decide when to mount the TLS secrets and configure KAS with with them through gitlab.kas.privateApi.tls.enabled.
    • Mount the Kubernetes TLS secret based on the gitlab.kas.privateApi.tls.secretName.
  3. Allow the user to set the OWN_PRIVATE_API_HOST env through gitlab.kas.privateApi.host.

Disclaimer, this relies on 2 KAS MRs that got merged very recently (gitlab-org/cluster-integration/gitlab-agent!754 (merged), gitlab-org/cluster-integration/gitlab-agent!753 (merged)). Since those were not yet part of the CNG gitlab-kas master branch based image, I've tested this forcing the image to be built from master, see job: https://gitlab.com/gitlab-org/build/CNG/-/jobs/3154967262. The image hash is registry.gitlab.com/gitlab-org/build/cng/gitlab-kas:096b44b65047955fa6956ab89911d5a7a4eaed77. As soon as the next master pipeline runs on the CNG project, using this specific image to test won't be necessary anymore.

Related issues

Implements gitlab-org/gitlab#375328 (closed).

Omnibus counterpart issue: gitlab-org/gitlab#375327 (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.
Edited by João Alexandre Cunha

Merge request reports