WIP: POC for providing encrypted ldap passwords

What does this MR do?

Introduced a few rake commands to enable editing some gitlab specific encrypted files using the Rails ActiveSupport EncryptedFile class. This is similar to how the rails encrypted credentials work.

In this POC, I've introduced a new rake command: gitlab:ldap:secret:edit that opens a encrypted yaml file in your console editor for storing ldap passwords. The file format is intended to be a password: <your password> nested under your provider as a yaml key.

main:
  password: my-password

Part of: omnibus-gitlab#5290 (closed)

What is this trying to solve

The task for omnibus-gitlab#5290 (closed) 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 with this POC is to have a minimal change for allowing us to eliminate plaintext ldap passwords, with the idea 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).

An alternative MVC might be to use SOPs https://github.com/mozilla/sops, but it wasn't clear to me how to enable our rails app to read the values (without introducing plaintext passwords on the filesystem).

Integrating with other systems

The long term plan would be to add build-in support for common secrets and kms systems into gitlab. But ones we do not support could potentially have a translation script to transfer the secrets from the existing system to this one.

In the current POC this can be done likes so:

# decrypt points to an existing file encoded with some other system
EDITOR="decrypt blah.yaml.enc" bundle exec rake gitlab:ldap:secret:edit

# secret grabs the secret directly from the third party system
EDITOR="secret" bundle exec rake gitlab:ldap:secret:edit

cat decrypt
#!/bin/bash
gcloud kms decrypt --key dj-key --keyring dj-test-kms --plaintext-file=$2 --ciphertext-file=$1 --location=us-west1

cat secret
#!/bin/bash
gcloud secrets versions access latest --secret="dj-test-secret" > $1

Note the POC currently only exposes the EDITOR env variable to be able to do this, but we can expand it to accept stdin, and add options to avoid it writing to the tmp file.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team