Untangle the db_key_base secret
Current situation:
- gitlab-rails/config/secrets.yml has a secret called
db_key_base
used to store several different symmetrically encrypted attributes in SQL - to set
db_key_base
you must usegitlab_ci['db_key_base']
in gitlab.rb
This is confusing and poorly documented (if at all), yet when you lose this db_key_base secret you have data loss. This happened to us on dev.gitlab.org last week (cc @marin @pcarranza @jnijhof ).
The natural thing to do would be to set your db_key_base secret via gitlab_rails['db_key_base']
but if you do that it gets IGNORED silently.
What needs to be done:
- ideally,
gitlab_rails['db_key_base']
should just work because it is what you expect. BUT: - we should not break setups where people put
gitlab_ci['db_key_base']
in (encrypted) config management (like we do ourselves on gitlab.com!) - we should have very clear instructions in the source-to-omnibus update documentation to make sure people do not lose their original
db_key_base
along the way - ... (did I miss something?)