- 인증되지 않은 API 요청 속도 제한 활성화
- 인증되지 않은 웹 요청 속도 제한 활성화
- 인증된 API 요청 속도 제한 활성화
- 인증된 웹 요청 속도 제한 활성화
- 사용자 정의 속도 제한 응답 사용
project/:id/jobs
당 최대 인증된 요청 수를 분당- 응답 헤더
- HTTP 헤더를 사용하여 요율 제한 우회하기
- 특정 사용자에게 인증된 요청 요율 제한 우회 허용
- 요율 제한을 강제하기 전에 설정을 시험해보세요
사용자 및 IP 속도 제한
속도 제한은 웹 애플리케이션의 보안과 내구성을 향상시키는 데 사용되는 일반적인 기술입니다. 자세한 내용은 속도 제한을 참조하십시오.
다음과 같은 제한 사항은 기본적으로 비활성화되어 있습니다:
인증되지 않은 API 요청 속도 제한 활성화
인증되지 않은 요청 속도 제한을 활성화하려면:
- 왼쪽 사이드 바에서 아래쪽에서 관리 영역(Admin Area)을 선택합니다.
- 설정 > 네트워크(Network)을 선택합니다.
- 사용자 및 IP 속도 제한(User and IP rate limits)을 확장합니다.
-
인증되지 않은 API 요청 속도 제한 활성화(Enable unauthenticated API request rate limit)를 선택합니다.
- 선택 사항. IP 주소 당 속도 제한 기간당 최대 인증되지 않은 API 요청 횟수(Maximum unauthenticated API requests per rate limit period per IP)을 업데이트합니다. 기본값은
3600
입니다. - 선택 사항. 인증되지 않은 속도 제한 기간(Unauthenticated rate limit period in seconds) 값을 업데이트합니다. 기본값은
3600
입니다.
- 선택 사항. IP 주소 당 속도 제한 기간당 최대 인증되지 않은 API 요청 횟수(Maximum unauthenticated API requests per rate limit period per IP)을 업데이트합니다. 기본값은
인증되지 않은 웹 요청 속도 제한 활성화
인증되지 않은 요청 속도 제한을 활성화하려면:
- 왼쪽 사이드 바에서 아래쪽에서 관리 영역(Admin Area)을 선택합니다.
- 설정 > 네트워크(Network)을 선택합니다.
- 사용자 및 IP 속도 제한(User and IP rate limits)을 확장합니다.
-
인증되지 않은 웹 요청 속도 제한 활성화(Enable unauthenticated web request rate limit)을 선택합니다.
- 선택 사항. IP 주소 당 속도 제한 기간당 최대 인증되지 않은 웹 요청 횟수(Maximum unauthenticated web requests per rate limit period per IP)을 업데이트합니다. 기본값은
3600
입니다. - 선택 사항. 인증되지 않은 속도 제한 기간(Unauthenticated rate limit period in seconds) 값을 업데이트합니다. 기본값은
3600
입니다.
- 선택 사항. IP 주소 당 속도 제한 기간당 최대 인증되지 않은 웹 요청 횟수(Maximum unauthenticated web requests per rate limit period per IP)을 업데이트합니다. 기본값은
인증된 API 요청 속도 제한 활성화
인증된 API 요청 속도 제한을 활성화하려면:
- 왼쪽 사이드 바에서 아래쪽에서 관리 영역(Admin Area)을 선택합니다.
- 설정 > 네트워크(Network)을 선택합니다.
- 사용자 및 IP 속도 제한(User and IP rate limits)을 확장합니다.
-
인증된 API 요청 속도 제한 활성화(Enable authenticated API request rate limit)을 선택합니다.
- 선택 사항. 사용자 당 속도 제한 기간당 최대 인증된 API 요청 횟수(Maximum authenticated API requests per rate limit period per user)을 업데이트합니다. 기본값은
7200
입니다. - 선택 사항. 인증된 API 속도 제한 기간(Authenticated API rate limit period in seconds) 값을 업데이트합니다. 기본값은
3600
입니다.
- 선택 사항. 사용자 당 속도 제한 기간당 최대 인증된 API 요청 횟수(Maximum authenticated API requests per rate limit period per user)을 업데이트합니다. 기본값은
인증된 웹 요청 속도 제한 활성화
인증된 웹 요청 속도 제한을 활성화하려면:
- 왼쪽 사이드 바에서 아래쪽에서 관리 영역(Admin Area)을 선택합니다.
- 설정 > 네트워크(Network)을 선택합니다.
- 사용자 및 IP 속도 제한(User and IP rate limits)을 확장합니다.
-
인증된 웹 요청 속도 제한 활성화(Enable authenticated web request rate limit)을 선택합니다.
- 선택 사항. 사용자 당 속도 제한 기간당 최대 인증된 웹 요청 횟수(Maximum authenticated web requests per rate limit period per user)을 업데이트합니다. 기본값은
7200
입니다. - 선택 사항. 인증된 웹 속도 제한 기간(Authenticated web rate limit period in seconds) 값을 업데이트합니다. 기본값은
3600
입니다.
- 선택 사항. 사용자 당 속도 제한 기간당 최대 인증된 웹 요청 횟수(Maximum authenticated web requests per rate limit period per user)을 업데이트합니다. 기본값은
사용자 정의 속도 제한 응답 사용
- GitLab 13.8에서 도입됨.
속도 제한을 초과하는 요청은 기본적으로 429
응답 코드와 일반 텍스트 본문이 반환됩니다. 기본값은 나중에 다시 시도해주세요
입니다.
사용자 정의 응답을 사용하려면:
- 왼쪽 사이드 바에서 아래쪽에서 관리 영역(Admin Area)을 선택합니다.
- 설정 > 네트워크(Network)을 선택합니다.
- 사용자 및 IP 속도 제한(User and IP rate limits)을 확장합니다.
- 요청 제한에 걸린 클라이언트에게 전송할 일반 텍스트 응답(Plain-text response to send to clients that hit a rate limit) 텍스트 상자에 일반 텍스트 응답 메시지를 추가합니다.
project/:id/jobs
당 최대 인증된 요청 수를 분당
- GitLab 16.5에서 도입됨.
Time out을 줄이기 위해 project/:id/jobs
엔드포인트에는 인증된 사용자 당 기본 속도 제한이 한 분당 600개의 호출로 설정되어 있습니다.
최대 요청 수를 수정하려면:
- 왼쪽 사이드 바에서 아래쪽에서 관리 영역(Admin Area)을 선택합니다.
- 설정 > 네트워크(Network)을 선택합니다.
- 사용자 및 IP 속도 제한(User and IP rate limits)을 확장합니다.
-
project/:id/jobs
당 최대 인증된 요청 수(Most authenticated requests toproject/:id/jobs
per minute) 값을 업데이트합니다.
응답 헤더
- GitLab 13.8에서 도입된
RateLimit
헤더입니다. 이전 버전에서는Retry-After
가 도입되었습니다.
클라이언트가 연관된 속도 제한을 초과하면 해당 요청이 차단됩니다. 서버는 요청자가 특정 시간 이후에 다시 시도하도록 허용하는 속도 제한 정보로 응답할 수 있습니다. 이러한 정보는 응답 헤더로 첨부됩니다.
헤더(Header) | 예시(Example) | 설명(Description) |
---|---|---|
RateLimit-Limit
| 60
| 클라이언트의 매 분당 요청 할당량. 관리 영역에서 속도 제한 기간이 1분이 아닌 경우, 이 헤더의 값은 대략 60분 주기에 맞게 조정됩니다. |
RateLimit-Name
| throttle_authenticated_web
| 요청을 차단하는 스로틀의 이름. |
RateLimit-Observed
| 67
| 시간 창에 연관된 요청 수. |
RateLimit-Remaining
| 0
| 시간 창에서 남은 할당량. RateLimit-Limit - RateLimit-Observed 의 결과입니다.
|
RateLimit-Reset
| 1609844400
| 요청 할당량이 재설정되는 유닉스 시간 형식의 시간. |
RateLimit-ResetTime
| Tue, 05 Jan 2021 11:00:00 GMT
| 요청 할당량이 재설정되는 RFC2616 형식의 날짜와 시간. |
Retry-After
| 30
| 할당량이 재설정될 때까지 남은 기간 초 단위입니다. 이것은 표준 HTTP 헤더입니다. |
HTTP 헤더를 사용하여 요율 제한 우회하기
- GitLab 13.6 에서 도입되었습니다.
귀하의 조직의 필요에 따라 요율 제한을 활성화하려 하지만 일부 요청은 요율 제한을 우회해야 할 수도 있습니다.
로드 밸런서 또는 GitLab 앞 단의 리버스 프록시에서 요율 제한을 우회해야 하는 요청을 사용자 정의 헤더로 표시함으로써 이를 수행할 수 있습니다. 예를 들어:
- 우회 헤더의 이름을 선택합니다. 예:
Gitlab-Bypass-Rate-Limiting
. - GitLab 요율 제한을 우회해야 하는 요청에 대해 로드 밸런서를 구성하여
Gitlab-Bypass-Rate-Limiting: 1
로 설정합니다. - 로드 밸런서를 구성하여 다음 중 하나를 수행합니다:
-
Gitlab-Bypass-Rate-Limiting
를 지우세요. - 요율 제한의 영향을 받아야 하는 모든 요청에서
Gitlab-Bypass-Rate-Limiting
을1
이 아닌 값을 설정하세요.
-
- 환경 변수
GITLAB_THROTTLE_BYPASS_HEADER
를 설정하세요-
Linux 패키지 설치의 경우,
gitlab_rails['env']
에서'GITLAB_THROTTLE_BYPASS_HEADER' => 'Gitlab-Bypass-Rate-Limiting'
를 설정하세요. - 직접 컴파일한 설치의 경우,
/etc/default/gitlab
에서export GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limiting
을 설정하세요.
-
Linux 패키지 설치의 경우,
로드 밸런서가 모든 입력 트래픽에서 우회 헤더를 지우거나 덮어 쓰는 것이 중요합니다. 그렇지 않은 경우 사용자가 해당 헤더를 설정하고 GitLab 요율 제한을 우회할 수 있음을 신뢰해야 합니다.
우회는 헤더가 1
으로 설정된 경우에만 작동합니다.
우회 헤더로 인해 요율 제한을 우회한 요청은 production_json.log
에서 "throttle_safelist":"throttle_bypass_header"
로 표시됩니다.
우회 메커니즘을 비활성화하려면 환경 변수 GITLAB_THROTTLE_BYPASS_HEADER
가 설정되지 않았거나 비어 있는지 확인하세요.
특정 사용자에게 인증된 요청 요율 제한 우회 허용
- GitLab 13.7 에서 도입되었습니다.
위에서 설명한 우회 헤더와 유사하게, 특정 집합의 사용자가 요율 제한을 우회할 수 있도록 설정할 수 있습니다. 이는 인증된 요청에만 적용됩니다. 인증되지 않은 요청의 경우 GitLab은 사용자를 모르므로 적용되지 않습니다.
허용 디렉터리은 GITLAB_THROTTLE_USER_ALLOWLIST
환경 변수에 사용자 ID의 쉼표로 구분된 디렉터리으로 구성됩니다. 사용자 1, 53 및 217이 인증된 요청 요율 제한을 우회하도록 하려면 허용 디렉터리 구성은 1,53,217
이 될 것입니다.
-
Linux 패키지 설치의 경우,
gitlab_rails['env']
에서'GITLAB_THROTTLE_USER_ALLOWLIST' => '1,53,217'
를 설정하세요. - 직접 컴파일한 설치의 경우,
/etc/default/gitlab
에서export GITLAB_THROTTLE_USER_ALLOWLIST=1,53,217
를 설정하세요.
사용자 허용 디렉터리으로 인해 요율 제한을 우회한 요청은 production_json.log
에서 "throttle_safelist":"throttle_user_allowlist"
로 표시됩니다.
애플리케이션 시작 시, 허용 디렉터리이 auth.log
에 기록됩니다.
요율 제한을 강제하기 전에 설정을 시험해보세요
- GitLab 13.6 에서 도입되었습니다.
GITLAB_THROTTLE_DRY_RUN
환경 변수를 쉼표로 구분된 스로틀 이름 디렉터리으로 설정하여 스로틀 설정을 시험해볼 수 있습니다.
가능한 이름은 다음과 같습니다:
-
throttle_unauthenticated
-
GitLab 14.3에서 더 이상 사용되지 않음. 대신
throttle_unauthenticated_api
또는throttle_unauthenticated_web
을 사용하세요.throttle_unauthenticated
는 여전히 지원되며 둘을 모두 선택합니다.
-
GitLab 14.3에서 더 이상 사용되지 않음. 대신
throttle_unauthenticated_api
throttle_unauthenticated_web
throttle_authenticated_api
throttle_authenticated_web
throttle_unauthenticated_protected_paths
throttle_authenticated_protected_paths_api
throttle_authenticated_protected_paths_web
throttle_unauthenticated_packages_api
throttle_authenticated_packages_api
throttle_authenticated_git_lfs
throttle_unauthenticated_files_api
throttle_authenticated_files_api
throttle_unauthenticated_deprecated_api
throttle_authenticated_deprecated_api
예를 들어, 인증된 요청에 대한 모든 비보호 경로에 대한 스로틀을 모두 시험해보려면
GITLAB_THROTTLE_DRY_RUN='throttle_authenticated_web,throttle_authenticated_api'
를 설정하면 됩니다.
모든 스로틀에 대해 드라이런 모드를 활성화하려면 변수를 *
로 설정하세요.
스로틀을 드라이런 모드로 설정하면 요청이 계속되는 동안 제한에 도달할 때 auth.log
에 메시지가 기록됩니다. 로그 메시지에는 env
필드가 track
으로 설정되어 있고 matched
필드에는 제한이 발생한 이름이 포함됩니다.
환경 변수를 설정하기 전에 요율 제한을 설정하는 것이 중요합니다. 관리 영역의 설정은 즉시 적용되지만 환경 변수를 설정하려면 모든 Puma 프로세스를 재시작해야 합니다.