How is `encrypted_settings_key_base` handled?

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

Start with /etc/docker-gitlab/runtime/env-defaults and the generated /etc/docker-gitlab/runtime/config/gitlabhq/secrets.yml, then trace how environment variables are templated into the container configuration. Compare that behavior with the linked GitLab encrypted-configuration and Helm documentation. Done means documenting where encrypted_settings_key_base comes from, how to determine its current value, and what must be preserved for migration.