Solution Validation: Encrypting the LDAP password in GitLab config files
What's this issue all about? (Background and context)
The LDAP password used to connect to a customer's LDAP server is stored in clear text in GitLab configuration files. This is unacceptable for some customers. See the epic for more details about the problem. Two research spikes have been completed and a POC is underway. This issue is to track user feedback to validate the proposed solution and next iterations.
What are the overarching goals for the research?
Validate the proposed solution and identify additional customer needs
What hypotheses and/or assumptions do you have?
The proposed solution will address the most basic need of not storing the LDAP password in plain text in the GitLab configuration files. Customers would like to extend this work to cover all passwords stored in GitLab configuration files. Customers will have their own password storage solutions and will want a more automated way to extract passwords from those systems for consumption by GitLab.
What research questions are you trying to answer?
- Describe your current and desired workflow for managing secrets
- The encryption key for the encrypted password file is stored in plaintext in
/etc/gitlab/gitlab-secrets.json
. Is that okay? (Note: access to the secrets file requiresroot
orgit
user - Does
/etc/gitlab/gitlab-secrets.json
need to be able to reside on a different filesystem? If so, does a symlink suffice? - How important is it to encrypt user names?
- Do you have a password rotation policy?
- Do you have a key rotation policy for encryption keys?
- To what extent would you need configuration passwords separated out into different encrypted files? (LDAP, incoming mail, root user initial password, PostgreSQL, Redis, Grafana). List of passwords
- What immediate needs do you have that are not addressed by the solution?
- Do you currently have a password management system? What system are you using? How important is it to incorporate the system into this workflow? Have you created any tooling to help use your password management system with other applications?
What persona, persona segment, or customer type experiences the problem most acutely?
- Organizations with password encryption requirements and security audits
- GitLab administrators
- Security teams
Who will be leading the research?
Distribution Product Manager, Larissa Lane
What timescales do you have in mind for the research?
July/Aug 2020, aiming to have a solution implemented by 13.4 or 13.5 depending on the results from the POC
Relevant links (script, prototype, notes, etc.)
Known customers that want passwords encrypted
- https://gitlab.lightning.force.com/lightning/r/Account/00161000003QEzIAAW/view - customer feedback here
- https://gitlab.lightning.force.com/lightning/r/0016100001F5NxWAAV/view - see comment here
- https://gitlab.zendesk.com/agent/tickets/122189 (feedback call being scheduled)
- https://gitlab.lightning.force.com/lightning/r/Account/0016100001Eo26OAAR/view (see omnibus-gitlab#5048 (comment 284547404))
- https://gitlab.zendesk.com/agent/tickets/156599 - Internal outreach - call scheduled for 2020/07/22
- https://gitlab.my.salesforce.com/0064M00000WtWNi?srPos=0&srKp=006 - Customer interview conducted through email
- https://gitlab.my.salesforce.com/00161000019g5u9AAA and https://gitlab.zendesk.com/agent/tickets/142874 - Internal outreach
- https://gitlab.lightning.force.com/lightning/r/Account/0016100000Nm6rTAAR/view - Internal outreach - call scheduled for 2020/07/28
- https://gitlab.lightning.force.com/lightning/r/Account/00161000006g0bBAAQ/view and https://gitlab.zendesk.com/agent/tickets/136012 - [Internal outreach] (https://gitlab.slack.com/archives/DR8JKUQJC/p1595284199002000) - May not be a priority since they moved to Okta
- https://gitlab.lightning.force.com/lightning/r/Account/00161000004bZPDAA2/view - Validation call scheduled for 2020-08-07