Skip to content

Extend encrypted secrets support to incoming and service desk email

Jason Youngrequested to merge
encrypt-mailroom-passwords into master

This merge request is part of omnibus-gitlab#6273 (closed)

What does this MR do and why?

This enables the use of an encrypted file to store the user and password used for the Incoming Email and Service Desk custom mailbox configuration, in lieu of storing the password within the gitlab.yml configuration file in plaintext.

This makes use of the encrypted_settings feature added in %13.7 with !43220 (merged) and subsequently used for storing LDAP and SMTP credentials in an encrypted file.

New rake commands:

  • gitlab:incoming_email:secret:write : can be used to pipe plaintext content into the encrypted file
  • gitlab:incoming_email:secret:edit : allows editing/creating encrypted secrets with a specified editor
  • gitlab:incoming_email:secret:show : decrypts the encrypted file contents to stdout

For Service Desk - the functions are the same for the following new rake commands:

  • gitlab:service_desk_email:secret:write
  • gitlab:service_desk_email:secret:edit
  • gitlab:service_desk_email:secret:show

One complication with implementing this feature for the Incoming/Service Desk Email configuration is that the gitlab.yml configuration is rendered as ERB into the mail_room.yml configuration by the Gitlab::MailRoom library - which is loaded standalone as part of the mailroom process and not the Rails application. The library reads gitlab.yml directly instead of accessing it through Gitlab.config/Settings.

Making use the encrypted settings in Gitlab.config/Settings would require loading a significant number of libraries for rendering the configuration - so in this merge request - I'm directly loading Gitlab::EncryptedConfiguration - and the portions of active_support that EncryptedConfiguration requires - this also required parsing the application secrets directly in order to read in encrypted_settings_key_base to decrypt the encrypted file.

How to set up and validate locally

  1. Ensure encrypted configuration keys are enabled: https://docs.gitlab.com/ee/administration/encrypted_configuration.html 
    bundle exec rake gitlab:env:info RAILS_ENV=development GITLAB_GENERATE_ENCRYPTED_SETTINGS_KEY_BASE=true
  2. Create encrypted secrets, and uncomment the defaults 
    bundle exec rake gitlab:incoming_email:secret:edit EDITOR=vim
  3. Confirm the secrets show in the rails app by running a rails console 
    > Gitlab::MailRoom.send(:configs)

Additionally, you can set incoming_email.enabled: true in the config/gitlab.yml and inspect the settings in the rails console with Gitlab::MailRoom.enabled_configs.

The same can be done with the service_desk_email settings - using the same encrypted_settings_key_base created in Step One above.

  1. Create encrypted secrets, and uncomment the defaults 
    bundle exec rake gitlab:service_desk_email:secret:edit EDITOR=vim
  2. Confirm the secrets show in the rails app by running a rails console 
    > Gitlab::MailRoom.send(:configs)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Jason Young

Merge request reports