Skip to content

[Meta] Security/permissions of CD

This is a meta issue to discuss the current state of security for continuous deployments done through GitLab CI. Security of CI was pretty much covered, but as we extend CI to include CD with environments, manual actions, etc. we need to make sure that our basic security model works and see where we need to improve, and where we can offer enhanced control for EE. There have been a bunch of issues created lately, and I find it hard to evaluate them in isolation.

Note: This issue is about internal security within a company, not about external hackers, although clearly they're related. Limiting access limits exposure to compromised accounts, for example.

Some examples:

  • Secret variables can be inadvertently disclosed, via a screencast or looking over the shoulder. (gitlab-foss#21358 (closed))
  • Any developer can trigger a manual action. So while the master branch could be protected from pushes, any developer could trigger the deploy job in a pipeline. (gitlab-foss#20261 (closed))
  • Any developer can run a pipeline manually. So while the master branch could be protected from pushes, any developer could trigger the deploy job in a pipeline. (gitlab-foss#30634 (closed))
  • All project variables are accessible by any developer. If one developer adds secure variables to a project with deployment capable creds, any developer could write a trivial CI script to use or output those variables. (gitlab-foss#24196 (closed) or gitlab-foss#17739 (moved))
  • Even if you restrict deploy actions to the master branch, a developer could overwrite that restriction in a branch's .gitlab-ci.yml to force a deploy of unvetted code. (gitlab-foss#24196 (closed), gitlab-foss#17739 (moved), gitlab-foss#24194 (closed), and/or gitlab-foss#20826 (moved))
  • Even if you restrict secrets to a dedicated, tagged runner, a developer could overwrite tags in a branch's .gitlab-ci.yml to run arbitrary code on the dedicated runner. (#33281)
  • Any developer can rollback. (gitlab-foss#20261 (closed) and gitlab-foss#30634 (closed))
  • Even if you properly restrict variables to masters, if something print out a secret variable to the build log, it will be visible by developers (and possibly public). (gitlab-foss#13784 (moved))
  • Artifacts can be downloaded even if they're created on protected branches, there could be an option (EE only) to create "protected" artifacts that can be downloaded only by Master. (gitlab-foss#14925 (moved))

Questions/Assumptions:

  • Should all developers be treated the same? We don't have a role for operations or devops. For CE, I believe this is sufficient. But for EE, perhaps we need a new role or at least a bunch of checkboxes which specify what developers are capable of.

Priorities as of 4/7/17

  1. Respect protected branches for manual actions: https://gitlab.com/gitlab-org/gitlab-ce/issues/20261
  2. Protect variables: https://gitlab.com/gitlab-org/gitlab-ce/issues/24196
  3. Protect runners: https://gitlab.com/gitlab-org/gitlab-ce/issues/33281
  4. Block pipelines on protected branches: https://gitlab.com/gitlab-org/gitlab-ce/issues/30634
  5. Environment-specific variables: https://gitlab.com/gitlab-org/gitlab-ee/issues/2302
  6. Protected environments: https://gitlab.com/gitlab-org/gitlab-ee/issues/2747

Issues

Edited by username-removed-1243277