| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | devops secure | - |
GitLab 시크릿 감지 ADR 001: Ruby Push Check 방식을 모놀리식 내에서 사용
배경
규모에 맞는 정규식 기반 시크릿 감지의 성능에 대한 여러 우려가 있습니다. 주요 고려 사항으로는 노드 간의 전송 지연, CPU 및 메모리 부풀림이 포함됩니다. 이러한 우려 사항은 정규식 일치를 수행할 언어 및 배포 아키텍처에 두 가지 방식으로 나타났습니다.
탐색 이슈의 초기 토의에서 이러한 우려 사항과 배경에 대해 다루었습니다.
구현 언어
고려된 두 가지 주요 언어는 Ruby와 Go였습니다.
실행 언어로 C++와 같은 다른 언어를 사용하는 선택은 팀의 익숙함, 배포 속도 및 이식성을 이유로 Ruby와 Go를 선호하여 폐기되었습니다. 두 언어 간의 성능 비교에 대해서는 이 벤치마킹 이슈를 참조하십시오.
배포 아키텍처
배포 옵션으로는 Rails 모놀리식(Push Check 실행 경로 내부에 로직을 직접 임베딩), Rails 노드 배포 내부에 사이드카로 배치, Gitaly 노드 내부에 서버 사이드 후크로 배치, 독립적인 서비스로의 배포 등이 고려되었습니다.
결정
초기 이벤트 차단을 위한 기본 이터레이션에서 성능이 뛰어난 정규식 처리를 위해 Ruby 기반 접근 방식을 사용하기로 결정했으며, re2를 활용하기로 했습니다. 뿐만 아니라, 이 결정은 모놀리식로의 로직 직접 통합을 선택했으며, 이것이 이산적인 서비스나 Gitaly 내부의 서버 측 후크로의 통합을 선택한 것보다 우선되었습니다.
Gitaly 서버측 후크는 스캐닝 서비스와 Gitaly 블롭 스토리지 간의 최소 전송 지연에 대한 성능상의 이점이 있었습니다. 그러나 Gitaly와 Rails 애플리케이션 간에 스캔을 컨텍스트화하기 위해 추가 요청이 필요했습니다. 또한 현재 후크 아키텍처는 권장되지 않으며 곧 새로운 플러그인 아키텍처로의 마이그레이션 작업이 계획되어 있습니다.
Ruby Push Check 방식은 예상된 타임라인에 따라 전달을 달성하기 위한 명확한 실행 계획을 따르며, 플랫폼 전체 스캔의 장기적인 방향과 더욱 일치합니다. 예를 들어, 향후 이슈에서의 스캔은 Gitaly 컨텍스트가 아닌 Rails 애플리케이션의 신뢰 경계 내부에서 실행이 필요합니다. 그러나 이 방식은 Rails 애플리케이션 내의 메모리 사용 증가로 인한 가용성에 대한 우려가 제기되었습니다. 이 방향은 또한 미래에 Gitaly의 새로운 플러그인 아키텍처로의 마이그레이션을 필요로 할 수 있습니다.
독립적인 서비스는 미래에 고려될 수 있지만, 프리 프로덕션 프로파일링 중에 수집된 데이터에 기반한 기술적 접근 방식 고려가 필요합니다.