Preventing Crypto Mining abuse on GitLab.com SaaS

@whaber, Hello!

In our project we have two members that are verified and one that is not. We also don’t have personal runners, so we only use shared ones. How do I configure my pipeline not to be triggered by non-verified user?

Currently workflow:rules section looks like that:

workflow:
  rules:
    - if: $GITLAB_USER_ID == "xxxxxxxx"
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "dev"

But this fail due to trigger user not being verified seems to happen earlier than pipeline follows workflow:rules (this is only a guess).

What would you recommend?

Hey @anton2920,

You are correct that user verification occurs before the evaluation of workflow:rules.

How do I configure my pipeline not to be triggered by non-verified user?

The user verification takes care of this without any additional pipeline configuration. Please let us know if thats not what you’re experiencing, or if theres something else that you’re trying to achieve that you’d like us to help you with.

@jayswain, thanks for the quick confirmation.

I mean, yeah, pipeline won’t finish if user is not verified, that’s correct. But it’s still started. After that it instantly fails. We have a Slack notifications set up if pipeline fails. Also Jira shows that build failed. Also it’s displayed as failed pipeline on GitLab itself. It’s kind of annoying.

The think I’m trying to achieve is to prevent pipeline from even trying to start if it caused by a non-verified user, so we still can have notification settings we have right now, and it’s not flooded with fail messages.

Ah, I see the frustration @anton2920.

Would Push options be a solution that works for your team?

@jayswain, thanks! I’ve tested it and here are the results.

If you create new branch and merge request like that:

git branch new_branch
git checkout new_branch
git push origin new_branch -o merge_request.create -o ci.skip

two pipelines will be created, one for branch will be skipped and one for MR will fail (ouch). Same results if you just push the branch with -o ci.skip and create MR using GitLab website, which makes sense. All that seems to be in sync with documentation.

If you push to existing branch and MR, two pipelines will be created (for push to branch and push to MR) and both of them will be skipped. Which seems good to our team but otherwise a bug, as documentation states:

Only skips branch pipelines and not merge request pipelines.

Probably I don’t understand what exactly should be skipped, so it’s up to you to draw conclusions

Still, I’ll consider this method as a workaround, as every branch created from Jira, every MR that is created with whatever method and every accidental push that forgets this option will result in a pipeline failure and a lot of notification noise after that

Also, pipelines although skipped are still created and CI/CD log with all pipelines is now getting a bit messy with these. So the amount of work needed to clean this up remains the same.

yep this is a big problem but we have a solution i have a idea we could resrit crypto mining or something like that

My agency has access to several Premium namespaces on GitLab and numerous free projects/groups.

When we bring in a new developer who is creating a new account, even though they are occupying a paid seat in other groups, they still run into this error on the free groups if they haven’t validated with a CC.

Sometimes we can simply tell the person working for us that they just have to do it. But in other cases we are working to get buy in from a client on using GitLab, and may have resistence from their internal staff. Teaching someone how to set up a Hugo site on GitLab pages causes friction when they are asked to provide a CC.

Is there anyway to verify a user across projects/groups if they occupy paid seats elsewhere or is it too messy to put that burden of trust on another agency?

@jayswain, any updates?

Hey @anton2920,

Apologies this fell off my radar.

I’ve asked internally for an expert to weigh in, but while that conversation resolves, would avoiding duplicate pipelines help you get to a solution?

@jayswain, two things.

First, in my initial comment I’ve posted our workflow:rules section, so I don’t know what else to apply to that from your link.

Second, it seems that it’s no longer a problem for us (as now all our members have a proper account), but it might be an issue in the future and it’s still an issue for other teams.

I’m willing to provide any additional information, even create a new account to test things, so this should be properly fixed.

I have just landed with this user to help a friend with GitLab Pages. I’m just a single person trying to help other people publishing a relatively small website.

I totally agree that GitLab should prevent crypto mining abuse, but please don’t throw the baby out with the bathwater.

I’m afraid that this kind of measure hurts the less tech-oriented people (or the rest of us).

Shared runners might be enabled by default with GitLab Pages for free users, given two conditions:

1. They are only used for GitLab Pages.
2. When forked from GitLab Pages examples · GitLab, .gitlab-ci.yml should be unmodified (SHA512 is only a way to check this).

If crytpo minining cannot be introduced without modifying these .gitlab-ci.yml files (as mentioned by @francoismartin), enabling shared runners with the conditions above may be a win-win situation:

1. Legitimate users may have their GitLab Pages no matter when they registered.
2. Crypto mining abuse may not enabled in this case.

@whaber, I wonder whether this consideration could be sent again to the people at GitLab Pages to examine whether such a measure is feasible.

Many thanks for your help.

I thought my previous proposal might make sense to allow free user to GitLab Pages.

Could somebody from GitLab check whether this measure (or a similar one) might be allowed?

At least, a reply discarding this possibility would help to know that GitLab Pages are not for new free users.

Many thanks for your help.