Skip to content

fix: leaking secrets in gitlab.rb with diff

Steve Xuereb requested to merge fix/gitlab-rb-sensitive into master

chore: update gitlab_secrets to latest release

What

Update gitlab_secrets to 1.0.0

Why

CI is failing https://gitlab.com/gitlab-cookbooks/cookbook-omnibus-gitlab/-/jobs/3775594676 because it fails to get gitlab_secrets with the ~> 0.0.6 constrain and we've released a 1.0.0 for this gitlab_secrets!18 (merged)

It seems like most servers already have gitlab_secrets 1.0.0 installed as well.

steve@file-01-stor-gstg.c.gitlab-staging-1.internal:~$ sudo chef-client
...
  - gitlab_secrets (1.0.0)

steve@thanos-compact-01-inf-gprd.c.gitlab-production.internal:~$ sudo chef-client
...
  - gitlab_secrets (1.0.0)

fix: leaking secrets in gitlab.rb with diff

What

Mark the /etc/gitlab/gitlab.rb as sensitive

Why

When there is a change in gitlab.rb we show a diff in chef logs like below. This is not ideal because gitlab.rb has a lot of sensitive information such as database passwords and certificates and having the diff show in the logs can end up leaking secrets and we don't save this inside of ElasticSearch either.

  * template[/etc/gitlab/gitlab.rb] action create
    - update content in file /etc/gitlab/gitlab.rb from 68354b to d7c2ca
    --- /etc/gitlab/gitlab.rb   2023-02-15 12:48:04.423750025 +0000
    +++ /etc/gitlab/.chef-gitlab20230215-1153037-66610w.rb      2023-02-15 12:49:06.929231798 +0000
    @@ -96,7 +96,7 @@
     gitaly['concurrency'] = [{"rpc"=>"/gitaly.SmartHTTPService/InfoRefsUploadPack", "max_per_repo"=>120, "max_queue_size"=>10, "max_queue_time"=>"10s"}, {"rpc"=>"/gitaly.SmartHTTPService/PostUploadPack", "max_per_repo"=>120}, {"rpc"=>"/gitaly.SmartHTTPService/PostUploadPackWithSidechannel", "max_per_repo"=>120, "max_queue_size"=>200, "max_queue_time"=>"10s"}, {"rpc"=>"/gitaly.SSHService/SSHUploadPack", "max_per_repo"=>120}, {"rpc"=>"/gitaly.SSHService/SSHUploadPackWithSidechannel", "max_per_repo"=>120, "max_queue_size"=>200, "max_queue_time"=>"10s"}, {"rpc"=>"/gitaly.RepositoryService/GetArchive", "max_per_repo"=>10, "max_queue_size"=>10, "max_queue_time"=>"10s"}, {"rpc"=>"/gitaly.RepositoryService/FetchRemote", "max_per_repo"=>5}, {"rpc"=>"/gitaly.CommitService/CommitsByMessage", "max_per_repo"=>5, "max_queue_wait"=>"10s"}, {"rpc"=>"/gitaly.CommitService/CountCommits", "max_per_repo"=>5, "max_queue_size"=>10, "max_queue_wait"=>"10s"}, {"rpc"=>"/gitaly.OperationService/UserCreateBranch", "max_per_repo"=>10, "max_queue_size"=>10}]
     gitaly['daily_maintenance_start_hour'] = 22
     gitaly['daily_maintenance_start_minute'] = 30
    -gitaly['daily_maintenance_duration'] = "5h"
    +gitaly['daily_maintenance_duration'] = "4h"
     gitaly['daily_maintenance_storages'] = ["default"]
     gitaly['env'] = {"GITLAB_CONTINUOUS_PROFILING"=>"stackdriver?service=gitaly", "GITLAB_TRACING"=>"opentracing://stackdriver?sampler_probability=0.05"}
     gitaly['pack_objects_cache_enabled'] = true

Reference: https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/17171

Edited by Steve Xuereb

Merge request reports