Separation between regular configuration and passwords

As we start being used more in Enterprise environments we'll get more requests to separate passwords from regular configuration.

I also expect to hear some backlash about having passwords in plain text in configuration files. Obviously, this is not only the problem of the Rails application, but all components we use as part of GitLab as a whole.

gitlab.rb is a configuration file but it is also a Ruby file.

I want to start a discussion about this, maybe we have some low hanging fruit we can handle.

/cc @gitlab-build-team @stanhu @rymai

Thanks for creating the issue. @briann, what is the desired way of setting credentials for companies that have these security requirements?

A good first step would be moving any secrets or passwords out of gitlab.rb and at least into the secrets file.

The Rails developers are working on this issue here and I like their ideas: https://github.com/rails/rails/issues/25095

Another good step forwards might be using: https://github.com/ahoward/sekrets

I like the idea of keeping our current secrets in secrets.yml and then providing an optional secrets.yml.enc that could either be encrypted with a shared key in the Rails root or using a GPG keypair so that any developer or admin could modify it but not read it.

The Rails developers are working on this issue here and I like their ideas: https://github.com/rails/rails/issues/25095

FYI this is available in Rails 5.1.

In ElectricFlow/ElectricCommander, such stuff is encrypted and decrypted using passkey file. Administrator could put cleartext password in the configuration files but it will be encrypted when it's read by the server. We may consider similar solution although ElectricFlow/ElectricCommander is built from Java.

Reference links below.

• [passkey file] (http://docs.electric-cloud.com/commander_doc/5_x/HTML5/Install/CommanderInstallHTML.htm#Install%20Guide/maintenance/2backups/dBacking%20Up%20a%20Commander%20Server.htm%3FTocPath%3DMaintenance%7CCommander%20Server%20Backups%7C_____3)
• [Credential object] (http://docs.electric-cloud.com/commander_doc/5_4/HTML5/Help/CommanderHelpHTML.htm#credenuserimperson.htm?Highlight=credential)

added SP3 customer labels

https://gitlab.zendesk.com/agent/tickets/73342

added feature label

@marin support would like to prioritize this for next release as part of our scheduling request :)

removed discussion label

@cpallares : This is user management, so should go to @mydigitalself / @DouweM . Thanks!

Thanks @victorwu. @mydigitalself, @DouweM can we get this prioritized? This is a support scheduling request.

@victorwu we are not only talking about user management here. This issue is aimed to cover different way of handling passwords not only for user accounts but for external and internal services and integrations. I think this is not only a Platform team task.

/cc @joshlambert

Thanks @marin . This is more about the omnibus configuration? So yes, @joshlambert sounds right for Build. Thanks!

Chatted with @cpallares, the support request is to offer secure storage for all necessary integrations as well, such as LDAP and the database.

Moving from a bunch of passwords in gitlab.rb to a single password somewhere (file, environment var) is good but probably still not sufficient from a customer standpoint. @briann how common is using an asymmetric key to protect the KEK? Seems like an easy solution to me, and something you can easily fix if one gets lost by just replacing the public key and associated encrypted files.

We should also consider that whatever work we do here, also moves us towards a friendlier cloud native approach.

@joshlambert I don't think it's common, mainly due to the complications of managing the keys.

Also see https://gitlab.com/gitlab-org/gitlab-ee/issues/2317#note_28773812.

Chatted with @briann on this. Would like to make a proposal:

• Rails related keys get protected by the new Rails 5.1 sekrets based protection. These would be anything GitLab Rails needs to consume. By doing this, we can prevent these keys from sitting on disk in an unencrypted format.
• Keys for other products (Mattermost, Redis, etc.) are out of scope for now, as they anyway will most likely have to be written out to another location which is unencrypted. We can tackle these on a case by case basis in the future, if they offer an encrypted storage solution.

Does this sound reasonable?

Do we have the break of secrets, between Rails related items and third party apps?

changed milestone to %9.4

Does this sound reasonable?

Sounds reasonable.

Do we have the break of secrets, between Rails related items and third party apps?

In the gitlab.rb configuration file, no. They do get written out to separate configuration files on the disk though.

added federal label

@joshlambert @marin apologies, i put this into 9.4 without checking with you guys. if you need something done in CE, @marin are you able to create an issue and reference this one please. Happy to take scheduling on your lead.

@mydigitalself 9.4 is fine for now, we can review once we get there but it's definitely a candidate. Thanks.

This requires us to move to Rails 5.1 first, which is being tracked in gitlab-ce#14286.

changed milestone to %Backlog

Note - we should also consider gitlab-secrets.json as well for encryption, since I believe that holds MFA secrets?

Is this still slated for 9.4?

@mollybeth This is currently blocked by https://gitlab.com/gitlab-org/gitlab-ce/issues/14286 . Once that issue is resolved we can move on scheduling this.

Is there an adjusted expected delivery or milestone for this issue?

@tmoy the upgrade to Rails 5 is currently planned for 9.5, so this would be planned to get into 9.6.

added blocked label