Application-level trust store for X.509 signature verification

Summary

Currently, /etc/gitlab/trusted-certs is used at the datastore for trusted roots for X.509 signature verification. I don't think this is suitable for this use-case for a number of reasons.

1. These same roots are used for verifying TLS connections.
2. Adding certs in this way requires placing certs on the file system. Generally, we don't want GitLab to be configured in this way because it's not conducive for cloud native / Kubernetes deployments (which is how GitLab.com is deployed). It's doable with a volumeMount or a secret, but it would be better if this were configured via the application rather than the system.
3. This is an instance-wide change, but organizations likely want to be selective about which root certs they trust. Therefore, we ought to have a way to configure this on a per-namespace basis. Such a change would also enable people to use X.509 signed commits on GitLab.com.

Proposal

We should store these roots in the database instead. This will allow them to be managed via the application, and each namespace can have a separate set of trusted CAs. Organizations would be able to use their own CA roots on GitLab.com.

1. Roots can be added via the group settings or project settings.
2. Instance-wide trusted roots can be added via the admin area.
3. (Nice to have?) On GitLab.com, groups can opt-out of the instance-level trusted roots.

Relevant links

Non-functional requirements

• Documentation:
• Feature flag:
• Performance:
• Testing:

Implementation plan

Verification steps