Cells: Secrets & Credentials

Where possible, each Cell should have its own distinct set of secrets. However, there will be some secrets that will be required to be the same for all Cells in the cluster.

1. Definition

GitLab has a few secrets that need to be configured. These secrets are stored in different locations depending on the installation method.

• Secrets for encryption: secret_key_base (session data) and db_key_base (encryption at rest in the database).
• Secrets for features: otp_key_base and openid_connect_signing_key.
• Secret for encrypted files (similar to the Rails credentials feature): encrypted_settings_key_base.

In addition to secrets stored in the “secrets” file, GitLab also uses specific secret files for inter-component communication, for example, GitLab Shell secret, and used only within a Cell.

Last but not least, many features need credentials to be set up. These credentials are stored in different locations depending on the installation method:

• /etc/gitlab/gitlab.rb for Omnibus
• Kubernetes secrets for Charts
• config/gitlab.yml for source installation

2. Data flow

3. Proposal

1. secret_key_base is used for: encrypted cookies, signed cookies, and Active Storage files, based on https://guides.rubyonrails.org/security.html#session-storage. We don’t use Active Storage, as far as I know, so it’s only cookies that are affected. Given that for Cells 1.0, users will be tied to a single cell, and since the session cookie will include the cell ID in its name, it’s fine to have a unique secret_key_base per Cell. Investigation issue: secret_key_base.
2. db_key_base is used for encryption at rest in the database, and will need to be consistent across all Cells, so that data can be moved easily between Cells. Investigation issue: db_key_base.
   1. This is especially true for the db_key_base secret which is used for encrypting data at rest in the database - so that Projects that are transferred to another Cell will continue to work. We do not want to have to re-encrypt such rows when we move Projects/Groups between Cells.
   2. In the future, we might support rotating such secrets, so that if the Org mover needs to move an organization from Cell1 to Cell2, it would decrypt data with Cell1 key and then re-encrypt it with Cell2 key. This is out of scope for Cells 1.0.
3. Secrets for features (otp_key_base and openid_connect_signing_key) will need to be consistent across all Cells, so that the UX is consistent. Investigation issues: otp_key_base, openid_connect_signing_key.
   1. Since we’ll support cluster-wide Application Settings, we should first migrate these secrets to ApplicationSetting attributes first, so that the consistency of their value on each Cell is handled by the Application Settings synchonization mechanism.
4. Secrets for encrypted files can be different on each Cell, as long as the credentials inside the encrypted files are the same. That said, it might be simpler to also use the same encrypted_settings_key_base on all Cells for simplicity sake. Investigation issue.
5. Secrets for inter-component communication inside a Cell only should be uniquely generated per Cell.
6. In general, credentials for various features should be the same on all Cells, unless a feature is set up in a Cell-specific way (e.g. if LDAP needs to be set up on a specific Cell). GitLab Dedicated already have a solution for sharing SMTP credentials in a multi-tenant environment so we should use a similar solution to set up cluster-wide configuration.

4. Evaluation

4.1. Pros

• Secrets are consistent accross most cells
• No need to handle data migration between cells

4.2. Cons

• Security of cells is not higher than the current GitLab.com installation

View page source - Edit this page - please contribute.