Make kerberos keytab updates dynamic

Ismael Posada Troborequested to merge
iposadat/gitlab:make-krb-dynamic into master

What does this MR do?

The GitLab upstream chart mounts the keytab in a manner that prevents the kubelet from updating it when the secret changes (ref: https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/charts/gitlab/templates/_kerberos.tpl). This is because of the use of the subPath element in the mount (ref: https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/charts/gitlab/templates/_kerberos.tpl#L27).

According to https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod, "A container using a Secret as a subPath volume mount does not receive automated Secret updates".

In scenarios where node autoscaler is available, provisioning new nodes and eventually generate a new keytab is not enough for GitLab to start considering these new keytabs. The application requires a restart in order the keytab secret with the new values to be taken into account by the deployments.

This MR tries to solve this limitation by using a projected volume instead, which seems to bypass this limitation (according to https://kubernetes.io/docs/concepts/configuration/secret/ > "As a result, the total delay from the moment when the Secret is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay"), and allow node autoscaler scenarios to dynamically update keytabs.

Required

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

  • Merge Request Title and Description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • MR has a green pipeline.
  • Documentation created/updated.
  • Tests added/updated, and test plan for scenarios not covered by automated tests.
  • Equivalent MR/issue for omnibus-gitlab opened.

Reviewers checklist

Edited by Jason Plum

Merge request reports