This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed devops secure -

GitLab Secret Detection ADR 001: 몽올리스 내에서 Ruby Push Check 접근 방식 사용

맥락

대규모에서 정규 표현식 기반 시크릿 감지의 성능에 대한 여러 우려 사항이 있습니다. 주요 고려 사항은 노드 간 전송 지연과 CPU 및 메모리 과다 사용이 포함됩니다. 이러한 우려 사항은 두 가지 방식으로 나타났습니다. 정규 표현식 일치에 사용할 언어와 배포 아키텍처입니다.

탐사 이슈에서 원래 토론이 많은 이러한 우려 사항과 배경을 다룹니다.

구현 언어

두 가지 주요 언어로 고려된 것은 Ruby와 Go입니다.

구현에 다른 언어(C++과 같은)를 사용하는 선택은 팀의 익숙함, 배포 속도 및 이식성 때문에 Ruby와 Go를 선호해서 폐기되었습니다. 두 언어 간의 성능 비교에 대해 알아보려면 이 벤치마킹 이슈를 참조하세요.

배포 아키텍처

배포를 위해 여러 옵션이 고려되었습니다: Rails 몽올리스의 Push Check 실행 경로 내에서 로직을 직접 포함시키기, Rails 노드 배포 내의 사이드카로 위치시키기, Gitaly 노드 내의 사이드카로 위치시키거나 서버 측 후크로 배치하거나 독립적인 서비스로 배포하기.

결정

초기 반복 주변에서 Prereceive 통합을 사용하여 푸시 이벤트를 차단하기 위해 re2를 활용한 고성능의 정규 표현식 처리를 위해 Ruby 기반의 접근 방식을 사용하고, 로직을 몽올리스에 직접 통합하는 결정이 내려졌습니다.

Gitaly 서버 측 후크는 Gitaly 블롭 저장소와 스캔 서비스 간의 최소 전송 지연에 대한 성능 이점을 가졌을 것입니다. 그러나 Gitaly와 Rails 애플리케이션 간에 스캔 내용을 맥락화하기 위해 추가 요청이 필요했을 것입니다. 또한, 현재 후크 아키텍처는 비권장되며 곧 새로운 플러그인 아키텍처로 이관할 계획이 있습니다.

Ruby Push Check 접근 방식은 예상된 일정에 따라 전달을 달성할 수 있는 명확한 실행 계획을 따르며, 플랫폼 전반의 스캔의 장기적인 방향과 더 밀접하게 일치합니다. 예를 들어, 향후 이슈 관련 스캔은 Gitaly 컨텍스트가 아닌 Rails 애플리케이션의 신뢰 경계 내에서 실행이 필요합니다. 그러나 이러한 접근 방법은 Rails 애플리케이션 내의 증가된 메모리 사용에 대한 우려 사항을 제기했습니다. 이 방향은 또한 타임라인이 정해지면 미래에 Gitaly의 새로운 플러그인 아키텍처로 이관해야 할 수도 있습니다.

독립적인 서비스는 미래에 고려될 수 있지만, 프리-프로덕션 프로파일링 중에 수집된 데이터에 의해 보다 잘 판단될 수 있는 기술적 접근에 대한 고려가 필요합니다.