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.

Can someone tell me why I can’t just create an account like with any other website (without using my card’s info)? The problem is only with “limited free stuff” (pipeline minutes or whatever), right? If so, why I can’t just create an account, create a repository, create an issue/PR, send messages and that’s it? There is no way this can be also abused. Just move this verification process/wall to when it’s absolutely needed, not at the time of the registration.

Additionally, not all cards are accepted, so even if I really wanted to give all my info and money, the error message wouldn’t let me do it!

Hi @Andrew15-5. I am a Product Manager for GitLab. Wanted to answer some questions for you regarding our verification system. First to clarify, Along with abuse of our pipeline systems we have seen an increase in users creating thousands of issues, MRs, etc in public issues in an attempt to disrupt development. Hence our system tries to prevent abuse of all features. We do this by asking a few identifying questions at signup. Now a few clarifying questions for you to determine how best to proceed:

1. How many accounts have you created? In general users only ever have to go through verification once, so it shouldn’t be too disruptive.
2. What country are you in?
3. What type of credit card are you using and what country is the credit card from?
4. Have you ever been banned from GitLab before?

I am sorry you are running into trouble registering for an account! It is important for us to protect the integrity and availability of our platform and we try to do that in the least disruptive way possible.

Thanks for the quick reply. This is so sad to see people abusing even the most essential things (and for what?). Now I’m wondering why GitHub doesn’t have the same issues (with account/issue/MR abuse).

And now for the quiz:

1. 0 (well 1, but it will be deleted again in a few days, so it will be 0 again).
2. Russia.
3. Debit card issued in Russia.
   I also tried (just to check what will happen) a card that has a random US bank’s BIN (1st 6 digits) and the rest is just random digits (since they are unique for each bank’s client and any sequence should be valid). In all cases, I either had an “Invalid card type” or an “Invalid card number”. So I can’t use my real number nor theoretical US bank’s number (strange).
4. I hope I haven’t. The thing is, I don’t remember if I ever had a GitLab account. I think I did, but I don’t have a saved password and I never really used GitLab. So 99% I never even had an account.

P.S. I’m glad that I don’t need a GitLab account to sign up here (this forum).

@jstava, it’s been more than a month and I still don’t know how best to proceed. Do I need to wait more?

I want to leave a note that I was able to register this time around. No credit card information was asked. 2 captchas: Cloudflare and “domestic”. Also, some questions about how and for which purpose I want to use GitLab account. Before I knew it, I’ve already successfully registered.

3. don’t card numbers have a validation checksum of sort? I don’t know about the american market, but on EU, in all cases I’ve worked with so far they all had checksums. So the app can know if a number is even valid, without ever checking with a central service. Eg. before the transation can even initiate.
   TLDR; as far as I know, not all number combinations are valid.

Why would a new user being asked for credit card information?
You can disable the CI/CD by default for new user, when user wants to use it they will input credit card information.
It’s very poor user experience. Very poor.