<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=250744) </details> <!--IssueSummary end--> <!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve As mentioned in https://gitlab.com/gitlab-org/gitlab/-/issues/213159, protecting job logs only when `CI_DEBUG_TRACE` is set to `true` will most likely be insufficient. Although the CI_DEBUG_TRACE flag has proven to be problematic if not used with caution, it's not the only way to leak secrets. The more abstract problem seems to be that we let Maintainers make mistakes. For example, handling the CI_DEBUG_TRACE as described in https://gitlab.com/gitlab-org/gitlab/-/issues/213159 case would not help in cases where credential leakage occurs by other means, for example by using echo or env to display environment variables via a pre-checkout hook. Allowing Maintainers to modify artifacts whose output ultimately lands in a job's log, which is a normal thing for Maintainers to do, forces us to deal with all infinite ways in which sensitive variables could possibly be leaked: CI_DEBUG_TRACE, echo, env and more. This is, I argue, impractical. <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> ### Intended users * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> Help prevent unintended credential leakage. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Instead of approaching this problem in a case-by-case basis we should improve GitLab's CI/CD variable masking capabilities, I argue this is actually fixing it, so that there are no restrictions w/r/t format, length or content. How to best do this is to be defined, but it is clear, that there are plenty scenarios where CI/CD variables should without doubt be masked even if they are too complex in format (service accounts, usually in JSON format). Regardless how we choose to improve variable masking, current restrictions on variable masking seem unreasonable, as many masking-worthy variables fall precisely within the formats that cannot be masked according to our documentation:  https://docs.gitlab.com/ee/ci/variables/#masked-variable-requirements Alternatively, we could implement access controls when accessing job logs, as described in https://gitlab.com/gitlab-org/gitlab/-/issues/250745, so that only maintainers and above can access them by default. This would help Maintainers avoid making mistakes that could lead to credential leakage. If we sufficiently improve variable masking, no amount of echo, env, etc will circumvent variable masking, as even complex variables that are unprotected due to their complexity and length today will be masked. #### Additional comments we need to ensure that this operation is memory and time safe on the Runner side, and that it does not obfuscate a build log if masking parameters are not defined in a sane way. Multiple strategies can be taken here, but the most simple one is presumably relaxing a limit without removing it completely. ### Links / references <!-- Label reminders - you should have one of each of the following labels if you can figure out the correct ones -->