Default compliance framework does not applied to a new project when Admin mode is enabled
Summary
When the default compliance framework is set up on the group, that framework should automatically apply to projects that newly created under the group or its subgroups.
However, if the Admin mode is enabled in the instance, the default compliance framework is not automatically apply to projects.
Steps to reproduce
- Set up the default compliance framework to a project
- Enable the Admin mode
- Create a project under the group that set up the default compliance framewortk
Example Project
This issue only happens in the self-managed instance since the Admin mode is off in the gitlab.com.
Please see the "Relevant logs and/or screenshots" section for example.
What is the current bug behavior?
The default compliance framework is not applied to the projects that created under the group that has the default compliance framework.
What is the expected correct behavior?
The default compliance framework is to the projects that created under the group that has the default compliance framework.
Relevant logs and/or screenshots
screenshot 2023-09-29 11.31.32.mov
- 0:00 - 0:10 : Shows the group has the default compliance framework
- 0:10 - 0:26: Shows the new project (test16) has compliance framework (expected behavior)
- 0:26 - 0:37 : Admin mode enabled
- 0:37- 0:59: Shows the new project (test17) does not have compliance framework (issue)
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
\[ec2-user@ip-172-31-30-219 \~\]$ sudo gitlab-rake gitlab:env:infoSystem information System: Proxy: no Current User: git Using RVM: no Ruby Version: 3.0.6p216 Gem Version: 3.4.19 Bundler Version:2.4.19 Rake Version: 13.0.6 Redis Version: 7.0.13 Sidekiq Version:6.5.7 Go Version: unknownGitLab information Version: 16.4.1-ee Revision: 229bc5f5985 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 13.11 URL: https://gitlab.kosk1011.tokyo HTTP Clone URL: https://gitlab.kosk1011.tokyo/some-group/some-project.git SSH Clone URL: git@gitlab.kosk1011.tokyo:some-group/some-project.git Elasticsearch: no Geo: yes Geo node: Primary Using LDAP: yes Using Omniauth: yes Omniauth Providers:GitLab Shell Version: 14.28.0 Repository storages: \- default: unix:/var/opt/gitlab/gitaly/gitaly.socket GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shellGitaly \- default Address: unix:/var/opt/gitlab/gitaly/gitaly.socket \- default Version: 16.4.1 \- default Git Version: 2.42.0 \[ec2-user@ip-172-31-30-219 \~\]$
Results of GitLab application Check
Expand for output related to the GitLab application check
\[ec2-user@ip-172-31-30-219 \~\]$ sudo gitlab-rake gitlab:check SANITIZE=true Checking GitLab subtasks ...Checking GitLab Shell ...GitLab Shell: ... GitLab Shell version \>= 14.28.0 ? ... OK (14.28.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successfulChecking GitLab Shell ... FinishedChecking Gitaly ...Gitaly: ... default ... OKChecking Gitaly ... FinishedChecking Sidekiq ...Sidekiq: ... Running? ... yes Number of Sidekiq processes (cluster/worker) ... 1/1Checking Sidekiq ... FinishedChecking Incoming Email ...Incoming Email: ... Reply by email is disabled in config/gitlab.ymlChecking Incoming Email ... FinishedChecking LDAP ...LDAP: ... Server: ldapmain LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 4 users of 100 limit.Checking LDAP ... FinishedChecking GitLab App ...Database config exists? ... yes Tables are truncated? ... skipped All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Cable config exists? ... yes Resque config exists? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units) Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units) Projects have namespace: ... 2/1 ... yes 4/2 ... yes 12/3 ... yes 15/4 ... yes 12/5 ... yes 15/6 ... yes 22/7 ... yes 21/8 ... yes 25/9 ... yes 25/10 ... yes 4/11 ... yes 29/12 ... yes 4/13 ... yes 4/14 ... yes 4/15 ... yes 51/19 ... yes 56/20 ... yes 59/21 ... yes 61/22 ... yes 51/23 ... yes 51/24 ... yes 51/25 ... yes 51/27 ... yes 71/28 ... yes 75/29 ... yes 73/30 ... yes 73/31 ... yes 73/32 ... yes 51/33 ... yes 4/34 ... yes 4/35 ... yes 74/36 ... yes 4/37 ... yes 86/38 ... yes 51/39 ... yes 51/40 ... yes 74/41 ... yes 51/42 ... yes 74/43 ... yes 51/44 ... yes 74/45 ... yes 74/46 ... yes 4/47 ... yes 4/48 ... yes 85/49 ... yes 86/50 ... yes 86/51 ... yes 85/52 ... yes 86/53 ... yes 86/54 ... yes 85/55 ... yes 86/56 ... yes 85/57 ... yes 85/58 ... yes 116/59 ... yes 116/60 ... yes 86/61 ... yes 51/62 ... yes 51/63 ... yes 116/64 ... yes 116/65 ... yes 116/66 ... yes 118/67 ... yes 118/68 ... yes 116/69 ... yes 116/70 ... yes 116/71 ... yes 116/72 ... yes 116/73 ... yes 116/74 ... yes 116/75 ... yes 116/76 ... yes 116/77 ... yes 116/78 ... yes 116/79 ... yes 116/80 ... yes 116/81 ... yes Redis version \>= 6.0.0? ... yes Ruby version \>= 3.0.6 ? ... yes (3.0.6) Git user has default SSH configuration? ... yes Active users: ... 12 Is authorized keys file accessible? ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled) All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled)Checking GitLab App ... FinishedChecking Geo ...GitLab Geo is available ... GitLab Geo is enabled ... yes This machine's Geo node name matches a database record ... yes, found a primary node named "primary" HTTP/HTTPS repository cloning is enabled ... yes Machine clock is synchronized ... yes Git user has default SSH configuration? ... yes OpenSSH configured to use AuthorizedKeysCommand ... skipped Reason: Cannot access OpenSSH configuration file Try fixing it: This is expected if you are using SELinux. You may want to check configuration manually For more information see: doc/administration/operations/fast_ssh_key_lookup.md GitLab configured to disable writing to authorized_keys file ... no Try fixing it: You need to disable \`Write to authorized_keys file\` in GitLab's Admin panel For more information see: doc/administration/operations/fast_ssh_key_lookup.md GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yesChecking Geo ... FinishedChecking GitLab subtasks ... Finished\[ec2-user@ip-172-31-30-219 \~\]$
Possible fixes
From another issue(GitLab internal)
# frozen_string_literal: true
module ComplianceManagement
class UpdateDefaultFrameworkWorker
include ApplicationWorker
idempotent!
data_consistency :always
urgency :low
feature_category :compliance_management
def perform(_user_id, project_id, compliance_framework_id)
admin_bot = ::Users::Internal.admin_bot
project = Project.find(project_id)
Gitlab::Auth::CurrentUserMode.bypass_session!(admin_bot.id) do
::Projects::UpdateService.new(
project, admin_bot,
compliance_framework_setting_attributes: { framework: compliance_framework_id }
).execute
end
rescue ActiveRecord::RecordNotFound => e
Gitlab::ErrorTracking.log_exception(e)
end
end
end