속도 제한
Offering: GitLab Self-Managed, GitLab Dedicated
GitLab.com의 경우 GitLab.com별 속도 제한을 참조하세요. GitLab Dedicated의 경우 인증된 사용자 속도 제한을 참조하세요. 속도 제한은 웹 애플리케이션의 보안과 내구성을 향상시키기 위해 사용되는 일반적인 기술입니다.
속도 제한은 웹 애플리케이션의 보안과 내구성을 향상시키기 위해 사용되는 일반적인 기술입니다.
예를 들어 간단한 스크립트는 초당 수천 개의 웹 요청을 만들 수 있습니다. 요청은:
- 악의적일 수 있습니다.
- 무관심할 수 있습니다.
- 단순히 버그일 수 있습니다.
애플리케이션과 인프라는 부하를 감당하지 못할 수 있습니다. 자세한 내용은 서비스 거부 공격을 참조하세요. 대부분의 경우 단일 IP 주소에서 요청 속도를 제한하여 완화할 수 있습니다.
대부분의 무차별 대입 공격도 속도 제한으로 유사하게 완화됩니다.
API 요청에 대한 속도 제한은 프론트엔드에서 만든 요청에 영향을 주지 않습니다. 이러한 요청은 항상 웹 트래픽으로 계산되기 때문입니다.
구성 가능한 제한#
인스턴스의 관리 영역에서 이러한 속도 제한을 설정할 수 있습니다:
- 가져오기/내보내기 속도 제한
- 이슈 속도 제한
- 노트 속도 제한
- 보호된 경로
- 원시 엔드포인트 속도 제한
- 사용자 및 IP 속도 제한
- 패키지 레지스트리 속도 제한
- Git LFS 속도 제한
- Git SSH 작업 속도 제한
- 파일 API 속도 제한
- 더 이상 사용되지 않는 API 속도 제한
- GitLab Pages 속도 제한
- 파이프라인 속도 제한
- 인시던트 관리 속도 제한
- 프로젝트 API 속도 제한
- 그룹 API 속도 제한
- 사용자 API 속도 제한
- 조직 API 속도 제한
ApplicationSettings API를 사용하여 이러한 속도 제한을 설정할 수 있습니다:
Rails 콘솔을 사용하여 이러한 속도 제한을 설정할 수 있습니다:
Git 및 컨테이너 레지스트리의 인증 실패 차단#
단일 IP 주소에서 3분 동안 30개의 인증 실패 요청을 받으면 GitLab은 1시간 동안 HTTP 상태 코드 403을 반환합니다. 이는 다음의 조합에만 적용됩니다:
- Git 요청
- 컨테이너 레지스트리(
/jwt/auth) 요청
이 제한:
- 성공적으로 인증하는 요청으로 초기화됩니다. 예를 들어, 29번의 인증 실패 요청 다음에 1번의 성공적인 요청, 그 다음 29번의 인증 실패 요청은 차단을 트리거하지 않습니다.
gitlab-ci-token으로 인증된 JWT 요청에는 적용되지 않습니다.- 기본적으로 비활성화됩니다.
응답 헤더는 제공되지 않습니다.
속도 제한을 피하기 위해 다음을 수행할 수 있습니다:
- 자동화된 파이프라인 실행을 분산하세요.
- 인증 실패 시도에 대해 지수 백오프 및 재시도를 구성하세요.
- 토큰 만료를 관리하기 위해 문서화된 프로세스와 모범 사례를 사용하세요.
구성 정보는 Linux 패키지 구성 옵션을 참조하세요.
구성 불가능한 제한#
리포지토리 아카이브#
리포지토리 아카이브 다운로드에 대한 속도 제한이 있습니다. 제한은 프로젝트와 UI 또는 API를 통해 다운로드를 시작하는 사용자에게 적용됩니다.
속도 제한은 사용자당 분당 5개의 요청입니다.
웹훅 테스트#
웹훅 테스트에 대한 속도 제한이 있으며, 이는 웹훅 기능의 악용을 방지합니다.
속도 제한은 사용자당 분당 5개의 요청입니다.
사용자 가입#
/users/sign_up 엔드포인트에 IP 주소당 속도 제한이 있습니다. 이는 엔드포인트의 오용 시도를 완화하기 위한 것입니다. 예를 들어 사용 중인 사용자 이름이나 이메일 주소를 대량으로 발견하려는 시도.
속도 제한은 IP 주소당 분당 20번의 호출입니다.
사용자 이름 업데이트#
사용자 이름을 변경할 수 있는 빈도에 대한 속도 제한이 있습니다. 이는 기능의 오용을 완화하기 위해 적용됩니다. 예를 들어 사용 중인 사용자 이름을 대량으로 발견하려는 시도.
속도 제한은 인증된 사용자당 분당 10번의 호출입니다.
사용자 이름 존재 여부#
가입 시 선택한 사용자 이름이 이미 사용 중인지 확인하는 데 사용되는 내부 엔드포인트 /users/:username/exists에 대한 속도 제한이 있습니다.
이는 사용 중인 사용자 이름을 대량으로 발견하는 것과 같은 오용 위험을 완화하기 위한 것입니다.
속도 제한은 IP 주소당 분당 20번의 호출입니다.
프로젝트 작업 API 엔드포인트#
히스토리
작업을 검색할 때 시간 초과를 줄이기 위해 적용되는 project/:id/jobs 엔드포인트에 대한 속도 제한이 있습니다.
속도 제한은 기본적으로 인증된 사용자당 600번의 호출입니다. 속도 제한을 구성할 수 있습니다.
AI 작업#
히스토리
- GitLab 16.0에서 도입되었습니다.
이 엔드포인트의 악용을 방지하기 위해 적용되는 GraphQL aiAction 뮤테이션에 대한 속도 제한이 있습니다.
속도 제한은 인증된 사용자당 8시간당 160번의 호출입니다.
API를 사용하여 구성원 삭제#
히스토리
- GitLab 16.0에서 도입되었습니다.
/groups/:id/members 또는 /project/:id/members API 엔드포인트를 사용하여 프로젝트 또는 그룹 구성원을 제거하는 데 대한 속도 제한이 있습니다.
속도 제한은 분당 60번의 삭제입니다.
API를 사용하여 프로젝트 구성원 나열#
히스토리
- GitLab 18.6에서 도입되었습니다.
그룹 또는 프로젝트의 모든 프로젝트 구성원을 나열하는 데 대한 속도 제한을 설정합니다. 다음 엔드포인트에서 기본값은 분당 200개의 요청입니다:
GET /groups/:id/members/all
GET /projects/:id/members/all
관리자는 프로젝트 엔드포인트의 속도 제한을 구성할 수 있습니다.
리포지토리 블롭 및 파일 액세스#
히스토리
- GitLab 18.1에서 도입되었습니다.
특정 리포지토리 API 엔드포인트를 통해 대용량 파일에 액세스할 때 속도 제한이 적용됩니다. 10MB보다 큰 파일의 경우 속도 제한은 다음에 대해 프로젝트당 객체당 분당 5번의 호출입니다:
- 리포지토리 블롭 엔드포인트:
/projects/:id/repository/blobs/:sha - 리포지토리 파일 엔드포인트:
/projects/:id/repository/files/:file_path
이러한 제한은 API를 통해 대용량 리포지토리 파일에 액세스할 때 과도한 리소스 사용을 방지하는 데 도움이 됩니다.
알림 이메일#
히스토리
프로젝트 또는 그룹과 관련된 알림 이메일에 대한 속도 제한이 있습니다.
속도 제한은 사용자당 프로젝트 또는 그룹당 24시간당 1,000개의 알림입니다.
GitHub 가져오기#
GitHub에서 프로젝트 가져오기를 트리거하는 데 대한 속도 제한이 있습니다.
속도 제한은 사용자당 분당 6개의 트리거된 가져오기입니다.
FogBugz 가져오기#
히스토리
- GitLab 17.6에서 도입되었습니다.
FogBugz에서 프로젝트 가져오기를 트리거하는 데 대한 속도 제한이 있습니다.
속도 제한은 사용자당 분당 1개의 트리거된 가져오기입니다.
커밋 diff 파일#
이 엔드포인트의 악용을 방지하기 위해 적용되는 확장된 커밋 diff 파일(/[group]/[project]/-/commit/[:sha]/diff_files?expanded=1)에 대한 속도 제한이 있습니다.
속도 제한은 사용자당(인증된 경우) 또는 IP 주소당(미인증 경우) 분당 6개의 요청입니다.
변경 로그 생성#
엔드포인트 오용 시도를 완화하기 위해 :id/repository/changelog 엔드포인트에 사용자당 프로젝트당 속도 제한이 있습니다.
속도 제한은 GET과 POST 작업 간에 공유됩니다.
속도 제한은 사용자당 프로젝트당 분당 5번의 호출입니다.
문제 해결#
Rack Attack이 로드 밸런서를 차단 목록에 추가함#
모든 트래픽이 로드 밸런서에서 오는 것처럼 보이면 Rack Attack이 로드 밸런서를 차단할 수 있습니다. 이 경우 다음을 수행해야 합니다:
-
nginx[real_ip_trusted_addresses]를 구성하세요. 이렇게 하면 사용자의 IP가 로드 밸런서 IP로 나열되지 않습니다. -
로드 밸런서의 IP 주소를 허용 목록에 추가하세요.
-
GitLab을 재구성하세요:
sudo gitlab-ctl reconfigure
Redis를 사용하여 Rack Attack에서 차단된 IP 제거#
차단된 IP를 제거하려면:
-
프로덕션 로그에서 차단된 IP를 찾으세요:
grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log -
차단 목록은 Redis에 저장되므로
redis-cli를 열어야 합니다:/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket -
다음 구문을 사용하여 차단을 제거하고
<ip>를 차단 목록에 있는 실제 IP로 교체하세요:del cache:gitlab:rack::attack:allow2ban:ban:<ip> -
IP가 있는 키가 더 이상 표시되지 않는지 확인하세요:
keys *rack::attack*기본적으로
keys명령은 비활성화됩니다. -
선택적으로 IP를 허용 목록에 추가하여 다시 차단 목록에 추가되는 것을 방지하세요.
