No, GitLab does not allow marking variables as secrets. They allow "masking" env variables, subject to a bunch of caveats, like your secrets not being multiple lines (e.g. a private key cannot be masked). Even then, the masking is just about log output -- it doesn't prevent a `env | curl` type situation. [0]
The correct mitigation is to ensure that any "secret" variables are marked as "protected" so they can only run on protected branches that are limited to pushes by maintainers. And you'll still need to make sure the masking works in the logs.
They do support integrating with Vault to access secrets in a CI job, but you need to pay them to use that feature. [1]
For GitLab if you don't have at least developer access to the repository (as in you are sending a MR from a fork) that will run in the context of your user, so you don't have access to any secrets configured upstream, etc.
If you have access to a repository you can customize the script to do whatever you want, but there will always be a trace tracking it back to you.
There is a discussion about ultimate security (access only when asked) Vs the convenience of self-service.
You can still avoid that by having people use a fork model, or triggering CD from an external project with tight access.
Putting a burocratic process between ICs will only limit their throughput as in Jenkins paradigm.
The better advice is don't hire people you can't trust
Add one extra command ;-) These can be innocuous if buried in something like unit tests of configs or network behavior, or in a big pr:
logs: `env | base64`
network: `env | gzip | curl`
It should be easy to set most workflows to run sandboxed with almost no capabilities - no secrets access, safelisted network access, safelisted package manager accesses for top 10 langs, etc - so that testing someone's PR isn't scary, and runtime violations make loud noises. The whole 'just disable actions on fork PRs' thing is a great default, but ultimately a figleaf as it's not hard to get someone to run an action.
