Cloud Connector: 아키텍처

GitLab Cloud Connector는 여러 GitLab 배포, 인스턴스 및 셀에서 공통으로 액세스하는 방법입니다. 현재 Cloud Connector는 전용 서비스 자체가 아니라 클라우드 기반 서비스를 GitLab 인스턴스와 통합할 때 인증 및 기타 항목의 접근을 표준화하는 API 및 코드 컬렉션입니다.

이 페이지는 Cloud Connector의 일반 아키텍처를 다루며 본 개발자 문서의 보조 자료로 사용됩니다.

용어

Cloud Connector의 컴포넌트와 메커니즘을 다룰 때, 다음 용어를 사용합니다:

  • GitLab Rails: 주요 GitLab 응용 프로그램
  • GitLab.com: GitLab Inc.이 운영하는 멀티 테넌트 GitLab SaaS 배포
  • 전용: GitLab Inc.이 운영하는 단일 테넌트 GitLab SaaS 배포
  • Self-managed: 고객이 운영하는 모든 GitLab 인스턴스, 잠재적으로 프라이빗 클라우드에 배포될 수 있음
  • GitLab 인스턴스: 위에서 언급된 것 중의 하나
  • 백엔드 서비스: GitLab 인스턴스가 호출하여 Cloud Connector 기능 중 하나인 기능을 제공하는 GitLab이 운영하는 웹 서비스. AI 게이트웨이가 한 가지 예입니다.
  • CustomersDot: 고객이 GitLab 구독을 관리하는 데 사용하는 GitLab 고객 포털
  • 서비스 토큰: GitLab 인스턴스와 백엔드 서비스 간의 요청을 인가하는 암호화된 토큰
  • 서비스 토큰 발급자: 서비스 토큰 및/또는 해당 토큰을 검증하기 위한 공개 키를 제공하는 엔드포인트를 제공하는 GitLab이 운영하는 웹 서비스입니다. GitLab.com 및 CustomersDot이 서비스 토큰 발급자입니다.
  • 서비스 토큰 검증기: 서비스 토큰 발급자로부터 얻은 공개 키를 사용하여 서비스 토큰을 검증하는 백엔드 서비스입니다. AI Gateway가 이에 해당합니다.
  • OIDC: OpenID Connect, 식별 공급자 및 인증 및 권한 부여를 구현하기 위한 오픈 표준
  • JWT: JSON Web Token, 식별 데이터를 인코드하고 전송하기 위한 오픈 표준
  • JWKS: JSON Web Key Set, JWT의 유효성을 검증하기 위한 암호화 키를 인코드하는 오픈 표준

해결할 문제

대부분의 GitLab 기능은 배포 위치에 관계없이 GitLab 인스턴스에서 직접 제공될 수 있습니다. 그러나 일부 기능은 제 3자 공급업체 통합이 필요하거나 GitLab.com 외부에서 운영하는 것이 어려운 경우가 있습니다. 이는 Self-managed 및 전용 고객이 해당 기능에 쉽게 액세스할 수 없는 문제를 제기합니다.

Cloud Connector는 다음과 같은 방식으로 이 문제를 해결합니다:

  • GitLab Rails에서 기능을 분리하여 GitLab이 운영하는 서비스로 옮겨 매뉴얼으로 구성하고 운영하는 수고를 덜어줍니다.
  • 클라우드.gitlab.com에서 Cloud Connector 기능에 대한 단일 전역 진입 지점을 제공하여 백엔드 서비스에 액세스합니다.
  • 인스턴스 라이선스 및 청구 데이터를 연결하여 권한을 부여하여 GitLab 인스턴스가 GitLab Inc.이 운영하는 백엔드 서비스에 호스팅된 기능을 사용할 수 있도록 합니다.

Cloud Connector 컴포넌트

기술적으로 Cloud Connector는 다음과 같은 컴포넌트로 구성됩니다:

  1. 글로벌 로드 밸런서. Cloudflare에서 ‘클라우드.gitlab.com’에 호스트되며, AI와 같은 Cloud Connector 기능으로의 모든 트래픽은 이 호스트를 통해 전달되어야 합니다. 로드 밸런서는 경로 접두어를 기준으로 경로 결정을 수행합니다. 예를 들어:
    1. 로드 밸런서는 ‘/접두어’를 백엔드 서비스에 매핑합니다.
    2. 클라이언트가 ‘클라우드.gitlab.com/접두어/경로’를 요청합니다.
    3. 로드 밸런서는 ‘/접두어’를 제거하고 ‘/경로’를 백엔드 서비스로 라우팅합니다.
  2. GitLab.com 및 CustomersDot을 서비스 토큰 발급자로 선출. 이러한 배포는 GitLab Inc.만 액세스 권한이 있는 개인 키로 구성됩니다. 이러한 키를 사용하여 GitLab Rails 인스턴스가 연결된 서비스 백엔드로 상향하는 요청에 사용할 수 있는 암호화된 서비스 토큰을 발급합니다. OIDC 디스커버리 API 엔드포인트를 사용하여 공개 인증 키를 게시합니다.
  3. 백엔드 서비스를 서비스 토큰 검증기로 선출. 백엔드 서비스는 정기적으로 GitLab.com 또는 CustomersDot과 동기화하여 요청에 첨부된 서비스 토큰의 서명을 검증하는 데 사용되는 공개 키를 얻습니다. 그런 다음 백엔드 서비스는 서명 유효성 및 토큰이 본문에 포함될 수있는 클레임에 따라 요청을 수락하거나 거부할 수 있습니다.
  4. 상기와 통합하기 위한 API 프로그래밍. 우리는 Ruby에서 GitLab Rails 애플리케이션과 백엔드 서비스 간의 통신을 구현하는 데 필요한 인터페이스를 제공하기를 원합니다. 이는 변화하는 대상이며, 우리는 Cloud Connector 추상화 에픽에 이슈를 제기하여 이를 개선합니다.

다음 다이어그램은 이러한 컴포넌트가 상호작용하는 방식을 보여줍니다:

액세스 제어

백엔드 서비스로 요청을 보낼 때 액세스 제어에는 두 가지 수준이 있습니다:

  1. 인스턴스 액세스. 특정 SM/전용 인스턴스에 대한 액세스 권한은 고객의 클라우드 라이선스 청구 상태에 바인딩된 서비스 토큰을 발행하여 수행됩니다. 이 토큰은 CustomersDot에서 GitLab 인스턴스로 매일 동기화되어 인스턴스의 로컬 데이터베이스에 저장됩니다. GitLab.com의 경우 우리는 이러한 단계를 요구하지 않습니다. 대신 각 요청에 대해 수명이 짧은 토큰을 발급합니다. 이러한 토큰은 JWT로 구현되며, 발급자에 의해 암호화되어 서명됩니다.
  2. 사용자 액세스. 현재 모든 최종 사용자 요청이 해당 GitLab 인스턴스를 통과하도록 기대합니다. 따라서 사용자 레벨의 인증 및 권한 부여는 일반 REST 또는 GraphQL API 요청과 동일하게 처리됩니다. 즉, OAuth 또는 개인 액세스 토큰을 사용합니다.

인스턴스 액세스용으로 발급된 JWT에는 다음과 같은 클레임이 포함되어 있습니다(완전하지 않으며, 변경될 수 있음):

  • aud: 대상. 이것은 백엔드 서비스의 이름입니다(예: gitlab-ai-gateway).
  • iss: 발급자 URL. https://gitlab.com 또는 https://customers.gitlab.com 중 하나입니다.
  • exp: 토큰의 만료 시간 (UNIX 타임스탬프). GitLab.com의 경우 현재 1시간, SM/전용의 경우 3일.
  • scopes: 이 토큰이 유효한 기능을 정의하는 액세스 스코프 디렉터리. GitLab 티어 및 애드온에 유료 기능이 어떻게 번들링되는지를 기반으로 우리는 이를 얻습니다.

JSON Web Key Set (JWKS)에는 토큰 검증기가 토큰의 서명을 검증하는 데 사용하는 공개 키가 포함되어 있습니다. 모든 백엔드 서비스는 현재 다음을 수행해야 합니다:

  • GitLab.com 및 CustomersDot에서 JWKS를 정기적으로 새로 고치므로 키 회전이 서비스 중단 없이 쉽게 정기적으로 발생할 수 있도록 합니다.
  • 모든 요청에 대해 JWT의 서명 검증 및 액세스 스코프를 수행합니다.

다음의 플로우 차트는 사용자가 AI 챗봇과 같은 Cloud Connector 기능을 소비할 때, GitLab.com 및 전용/Self-managed 배포용으로 어떤 일이 발생하는지 이해하는 데 도움이 될 것입니다.

GitLab.com

GitLab.com 배포는 특별한 신뢰를 즐기기 때문에 클라우드 커넥터 기능에 대한 모든 요청에 대해 자체 서명 및 서비스 토큰을 생성할 수 있는 장점이 있어서 흐름을 크게 단순화시킵니다.

백엔드 서비스GitLab.com사용자백엔드 서비스GitLab.com사용자최종 사용자 흐름GitLab 인스턴스로 승인1PAT 또는 Cookie2클라우드 커넥터 기능 사용3Cookie 또는 PAT으로 인증/인가 수행4사용 허용 여부 확인5서명된 서비스 토큰 생성6서비스 토큰으로 기능 요청7필요한 경우 공개 서명 키 검색8JSON Web Key Set (JWKS)9키로 서비스 토큰 유효성 검사10기능 데이터11

GitLab Dedicated/Self-managed

전용 및 Self-managed 인스턴스의 주요 문제는 신뢰 위임입니다. 우리는 개별 Self-managed 인스턴스를 신뢰할 수 없으며 그들이 토큰을 발급할 수는 없지만, GitLab Inc.에서 관리하는 CustomersDot을 통해 스스로를 정기적으로 인가하도록 허용함으로써 신뢰를 위임할 수 있습니다. GitLab Dedicated 인스턴스를 제어하지만 클라우드 커넥터 측면에서는 간단히 “Self-managed”으로 간주합니다.

GitLab.com과의 주요 차이점은 고객 인스턴스가 정기적으로 동기화하여 GitLab 백엔드 서비스에 액세스하는 데 필요한 데이터를 가져오고 유지하는 CustomersDot 액터의 추가입니다.

백엔드 서비스CustomersDotSM/Dedicated GitLab사용자백엔드 서비스CustomersDotSM/Dedicated GitLab사용자배경: 액세스 데이터 동기화loop[cron job]최종 사용자 흐름라이선스 키 전송1라이선스 키로 고객 구독 확인2JWT 서비스 토큰 생성 및 서명3클라우드 커넥터 액세스 데이터 + 서비스 토큰4DB에 액세스 데이터 + 서비스 토큰 저장5GitLab 인스턴스로 승인6PAT 또는 Cookie7클라우드 커넥터 기능 사용8Cookie 또는 PAT으로 인증/인가 수행9사용 허용 여부 확인10DB에서 서비스 토큰 로드11서비스 토큰으로 기능 요청12필요한 경우 공개 서명 키 검색13JSON Web Key Set (JWKS)14키로 서비스 토큰 유효성 검사15기능 데이터16

클라우드 커넥터 액세스 데이터는 인스턴스의 로컬 데이터베이스에 저장된 구조화된 JSON 데이터입니다. 서비스 토큰에 추가로, 이는 서비스가 완전히 출시되었는지 또는 베타 단계에 있는지와 같은 추가 정보를 포함하여 사용 가능한 서비스에 대한 정보가 특히 유용합니다. 우리가 제어하지 않는 Self-managed 인스턴스의 업그레이드 주기 때문에 이 정보는 변경될 수 있는 데이터를 동기화하고 원격으로 일부 GitLab 기능에 대한 액세스를 제어할 수 있게 합니다.

References