Provide encrypted ldap credentials through rails
Problem to solve
Allow users to avoid the ldap passwords from being stored in plaintext on the filesystem. This is a specific MVC of the wider plaintext secrets epic here: &2548
The task is to introduce a way to ensure that the ldap secrets are not available in plaintext on the filesystem. With the idea that this same approach could be used for other secrets other than ldap in the future. An additional consideration was that a Vault integration was not acceptable to the customers that we have been working with on this.
The idea is to have a minimal change for allowing us to eliminate plaintext ldap passwords, with the plan that in the future we could add a vault and other kms backends for this. (I tried looking for existing gems that provided these backends, but didn't find one for ruby that had good support for multiple backends).
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
User experience goal
As an MVC, and to meet much of the customer validation goals set forth in &2548, provide a method of encrypting the ldap secrets without introducing an additional dependency on a external service.
The user should be able to provide their ldap password, without having it stored in plaintext on the filesystem.
Build on the POC that was completed in !33904 (closed)
GitLab will generate a new secret key, to be used in encrypted ldap passwords. Admins are able to provide ldap passwords to gitlab through a new rake command that encrypts the provided passwords, and stores them encrypted within a encrypted ldap passwords file.
GitLab will read passwords from the encrypted ldap password file when ldap is enabled, and the encrypted ldap password file is found on the filesystem. When the ldap integration grabs the ldap password, it first checks the plaintext config, then the encrypted secrets. Allowing current users to continue to use unencrypted passwords for now.
The MVC should expand on the POC in the following:
- It should not use the db_key_base, but instead have its own new secret key
- The encrypted password file needs to default to being stored in a seperate directory from the secret
- The rake task that encrypts secrets should support being piped passwords and not require creation of a tempfile in those cases.
Use cases we have heard
Feedback from customer interviews