How is `encrypted_settings_key_base` handled?

[nemonik]

encrypted_settings_key_base was introduced starting with 13.7

https://docs.gitlab.com/ee/administration/encrypted_configuration.html#encrypted-configuration

The Omnibus Helm chart https://docs.gitlab.com/charts/installation/secrets.html#gitlab-rails-secret handles this secret in this manner. It seems it can be autogenerated, but this may present data migration or restore to Omnibus problems.

How is sameersbn/docker-gitlab handling encrypted_settings_key_base? it isn't being set... There is no /etc/gitlab/gitlab-secrets.json as values are passed in as environmental variable...

I need to know this in order to migrated a backup out of sameersbn/docker-gitlab to an Omnibus GitLab Helm chart deployment.

No value exists in /etc/docker-gitlab/runtime/env-defaults. So, I'm guessing it either never gets set or it is being set and the value held elsewhere. If so how do I determine the present value?

Digging around you can generate the encrypted_settings_key_base like so as per source installation guidance (https://docs.gitlab.com/ee/administration/encrypted_configuration.html#encrypted-configuration)

root@gitlab-0:/home/git/gitlab# bundle exec rake gitlab:env:info RAILS_ENV=production GITLAB_GENERATE_ENCRYPTED_SETTINGS_KEY_BASE=true
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:29: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:30: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
Missing Rails.application.secrets.encrypted_settings_key_base for production environment. The secret will be generated and stored in config/secrets.yml.

but it doesn't get written into the config/secrets.yml located in /etc/docker-gitlab/runtime/config/gitlabhq/secrets.yml which your code emplaces as

production:
  # db_key_base is used to encrypt for Variables. Ensure that you don't lose it.
  # If you change or lose this key you will be unable to access variables stored in database.
  # Make sure the secret is at least 30 characters and all random,
  # no regular words or you'll be exposed to dictionary attacks.
  db_key_base: {{GITLAB_SECRETS_DB_KEY_BASE}}
  secret_key_base: {{GITLAB_SECRETS_SECRET_KEY_BASE}}
  otp_key_base: {{GITLAB_SECRETS_OTP_KEY_BASE}}

development:
  db_key_base: development

test:
  db_key_base: test

[kkimurak]

Current config/ files are little bit older. Some secrets also missing as reported in #2356 ..
I'm trying to sync them to upstream but it takes a time to keep compatibility with customized parameters. If you need it soon, I recommend you to

1. add such parameters to config/secrets.yml,
2. set default value in assets/runtime/env-default
3. add the parameters you have added to update_template ${GITLAB_SECTETS_CONFIG} in assets/runtime/functions
4. build the image
5. set your secrets to your setting file e.g. docker-compose.yml and run your self-built image.

[nemonik]

Thank you for your reply.

It appears at the moment a restore of a backup works on omnibus without this particular value set.

If this turns out not to be the case I am thankful to have your response to work with.

[Samysayu25]

Y