히스토리

• GitLab 18.3에서 duo_workflow_use_composite_identity 플래그와 함께 도입되었습니다.
• GitLab 18.8에서 일반 사용 가능해졌습니다.
• 복합 ID가 GitLab Duo Agent Platform에 자동으로 포함되고 복합 ID를 켜거나 끄는 설정이 GitLab 18.9에서 제거되었습니다.

복합 ID는 두 가지 ID를 단일 토큰으로 결합하는 인증 및 권한 부여 메커니즘입니다:

• 서비스 계정: 실제 작업을 수행하는 머신 사용자.
• 사람 사용자: 요청을 시작한 사람.

복합 ID는 GitLab Duo Agent Platform에 자동으로 포함됩니다.

이 이중 ID 접근 방식은 중요한 문제를 해결합니다: 에이전트는 에이전트를 트리거한 사용자의 접근 권한이나 서비스 계정에 부여된 접근 권한을 초과하지 않는 접근 방식으로 작업을 수행해야 하며, 작업이 사람 사용자가 직접 수행한 것이 아니라 에이전트에 의해 수행되었음을 명확하게 보여주는 별개의 ID를 유지해야 합니다.

복합 ID가 중요한 이유#

복합 ID는 다음을 보장하는 데 도움이 되기 때문에 중요합니다:

• 추적 가능성: 모든 에이전트 활동은 서비스 계정에 명확하게 귀속되어 감사 로그 및 커밋 히스토리에서 자동화된 작업을 쉽게 식별할 수 있습니다.
• 보안: 에이전트는 서비스 계정과 트리거한 사용자 모두 접근 권한이 있는 작업만 수행할 수 있습니다. 이 교차 접근은 권한 상승을 방지합니다.
• 책임: 사람 사용자의 ID가 토큰에 내장되어 에이전트 작업을 시작한 사람에게 연결하는 감사 추적을 만듭니다.

예를 들어 에이전트에게 코드에 대한 테스트를 만들어달라고 요청하면, 결과 커밋은 서비스 계정에 의해 사용자를 대신하여 만들어진 것으로 표시됩니다.

복합 ID가 사용되는 곳#

복합 ID는 플로우와 에이전트가 러너에서 실행될 때 사용됩니다. 다음을 포함합니다:

• 파운데이셔널 플로우.
• 커스텀 플로우.
• 외부 에이전트.
• api/v4/ai/duo_workflows/workflows 엔드포인트를 통해 시작된 모든 플로우.

복합 ID는 UI 및 IDE의 GitLab Duo 에이전틱 Chat에는 적용되지 않습니다.

복합 ID 작동 방식#

요청을 인증하는 토큰은 두 가지 ID의 복합체입니다:

• 기본 작성자: 에이전트 또는 플로우를 시작한 사람 사용자. 사람 사용자의 id는 동적 범위를 사용하여 토큰의 범위에 포함됩니다.
• 보조 작성자: 서비스 계정으로, 토큰의 소유자이며 개발자 권한을 가집니다.

이 복합 ID는 GitLab Duo Agent Platform에 의해 작성된 모든 활동이 사람 사용자에게 귀속되도록 하면서, 사람 사용자나 서비스 계정에 의한 권한 상승을 방지합니다.

복합 ID 워크플로우#

복합 ID는 워크플로우의 일부입니다.

1. AI 카탈로그에서 플로우를 만듭니다.
   • 복합 ID 관련 변경은 발생하지 않습니다.
2. 프로젝트에 플로우를 활성화합니다.
   • 최상위 그룹에 서비스 계정이 만들어집니다. (이름은 ai-flowname-groupname과 유사합니다.)
   • 서비스 계정이 개발자 권한으로 프로젝트에 추가됩니다.
3. 사용자가 플로우를 실행합니다.

   • 플로우는 일회성 복합 ID로 실행됩니다. 이 ID는 사용자의 권한과 서비스 계정의 개발자 권한의 조합으로, 더 제한적인 쪽이 사용됩니다. 사용자가 메인테이너이지만 서비스 계정이 개발자인 경우 개발자 권한이 사용됩니다.

   • 플로우는 다음 두 조건을 모두 충족하는 모든 프로젝트에 접근할 수 있습니다:

     • 사용자가 접근 권한이 있는 프로젝트.
     • 서비스 계정이 추가된 프로젝트.

     예를 들어 서비스 계정이 다른 프로젝트에 추가되었고 사용자가 해당 프로젝트에 접근 권한이 있는 경우, 사용자가 이전에 해당 프로젝트에서 플로우를 사용하지 않았더라도 플로우가 해당 프로젝트에 접근할 수 있습니다.

AI 카탈로그 플로우의 토큰 권한#

AI 카탈로그 플로우는 다양한 권한 범위를 가진 다른 토큰 유형을 사용합니다:

• AI 워크플로우에서 복합 ID에 사용되는 OAuth 토큰은 ai_workflows 및 mcp 범위로 제한된 접근이 있습니다. 이 OAuth 토큰은 플로우를 실행하기 위해 AI Gateway로 전달됩니다.
• 플로우의 일부로 트리거되는 CI job 토큰은 사용 가능한 job 토큰 권한으로 추가 제한됩니다.

이들이 다른 범위를 가진 다른 토큰 유형이기 때문에 CI/CD job은 OAuth 토큰과 다른 권한을 가집니다.

머지 리퀘스트에 대한 컴플라이언스 고려사항#

플로우가 머지 리퀘스트를 만들면 서비스 계정이 아닌 플로우를 트리거한 사람 사용자에게 머지 리퀘스트가 귀속됩니다. 이는 다음과 같은 의무 분리를 요구하는 컴플라이언스 프레임워크를 준수하기 위한 것입니다:

• SOC 2 (시스템 및 조직 제어 2)
• SOX (사베인스-옥슬리 법)
• ISO 27001 (정보 보안 관리)
• FedRAMP (연방 위험 및 권한 관리 프로그램)

이러한 프레임워크는 일반적으로 사용자가 코드 변경을 작성하고 프로덕션 배포를 위해 해당 변경 사항을 승인할 수 없도록 요구합니다.

귀속 모델 이해#

서비스 계정이 커밋을 만들고 머지 리퀘스트를 열지만 다음과 같은 이유로 사람 사용자가 작성자로 간주됩니다:

• 사람 사용자가 서비스 계정에 변경 사항을 만들도록 지시했습니다.
• 컴플라이언스 관점에서 AI 시스템에 코드 작성을 촉구하는 것은 직접 코드를 작성하는 것과 동일합니다.
• 서비스 계정은 사람 사용자의 의도에 대한 프록시 역할을 합니다.