Introduce CloudConnector::Keys model

What does this MR do and why?

Replaces !178857 (merged) which introduced a similar change but was storing these keys as an application setting. We had to revert this change since it resulted in an incident: 2025-01-28: gstg-migrations job is failing due ... (gitlab-com/gl-infra/production#19182 - closed). The old setting was already dropped in Add post-deploy migration to drop cloud_connect... (!179672 - merged) and related MRs.

IMPORTANT: This MR should not be deployed before the following two issues are resolved:


This adds a new table, cloud_connector_keys, which stores encrypted RSA keys for use with Cloud Connector. For now, we store 2 keys:

  • The existing (shared) OIDC key, which is in use today. We will later rotate away from this key.
  • A newly generated key. We will later rotate toward this key. This will also happen in a follow-up MR.

The idea here is to always have between 1 and 2 keys stored (in EE setups), with the oldest being used as the current key. As part of the key rotation we then drop the oldest key and promote the next-newer key to become the current key.

Note that in this MR, this table remains unused. We will for now keep reading keys from Rails.application.credentials; using keys from this table will happen in this change instead: https://gitlab.com/gitlab-org/gitlab/-/issues/512450+

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

  1. Make sure migrations have run
  2. start Rails console
  3. Run CloudConnector::Keys.all

This should return an array with 2 PEM encoded keys.

Related to #512449

Edited by Matthias Käppler

Merge request reports

Loading