GitLab flow and secret environment variables

I am a little puzzled by the proposed GitLab workflow (https://docs.gitlab.com/ee/workflow/gitlab_flow.html) and how it is supposed to work together with secret environment variables (https://docs.gitlab.com/ce/ci/variables/#secret-variables).

I'm a long time GitHub / Travis-CI user and manage a couple of open source projects this way. It's very typical for open source projects, with few "core developers" and many drive-by-contributors to use the git triangular workflow, i.e. you pull the upstream master, branch into your feature branch, do some changes, commit and push to a branch on your git repo. From there you open a MR / PR. That means that when CI is run on your feature branch it doesn't have access to the secret environment variables, since it's running from your private repo and not the upstream version. This is good, since drive-by-contributors shouldn't be entrusted with secrets to the project.

GitLab EE is built for a different kind of environment where you typically have more "core contributors" (actual developers hired for developing something) and fewer drive-by-contributors (because it's usually private / internal projects). However, it's not uncommon to have hired developers from external companies, like consultancy firms etc. GitLab permissions only allow masters of a project to view and modify secret environment variables. This is great, since it means I don't have to entrust all developers (some of which are kind of external) with all my secrets. They have "developer" permissions while I have "master". Super!

In GitLab workflow however it seems that it is encouraged that developers create branches in the "upstream" repository and not in their own private fork of the project. I have historically not allowed this, through the use of protected branches, because it clutters up the upstream repo AND it allows anyone to view the secret environment variables - all they have to do is modify .gitlab-ci.yml to echo $SECRET_ENVIRONMENT_VARIABLE. That is obviously very bad and means my secrets are not very secret at all.

GitLab flow doesn't actually explicitly state that triangular workflow is discouraged and that branches on upstream should be used but I infer that this is the recommendation based on that the "New branch" button from issues tries to create a branch on the "upstream" repo, where all the issues are and there doesn't seem to be a way to change this. I should also point how neat I think this is - having that "new branch" button allows someone to develop things completely through the GitLab UI while retaining proper git workflow with branches / MRs - it considerably lowers the barrier for non-git experts / developers to modify things in our git repository - AWESOME! :D however, shouldn't it open the branch in a private fork of the repo?

If nothing else, being a little bit more explicit about this in the documented flow probably doesn't hurt.