Preventing Crypto Mining abuse on GitLab.com SaaS

Recently, there has been a massive uptick in abuse of free pipeline minutes available on GitLab.com and on other CI/CD providers to mine cryptocurrencies. In addition to the cost increases, the abuse creates intermittent performance issues for GitLab.com users and requires our teams to work 24x7 to maintain optimal services for our customers and users. To discourage and reduce abuse, starting May 17th, 2021, GitLab will require new free users to provide a valid credit card in order to use shared runners on GitLab.com. However, a user will be able to run pipelines without providing a credit card if they use their own runner and disable shared runners. Although imperfect, we believe this will reduce the abuse.

We plan to rollout this change gradually and increase the scope if needed in the following manner. We plan to start with adding the new requirement for new free users created on or after May 17th, 2021. If we continue to see abuse through existing free accounts, we plan to extend the requirement to additional users.

This change does not currently impact any of the following users:

  • GitLab self-managed customers and users (free or otherwise)
  • Paid or program users (e.g. education, open source) on GitLab.com
  • Users created before May 17, 2021

When you provide the card, it will not be charged but instead will be verified with a one-dollar authorization transaction. No charge will be made and no money will transfer.

A credit card is one (of many) controls we have put in place to reduce abuse of our platform. We will never fully solve platform abuse, but the more barriers we put up, the more difficult and expensive it becomes to engage in abuse.

The GitLab team members have already activated and shipped many improvements. These were helpful in deterring abuse, although are not sufficient. A sampling of the fixes we have delivered to mitigate pipeline abuse include:

  1. Fail creation of jobs when pipeline minutes quota is exceeded.
  2. Fail pipelines after user exceeds pipeline minutes quota.
  3. Adding restrictions to the creation of namespaces via the API.
  4. Enabling the termination of pipelines when blocking a user.
  5. Ensuring pipelines do not run when pipelines are owned by a blocked user.
  6. Closing gaps in jobs running by user accounts deleted by users.
  7. Utilizing and enhancing the External Pipeline Validation Service specifically around authentication, payload, and access restriction.
  8. Ensuring scheduled pipelines don't run by blocked users.

We expect to make enhancements to harden our pipeline system against abuse. We believe using pipeline minute quotas as the foundation for free minute usage will be the best mechanism for failing jobs and pipelines to stop abuse. Including this effort, our other pipeline abuse improvements are below:

  1. Include public projects in pipeline minutes quota for free users.
  2. Expand application limits for preventing abuse of webhooks.

A user impacted by this change has the following options:

  • Provide a credit card and use the four hundred free minutes with shared runners.
  • A user can also run pipelines without providing a credit card if they use their own runner and disable shared runners for their project.
  • Decline to provide the card and continue to utilize many of the GitLab capabilities for free. In this case, any feature within GitLab that relies on our pipelines won't work, such as: a pipeline (CI/CD generally), scheduled pipelines including on-demand DAST scans, defining your own pipelines, utilizing AutoDevOps.
  • Switch to GitLab Self-managed

Validating an account

Continue the conversation

Please share your questions and feedback with us on the community forum.



from GitLab https://ift.tt/3eUEz10 #GitLab #DevSecOps

Comments

Post a Comment

Popular posts from this blog

Efficient DevSecOps workflows: Hands-on python-gitlab API automation

Image
A friend once said in a conference presentation, “Manual work is a bug." When there are repetitive tasks in workflows, I tend to come back to this quote , and try to automate as much as possible. For example, by querying a REST API to do an inventory of settings, or calling API actions to create new comments in GitLab issues/merge requests. The interaction with the GitLab REST API can be done in different ways, using HTTP requests with curl (or hurl ) on the command line, or by writing a script in a programming language. The latter can become reinventing the wheel again with raw HTTP requests code, and parsing the JSON responses. Thanks to the wider GitLab community, many different languages are supported by API abstraction libraries. They provide support for all API attributes, add helper functions to get/create/delete objects, and generally aim to help developers focus. The python-gitlab library is a feature-rich and easy-to-use library written in Python. In this blog post, y...
Read more

Secure GitLab CI/CD workflows using OIDC JWT on a DevSecOps platform

Image
Securing CI/CD workflows can be challenging. This blog post walks you through the problem validation, explores the JWT token technology and how it can be used with OIDC authentication, and discusses implementation challenges with authorization realms. You will learn about the current possibilities and future plans with GitLab 16.0. Variables vs. secrets Variables are an efficient way to control and inject parameters into your jobs and pipelines, making managing and configuring the CI/CD workflows easier. You can read more about how to use CI/CD variables . An extra layer of security on top of variables to mask and protect, for now, is our “best-effort” to prevent sensitive variables from being accidentally revealed. However, variables are not a drop-in replacement for secrets. Securing secrets natively is a solution that GitLab aspires to provide. Meanwhile, we recommend storing sensitive information in a dedicated secrets management solution. As a company, we will provide you abili...
Read more

GitLab 13.11 released with Kubernetes Agent and Pipeline Compliance

Image
On this Earth Day we are thinking about growth. Our customers are scaling their DevOps practices and with growth comes the need for even greater efficiencies and automated controls. The GitLab Kubernetes Agent is now available on GitLab.com to help you benefit from fast, pull-based deployments to your cluster, while GitLab.com manages the necessary server-side components of the Agent. Compliant Pipeline Configurations let you define enforceable pipelines that will run for any project assigned a corresponding compliance framework, even custom ones . We also have a host of features to improve pipeline efficiency and measurement, to provide On-call Scheduling , and even more security enhancements. These are just a few of the 50+ significant new features and improvements in this release. Controls to help you grow safely and efficiently Controls can keep your automation on track as you grow and scale while simplifying compliance efforts. The GitLab Kubernetes Agent is core to GitLab...
Read more