내부 API

GitLab 내부 컴포넌트 간 통신에 사용되는 내부 API의 엔드포인트, 인증 방식, 사용 목적 및 소비자를 설명합니다.

내부 API는 여러 GitLab 구성 요소가 사용합니다. 다른 소비자는 사용할 수 없습니다. 이 문서는 GitLab 코드베이스를 작업하는 사람을 대상으로 합니다. 이 문서에는 GitLab Pages가 사용하는 내부 API가 아직 포함되어 있지 않습니다. GitLab Subscriptions 내부 API는 전용 페이지 를 참고합니다. Orbit 내부 API는 전용 페이지 를 참고합니다. 새 엔드포인트 추가 # API 엔드포인트는 기본적으로 적절한 인증과 인가를 갖추어 외부에서 접근할 수 있어야 합니다. 새 내부 엔드포인트를 추가하기 전에, 해당 API가 더 넓은 GitLab 커뮤니티에 도움이 되는지, 외부에서 접근할 수 있게 만들 수 있는지 검토합니다. 때로 내부 API 엔드포인트를 선호하는 이유 중 하나는 엔드포인트를 사용하는 데 외부 주체가 가질 수 없는 내부 데이터가 필요한 경우입니다. 예를 들어 내부 Pages API에서는 요청이 내부 요청임을 식별하는 시크릿 토큰을 사용하거나, 더 넓은 커뮤니티가 사용할 수 없는 공개 키로 요청에 서명할 수 있습니다. 무언가를 내부 API로 분리하는 또 다른 이유는 해당 API 엔드포인트에 대한 요청이 엣지(공개) 로드 밸런서를 절대 거치면 안 되는 경우입니다. 이렇게 하면 내부 로드 밸런서를 통해 해당 엔드포인트에는 내부 요청만 들어올 수 있음을 알 수 있으므로, 엔드포인트에 접근하는 방식에 대해 서로 다른 속도 제한 규칙과 정책을 구성할 수 있습니다. 인증 # 이 메서드는 모두 공유 시크릿을 사용해 인증합니다. 이 시크릿은 config/gitlab.yml 에 구성된 경로의 파일에 저장됩니다. 기본적으로 GitLab Rails 앱의 루트에 있으며 파일 이름은 .gitlab_shell_secret 입니다. 해당 토큰으로 인증하려면 클라이언트는 다음을 수행합니다. 해당 파일의 내용을 읽습니다. 파일 내용을 사용해 JSON Web Token( JWT )을 생성합니다. Gitlab-Shell-Api-Request 헤더에 JWT를 전달합니다. Git 인증 # Gitaly 와 GitLab Shell 이 리포지터리에 대한 접근을 확인하기 위해 호출합니다. GitLab Shell에서 호출하는 경우: 변경 사항은 전달되지 않으며, 내부 API는 요청을 Gitaly로 넘기는 데 필요한 정보로 응답합니다. Gitaly가 pre-receive 훅에서 호출하는 경우: 변경 사항이 전달되고 푸시를 허용할지 판단하기 위해 검증됩니다. 호출은 각각 50초로 제한됩니다. 이 엔드포인트는 다루는 범위가 넓어 별도 페이지 에서 더 자세히 설명합니다. POST /internal/allowed 속성 유형 필수 여부 설명 key_id string 아니요 GitLab Shell 연결에 사용한 SSH 키의 ID username string 아니요 GitLab Shell 연결에 사용한 인증서의 사용자 이름 project string 아니요 ( gl_repository 를 전달한 경우) 프로젝트 경로 gl_repository string 아