튜토리얼: 클라우드 커넥터를 사용하여 새로운 기능 연결하기
- 기존 백엔드 서비스를 통해 새로운 기능이 도입됨
- 새로운 기능이 새로운 백엔드 서비스를 통해 도입됩니다
  - JWT 검증 설정
    - 토큰 검증을 위한 JWKS 유지
    - JWT를 JWKS로 검증하기
  - 새로운 클라우드 커넥터 route 추가
테스트

클라우드 커넥터

GitLab 클라우드 커넥터는 다수의 GitLab 배포, 인스턴스 및 셀에서 공통적으로 사용되는 서비스에 접근하는 방법입니다. 현재 클라우드 커넥터는 자체 전용 서비스가 아니며, GitLab 인스턴스와 클라우드 기반 서비스를 통합할 때 인증 및 기타 항목에 대한 접근 방식을 표준화하는 API 및 코드 모음입니다. 이 페이지는 GitLab Rails를 서비스와 연결하기 위해 클라우드 커넥터를 사용하는 방법을 설명하는 것을 목표로 합니다.

클라우드 커넥터에 대한 자세한 정보는 아키텍처 페이지를 참조하세요. 문서 전반에 걸쳐 사용되는 용어 목록은 용어를 확인하세요. 유료 기능이 GitLab 티어와 추가 기능에 번들로 포함되는 정보는 구성을 참조하세요.

튜토리얼: 클라우드 커넥터를 사용하여 새로운 기능 연결하기

다음 섹션에서는 다음 사용 사례를 다룰 것입니다:

기존 백엔드 서비스를 통해 새로운 기능이 도입됨 - 클라우드 커넥터에 이미 연결된 서비스 (즉, AiGateway).
새로운 백엔드 서비스를 통해 새로운 기능이 도입됨 - 클라우드 커넥터에 연결할 필요가 있는 서비스.

기존 백엔드 서비스를 통해 새로운 기능이 도입됨

Ai Gateway는 현재 클라우드 커넥터와 연결된 유일한 백엔드 서비스입니다.

기존 백엔드 서비스 (Ai Gateway)에 새로운 기능을 추가하려면:

JWT 발급자에서 새로운 기능 등록.
GitLab Rails에서 권한 검사 구현.
백엔드 서비스에서 권한 확인 구현.

선택 사항: 토큰이 사용되는 백엔드 서비스에서 서비스 접근 토큰에 추가 클레임이 포함되어야 하는 경우, 현재 자가 서비스 인터페이스가 없기 때문에 #g_cloud_connector (Slack, 내부 전용)에 문의하세요.

JWT 발급자에서 새로운 기능 등록

GitLab 전용 및 자기 관리 GitLab 인스턴스의 경우, CustomersDot이 JWT 발급자입니다.
GitLab.com 배포의 경우, GitLab.com이 JWT 발급자입니다. 이는 클라우드 커넥터 기능에 대한 모든 요청에 대해 자체 서명 및 JWT 생성 할 수 있기 때문입니다.

자기 관리, 전용 및 GitLab.com 고객을 위한 새로운 기능 등록

CustomersDot이 GitLab 전용 및 자기 관리 GitLab 인스턴스의 JWT 발급자이기 때문에, 새로운 기능을 등록하려면 CustomersDot 구성을 업데이트해야 합니다.

GitLab.com이 JWT 발급자이기 때문에 자체 서명 및 JWT 생성 할 수 있으며, 새로운 기능을 등록하려면 GitLab.com 구성도 업데이트해야 합니다.

따라서 전체적으로 두 개의 별도 병합 요청을 열어야 합니다: 하나는 CustomersDot로, 또 다른 하나는 GitLab.com으로 제출합니다. 병합 시 동기화할 필요는 없습니다.

새로운 기능은 새로운 단위 원시 단위로 추가되어야 하며, 이를 JWT (서비스 접근 토큰)에 포함할 수 있습니다.

새로운 기능은 여러 방법으로 제공됩니다:

일부 기능(예: documentation_search)은 기존의 (Duo Chat) 서비스의 일부로 제공됩니다.
다른 기능은 독립형 서비스(code_suggestions)로 제공됩니다.
기존 기능(explain_vulnerability)을 기존 (Duo Chat) 서비스의 일부로 이동할 수도 있습니다.
기능을 Duo Chat 서비스의 일부로 만들고, 독립형 서비스로도 제공할 수 있습니다.

용어:

feature - documentation_search, 새로운 unit primitive로 등록되어 JWT에 포함될 수 있습니다.
existing service - Duo Chat - 기능은 Duo Chat 서비스의 일부로 제공됩니다.
stand-alone service - code_suggestions, 기능은 아마도 자체 인터페이스를 통해 접근할 수 있는 별도의 서비스입니다.
backend service - Ai Gateway, 기능이 호스팅되는 백엔드입니다.

기존 서비스에 새로운 기능 등록하기 (DuoChat)

새로운 기능은 기존 서비스(Duo Chat)의 일환으로 제공됩니다.

예를 들어, 새로운 기능은 다음과 같습니다:

이름: new_feature
기존 duo chat 서비스의 일부로 제공되며 Duo Chat 창을 통해서만 접근 가능
duo_enterprise 애드온을 통해서만 판매됨

new_feature_up unit primitive를 duo chat 서비스 아래에 등록하여 cloud_connector.yml (Self-Managed 및 Dedicated용) 및 access_data.yml (GitLab.com용)을 업데이트하세요:

defaults: &defaults
  services:
    duo_chat:
      cut_off_date: 2024-7-15 00:00:00 UTC
      min_gitlab_version: 16.8
      min_gitlab_version_for_free_access: 16.8
      bundled_with:
        duo_pro:
          unit_primitives:
            - duo_chat
            - documentation_search
        duo_enterprise:
          unit_primitives:
            - duo_chat
            - documentation_search
+           - new_feature_up

이 기능은 기존 서비스(Duo Chat)의 일환으로 제공되므로, duo_chat 서비스 아래에 new_feature_up unit primitive를 등록합니다.
이 기능은 오로지 duo_enterprise를 통해서만 판매되므로, duo_enterprise 애드온에 대해서만 bundled with 아래에 new_feature_up을 추가해야 합니다.

구성 구조에 대한 자세한 정보는 configuration를 참조하세요.

현재, 기존 서비스(Duo Chat)의 일부로 제공되는 unit primitive에 대해 cut_off_date 또는 min_gitlab_version을 설정하는 것은 지원되지 않습니다.
Issue 465221에서는 현재 구성 구조를 재편성하고, unit primitive마다 cut_off_date 지원을 추가할 것을 제안합니다.

새로운 독립 서비스 등록하기

새로운 기능은 독립 서비스로 제공됩니다.

예를 들어, 새로운 기능은 다음과 같습니다:

이름: new_feature
독립 서비스로 제공되며 Duo Chat 서비스의 일부가 아님.
duo_pro 및 duo_enterprise 애드온을 통해 판매됨.
무료로 접근할 수 없어야 함.
최소 요구 GitLab 버전은 17.1임.

new_feature를 service로 등록하여 cloud_connector.yml (Self-Managed 및 Dedicated용) 및 access_data.yml (GitLab.com용)을 업데이트하세요. configuration를 참조하세요.

defaults: &defaults
services:
+  new_feature:
+    cut_off_date: 2024-1-1 00:00:00 UTC
+    min_gitlab_version: 17.1
+    bundled_with:
+      duo_pro:
+        unit_primitives:
+          - new_feature_up
+      duo_enterprise:
+        unit_primitives:
+          - new_feature_up

이 기능은 아마도 자체 인터페이스를 통해 새 독립 서비스로 접근 가능하므로, 새로운 new_feature 서비스를 등록합니다.
이 기능은 무료로 접근할 수 없어야 하므로 cut_off_date를 과거로 설정해야 합니다.
이 기능은 duo_pro 및 duo_enterprise 두 애드온을 통해 판매되므로, 두 애드온의 bundled with 아래에 new_feature_up을 추가해야 합니다.

구성 구조에 대한 자세한 정보는 configuration를 참조하세요.

기존 서비스와 독립형 기능의 조합으로 기능 등록

새 기능은 기존 서비스(Duo Chat)를 통해 접근 가능하며, 자체 사용자 인터페이스를 통해서도 접근할 수 있습니다.

예를 들어, 새 기능은 다음과 같습니다:

new_feature로 명명됨.
기존의 duo chat 서비스의 일부로 제공되며 Duo Chat 창을 통해서만 접근 가능.
독립형 서비스로도 제공됨. 즉, 자신의 인터페이스를 통해 Duo Chat 외부에서도 사용됨.
duo_enterprise 애드온을 통해서만 판매됨.

cloud_connector.yml (Self-Managed 및 Dedicated용) 및 access_data.yml (GitLab.com용)를 업데이트하세요:

defaults: &defaults
  services:
+  new_feature:
+    bundled_with:
+      duo_enterprise:
+        unit_primitives:
+          - new_feature
    duo_chat:
      bundled_with:
        duo_pro:
          unit_primitives:
            - duo_chat
            - documentation_search
        duo_enterprise:
          unit_primitives:
            - duo_chat
            - documentation_search
+           - new_feature_up

기능은 기존 서비스(Duo Chat)의 일부로 제공되므로, duo_chat 서비스 아래에 새 new_feature_up 단위 원시 값을 등록합니다.
기능은 독립형 서비스로도 제공되므로, new_feature를 새 service로 등록해야 합니다.
기능은 오직 duo_enterprise를 통해서만 판매되므로, 두 서비스에 대해 duo_enterprise 애드온 아래에 new_feature_up을 단위 원시로 추가해야 합니다.

구성 구조에 대한 더 많은 정보는 구성을 참조하세요.

GitLab Rails에서 권한 검사 구현

새 기능이 독립형 서비스로 제공됨

접근 토큰

예를 들어, 이 기능은 new_feature라는 이름의 독립형 서비스로 제공됩니다.

CloudConnector::AvailableServices.find_by_name(:new_feature).access_token(user_or_namespace)를 호출하고 이 토큰을 Authorization HTTP 헤더 필드에 포함하세요.
- GitLab.com에서는 제공된 리소스에 따라 스코프가 달라지는 토큰을 자체 발급합니다:
  - 사용자에 대한 경우: 스코프는 사용자의 좌석 할당에 기반합니다.
  - 네임스페이스에 대한 경우: 스코프는 이 네임스페이스에 대해 구매한 애드온에 기반합니다.
    - 서비스에 무료로 접근할 수 있는 경우, 토큰에는 해당 서비스에 대해 사용 가능한 모든 스코프가 포함됩니다.
    - Duo Chat의 경우, JWT에는 documentation_search 및 duo_chat 스코프가 포함됩니다.
- Self-managed의 경우, 항상 ::CloudConnector::ServiceAccessToken JWT 토큰을 반환합니다.
  - 사용자, 네임스페이스 또는 추가 클레임과 같은 제공된 매개변수는 Self-managed 인스턴스에 대해 무시됩니다. 사용자 정의 클레임이 Self-managed 인스턴스에 대해 처리되는 방법에 대한 내용은 이 섹션을 참조하세요.
백엔드 서비스 (즉, AI Gateway)는 요청을 수신할 때 이 토큰과 관련된 모든 스코프를 검증해야 합니다.
특정 사용 사례에 필요한 추가 클레임을 토큰에 포함해야 하는 경우, extra_claims 인수에 이를 전달할 수 있습니다.
백엔드 서비스에 필요한 헤더를 보낼 수 있도록 요청을 확인하십시오.

모든 백엔드 서비스에 전송해야 하는 주요 헤더 필드:
- X-Gitlab-Instance-Id: 전세계적으로 고유한 인스턴스 ID 문자열.
- X-Gitlab-Global-User-Id: 전세계적으로 고유한 익명의 사용자 ID 문자열.
- X-Gitlab-Realm: saas 또는 self-managed 중 하나.
- X-Gitlab-Version: GitLab 인스턴스의 버전.
- X-Gitlab-Host-Name: 현재 GitLab 인스턴스의 호스트 이름.
- Authorization: 1단계에서 얻은 access_token 메서드의 Bearer 토큰으로 Base64 인코딩된 JWT를 포함.
AI-specific 헤더 필드:
- X-Gitlab-Duo-Seat-Count: 고객이 구매한 duo pro 또는 duo enterprise 좌석의 수. 두 개의 애드온이 모두 있는 경우, 가장 높은 좌석 수가 선택됩니다.
이러한 헤더 중 일부는 Gitlab::CloudConnector#headers 메서드의 결과를 페이로드에 병합하여 주입할 수 있습니다. AI 사용 사례 및 AI 게이트웨이를 대상으로 하는 요청의 경우, 대신 Gitlab::CloudConnector#ai_headers를 사용하십시오.

권한 검증

서비스가 최종 사용자에게 사용 가능한지 또는 보이는지를 결정하기 위해 다음을 수행해야 합니다:

선택 사항. Self-managed GitLab에서 새로운 기능이 새로운 엔터프라이즈 기능으로 도입된 경우, 사용자가 기능에 접근할 수 있는지 확인하려면 EE 기능 가이드라인을 따릅니다.
```
  next true if ::Gitlab::Saas.feature_available?(:new_feature_on_saas)

  ::License.feature_available?(:new_feature)
```
Self-managed GitLab에서 고객이 온라인 클라우드 라이센스를 사용하고 있는지 확인합니다.
- 클라우드 커넥터는 현재 self-managed 고객에게 온라인 클라우드 라이센스만 지원합니다.
- 평가판 또는 레거시 라이센스는 지원되지 않습니다.
- GitLab.com은 레거시 라이센스를 사용하고 있습니다.
```
  ::License.current&.online_cloud_license?
```
GitLab.com 및 self-managed GitLab에서 서비스가 무료로 접근 가능한지 확인합니다.
- 컷오프 날짜가 설정되지 않았거나 미래로 설정된 경우, 기능은 무료로 간주됩니다.
```
  # 서비스에 무료로 접근할 수 있는지 여부를 반환합니다 (추가 구매가 필요하지 않음)
  CloudConnector::AvailableServices.find_by_name(:new_feature).free_access?
```
선택 사항. 서비스가 무료로 접근 가능하다면, 이는 보통 실험적 기능이 테스트 계약의 적용을 받음을 의미합니다.
- GitLab Duo 기능의 경우, 고객은 실험적 기능을 무료로 사용하기 위해 실험 토글을 활성화해야 합니다.

GitLab.com 및 self-managed GitLab에서 서비스가 무료로 접근할 수 없는 경우, 고객이 이 서비스와 함께 번들된 애드온을 구매했는지 확인합니다 (그룹/네임스페이스 기준).

  # 서비스와 함께 번들된 애드온이 구매된 경우 true를 반환합니다.
  #
  # - 제공된 네임스페이스에 대해, 제공된 그룹/프로젝트 또는 그 조상의 애드온이 구매되었는지를 확인합니다.
  # - SM의 경우, 네임스페이스는 무시되며 self-managed 고객에 대해 네임스페이스별로 애드온이 구매되지 않습니다.
  CloudConnector::AvailableServices.find_by_name(:new_feature).purchased?(namespace)

GitLab.com 및 self-managed GitLab에서 고객의 최종 사용자가 적절한 좌석에 배정되었는지 확인합니다.

  # 서비스가 사용 가능하도록 허가된 경우 true를 반환합니다.
  #
  # 제공된 사용자에 대해, 사용자가 적절한 좌석에 배정되었는지를 확인합니다.
  current_user.allowed_to_use?(:new_feature)

예시

다음 예시는 :new_feature라는 서비스에 대한 요청입니다.

여기서 우리는 귀하의 백엔드 서비스가 foo라고 가정하며, 이미 https://cloud.gitlab.com/foo에서 접근 가능합니다.

또한 백엔드 서비스가 /new_feature_endpoint 엔드포인트를 사용하여 서비스를 노출한다고 가정합니다.

이로써 클라이언트는 https://cloud.gitlab.com/foo/new_feature_endpoint에서 서비스에 접근할 수 있습니다.

ee/global_policy.rb에 새로운 정책 규칙을 추가합니다:

  condition(:new_feature_licensed) do
    next true if ::Gitlab::Saas.feature_available?(:new_feature_on_saas)
    next false unless ::License.current.online_cloud_license?

    ::License.feature_available?(:new_feature)
  end

  condition(:user_allowed_to_use_new_feature) do
    @user.allowed_to_use?(:new_feature)
  end

  rule { new_feature_licensed & user_allowed_to_use_new_feature }.enable :access_new_feature

요청:

include API::Helpers::CloudConnector

# 주어진 사용자에 대해 좌석 배정, 애드온 구매 기준으로 서비스가 사용 가능한지 확인합니다.
return unauthorized! unless current_user.can?(:access_new_feature)

# Gitlab.com의 경우 제공된 리소스에 따라 범위 기반으로 자가 발급한 토큰입니다:
# - 제공된 사용자에 대해, 사용자 배정 권한에 기반하여 자가 발급한 토큰입니다.
# - 제공된 네임스페이스에 대해, 애드온 구매 권한에 기반하여 자가 발급한 토큰입니다.
# - 서비스가 free_access?인 경우, 사용 가능한 모든 범위를 포함하는 토큰입니다.
#
# SM의 경우, 제공된 사용자, 네임스페이스 및 추가 클레임을 무시하며 :CloudConnector::ServiceAccessToken 인스턴스 토큰을 반환합니다.
token = ::CloudConnector::AvailableServices.find_by_name(:new_feature).access_token(current_user)

Gitlab::HTTP.post(
  "https://cloud.gitlab.com/foo/new_feature_endpoint",
  headers: {
      'Authorization' => "Bearer #{token}",
    }.merge(cloud_connector_headers(current_user))
)

도입된 정책은 프런트 엔드가 보이는지를 제어하는 데 사용될 수 있습니다. new_feature_helper.rb를 추가합니다:

  def show_new_feature?
      current_user.can?(:access_new_feature)
  end

새로운 기능이 기존 서비스의 일부로 제공됩니다 (Duo Chat)

액세스 토큰

기능이 Duo Chat와 같은 기존 서비스의 일부로 제공되면,

CloudConnector::AvailableServices.find_by_name(:duo_chat).access_token(user_or_namespace)를 호출하면

모든 인가된 기능 (unit primitives)을 포함하는 IJWT가 반환됩니다.

백엔드 서비스(AI Gateway)는 토큰 범위에 JWT에 포함되지 않은 특정 기능 (unit primitive)에 대한 액세스를 방지합니다.

권한 확인

기능이 Duo Chat와 같은 기존 서비스의 일부로 제공되면 추가적인 권한 확인이 필요하지 않습니다.

기존의 글로벌 정책 규칙 user.can?(:access_duo_chat)에 의존할 수 있습니다.

최종 사용자가 최소한 하나의 기능 (unit primitive)에 액세스하면 최종 사용자는 해당 서비스에 액세스할 수 있습니다.

개별 기능 (unit primitive)에 대한 액세스는 IJWT 범위에 의해 관리되며, 백엔드 서비스(AI Gateway)에 의해 검증됩니다.

액세스 토큰을 참조하세요.

백엔드 서비스에서 권한 확인 구현

GitLab Rails는 자기 관리 및 전용 인스턴스에서 사용할 수 없는 기능을 제공하기 위해 백엔드 서비스를 호출합니다.

GitLab Rails가 이를 호출할 수 있으려면 노출된 엔드포인트가 있어야 합니다.

백엔드 서비스는 GitLab Rails에서 전송한 각 JWT를 Authorization 헤더에서 검증해야 합니다.

AI Gateway 권한 프로세스에 대한 자세한 정보와 예제는

AI Gateway 문서의 권한 부여를 참조하세요.

새로운 기능이 새로운 백엔드 서비스를 통해 도입됩니다

Cloud Connector 기능으로 이미 접근할 수 없는 새로운 백엔드 서비스를 통합하려면:

JWT 검증 설정.
cloud.gitlab.com에서 사용할 수 있도록 설정.

JWT 검증 설정

Cloud Connector를 이미 사용하는 서비스에 대해 백엔드 서비스에서 권한 확인 구현에서 언급된 바와 같이

각 서비스는 GitLab 인스턴스에서 전송한 JWT가 합법적인지 확인해야 합니다.

이를 달성하기 위해 백엔드 서비스는 다음을 수행해야 합니다:

JSON 웹 키 세트(JWKS) 유지.
이 세트의 키로 JWT 검증.

이 메커니즘에 대한 자세한 설명은

아키텍처: 액세스 제어를 참조하세요.

JWKS 및 JWT 인증을 처리하기 위해 기존 소프트웨어 라이브러리를 사용할 것을 강력히 권장합니다.

예를 들면:

토큰 검증을 위한 JWKS 유지

JWT는 처음 발행될 때 토큰 권한에 의해 암호화 서명됩니다.

그런 다음 GitLab 인스턴스는 백엔드 서비스에 요청할 때 JWT를 첨부합니다.

JWT 서비스 액세스 토큰을 검증하려면, 백엔드 서비스는 먼저 토큰을 서명하는 데 사용되는 개인 서명 키와 일치하는 공개 검증 키를 포함하는 JWKS를 얻어야 합니다.

GitLab.com과 CustomersDot 모두 토큰을 발행하므로, 백엔드 서비스는 두 곳 모두에서 JWKS를 가져와야 합니다.

JWKS를 가져오려면 GitLab.com 및 CustomersDot에서 노출된 OIDC 검색 엔드포인트를 사용하십시오.

각 토큰 권한에 대해:

GET /.well-known/openid-configuration

예시 응답:

{
  "issuer": "https://customers.gitlab.com/",
  "jwks_uri": "https://customers.gitlab.com/oauth/discovery/keys",
  "id_token_signing_alg_values_supported": [
    "RS256"
  ]
}

GET <jwks_uri>

예시 응답:

{
  "keys": [
    {
      "kty": "RSA",
      "n": "sGy_cbsSmZ_Y4XV80eK_ICmz46XkyWVf6O667-mhDcN5FcSfPW7gqhyn7s052fWrZYmJJZ4PPyh6ZzZ_gZAaQM7Oe2VrpbFdCeJW0duR51MZj52FwShLfi-NOBz2GH9XuUsRBKnXt7wwKQTabH4WW7XL23Hi0eDjc9dyQmsr2-AbH05yVsrgvEYSsWiCGEgobPgNc51DwBoIcsJ-kFN591aO_qAkbpf1j7yAuAVG7TUxaditQhyZKkourPXXyx1R-u0Lx9UJyAV8ySqFxq3XDE_pg6ZuJ7M0zS0XnGI82g3Js5zAughrQyJMhKd8j5c8UfSGxhRBQh58QNl3UwoMjQ",
      "e": "AQAB",
      "kid": "ZoObkdsnUfqW_C_EfXp9DM6LUdzl0R-eXj6Hrb2lrNU",
      "use": "sig",
      "alg": "RS256"
    }
  ]
}

응답을 캐시합니다. 캐시는 하루에 한 번 만료되도록 설정하는 것을 권장합니다.

이렇게 얻은 키는 해당 토큰 권한에서 발급된 JWT를 검증하는 데 사용될 수 있습니다.

이 방식이 작동하는 정확한 방법은 사용된 프로그래밍 언어와 라이브러리에 따라 다릅니다.

일반적인 지침은 JSON 웹 키 세트 위치 찾기에 나와 있습니다.

백엔드 서비스는 두 토큰 권한으로부터 받은 응답을 하나의 캐시된 결과 세트로 병합할 수 있습니다.

JWT를 JWKS로 검증하기

JWT를 검증하려면:

HTTP Authorization 헤더에서 토큰 문자열을 읽습니다.
JWT 라이브러리 객체와 이전에 얻은 JWKS를 사용하여 검증합니다.

토큰을 검증할 때는 다음을 확인하세요:

토큰 서명이 올바른지 확인합니다.
aud 클레임이 백엔드 서비스와 같거나 포함되어 있는지 확인합니다(이 필드는 문자열 또는 배열일 수 있습니다).
iss 클레임이 검증하는 데 사용된 키의 발급자 URL과 일치하는지 확인합니다.
scopes 클레임이 요청된 엔드포인트에서 노출된 기능을 포함하는지 확인합니다(자세한 내용은 백엔드 서비스에서 권한 검사를 구현하는 방법을 참조하세요).

새로운 클라우드 커넥터 route 추가

모든 클라우드 커넥터 기능은 경로 접두사를 기반으로 요청을 백엔드 서비스로 라우팅하는 글로벌 로드 밸런서인 cloud.gitlab.com을 통해 액세스해야 합니다. 예를 들어, AI 기능은 cloud.gitlab.com/ai/<AI-specific-path>에서 요청해야 합니다. 로드 밸런서는 이후 <AI-specific-path>를 AI 게이트웨이로 라우팅합니다.

클라우드 커넥터에 새로운 백엔드 서비스를 연결하려면 요청을 귀하의 서비스로 라우팅할 새로운 경로 접두사를 요청해야 합니다. 예를 들어, foo-service를 연결하는 경우, cloud.gitlab.com/foo를 foo-service로 라우팅하는 새로운 경로를 추가해야 합니다.

새로운 경로를 추가하려면 프로덕션 인프라 구성에 대한 액세스가 필요합니다. 새로운 경로가 필요하면 gitlab-org/gitlab 이슈 트래커에서 이슈를 열고 클라우드 커넥터 그룹에 할당하세요.

테스트

AI 게이트웨이를 백엔드 서비스로 설정하는 끝없는 통합의 예는 여기에서 찾을 수 있습니다.

클라우드 커넥터

튜토리얼: 클라우드 커넥터를 사용하여 새로운 기능 연결하기

기존 백엔드 서비스를 통해 새로운 기능이 도입됨

JWT 발급자에서 새로운 기능 등록

자기 관리, 전용 및 GitLab.com 고객을 위한 새로운 기능 등록

기존 서비스에 새로운 기능 등록하기 (DuoChat)

새로운 독립 서비스 등록하기

기존 서비스와 독립형 기능의 조합으로 기능 등록

GitLab Rails에서 권한 검사 구현

새 기능이 독립형 서비스로 제공됨

접근 토큰

권한 검증

예시

새로운 기능이 기존 서비스의 일부로 제공됩니다 (Duo Chat)

액세스 토큰

권한 확인

백엔드 서비스에서 권한 확인 구현

새로운 기능이 새로운 백엔드 서비스를 통해 도입됩니다

JWT 검증 설정

토큰 검증을 위한 JWKS 유지

JWT를 JWKS로 검증하기

새로운 클라우드 커넥터 route 추가

테스트

도움말

기능 사용 가능성과 제품 평가판

도움받기