Ensure a 2fa step happens between Commit and Deploy
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Background:
Some terminology: Endpoint, aka. desktop, laptop, cellphone. A potentially compromised machine that runs developer tools, compilers and end users execute random code on.
Execution, code running in virtual machine, sandbox or natively (in docker, javascript engine, python, natively)
Untrusted, Any un-vetted code that hasn't been through a second or third pair of eyeballs. (Code review, merge request)
The problem: Code needs to migrate from "untrusted" to "trusted" between moving from an Endpoint to a server, before execution happens.
This step needs to be strongly authenticated, which basically means that a 2fa challenge has to be made for this step.
Things considered (and discarded):
-
Only allowing Signed tags to be deployed GPG signatures are not 2fa steps and can easily be repeated by client local software.
-
Only allow master branch to be deployed Master users can merge and force push to master without barriers, including authentication barriers
Things that cause this to be a bit more difficult:
-
Limitations in gitlab-ci.yml on which branches can be deployed or run CI tools can be changed by anyone who can push for the branch.
-
Workflows where developers push to their own repository and Merge request go to the project are quite a hassle (con) and still permit unauthenticated code to enter the master repo ( permitted someone has permission to merge the code)
Desired workflow:
- Limitations on merge requests to ensure that 2fa steps happen when merging
- Limitations on (manual) Deployments that block until a 2fa step has happened
- Limitations on automatic deployments that allow it to only run on merge commits
- Limitations on project setting changes that enforce a 2fa step to change protected branches and CI settings
What questions are you trying to answer?
How do I prevent a hijacked endpoint from being equivalent to Server side code execution.
Are you looking to verify an existing hypothesis or uncover new issues you should be exploring?
Existing hypothesis is that GitLab AutoDevops and Deployments don't have enough security controls in the workflow, and basically ensures that ability to run code on an endpoint is equivalent to cluster-wide code execution on servers.
What is the backstory of this project and how does it impact the approach?
Attempting to migrate a current Manual deploy step to use gitlab automatic deployments in a secure manner.
What do you already know about the areas you are exploring?
Gitlab has support for 2fa authentication ( at least using OTP )
Our current deployment needs involve using a hardware token to authenticate against servers.
Equivalence between the two would be nice, but requires that GitLab strictly enforces that an authentication step happens between commit and deploy.
What does success look like at the end of the project?
Ability to turn on a setting in the project that limits deployments to only happen after a 2fa step happens
Links / references:
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.