blob: 20260c89ccd2ef0aac69e254b750e40bb1d6ebcb (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
---
stage: enablement
group: Tenant Scale
description: 'Cells: Secrets'
---
<!-- vale gitlab.FutureTense = NO -->
This document is a work-in-progress and represents a very early state of the
Cells design. Significant aspects are not documented, though we expect to add
them in the future. This is one possible architecture for Cells, and we intend to
contrast this with alternatives before deciding which approach to implement.
This documentation will be kept even if we decide not to implement this so that
we can document the reasons for not choosing this approach.
# Cells: Secrets
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 lot of
[secrets](https://docs.gitlab.com/charts/installation/secrets.html) that needs
to be configured.
Some secrets are for inter-component communication, e.g. `GitLab Shell secret`,
and used only within a cell.
Some secrets are used for features, e.g. `ci_jwt_signing_key`.
## 2. Data flow
## 3. Proposal
1. Secrets used for features will need to be consistent across all cells, so that the UX is consistent.
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.
1. Secrets which are used for intra-cell communication only should be uniquely generated
per-cell.
## 4. Evaluation
## 4.1. Pros
## 4.2. Cons
|
