GitLab UI에서 서명된 커밋

요약

이 기능의 사용 가능 여부는 기능 플래그로 제어됩니다. GitLab 사용자 인터페이스에서 커밋을 생성하면 그 커밋은 사용자가 직접 푸시하는 것이 아닙니다. 이러한 커밋에 서명할 때 GitLab은 인스턴스에 구성된 전역 키를 사용합니다.

히스토리

서명된 GitLab UI 커밋에 Verified 배지를 표시하는 기능이 GitLab 16.3에서 gitaly_gpg_signing 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
rotated_signing_keys 옵션에 지정된 여러 키로 서명을 검증하는 기능이 GitLab 16.3에서 도입되었습니다.
gitaly_gpg_signing 기능 플래그가 GitLab 17.0에서 GitLab Self-Managed 및 GitLab Dedicated에 대해 기본적으로 활성화되었습니다.

Feature flag

이 기능의 사용 가능 여부는 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트 용도로 사용할 수 있으며 프로덕션 환경에서 사용할 준비는 되지 않았습니다.

GitLab 사용자 인터페이스에서 커밋을 생성하면 그 커밋은 사용자가 직접 푸시하는 것이 아닙니다. 대신 사용자를 대신하여 커밋이 생성됩니다.

이러한 커밋에 서명할 때 GitLab은 인스턴스에 구성된 전역 키를 사용합니다. GitLab은 사용자의 개인 키에 액세스할 수 없으므로, 생성된 커밋은 계정에 연결된 키로 서명할 수 없습니다.

Note

GitLab이 검증한 서명이 있는 커밋은 리포지터리 미러링 작업에서도 나타날 수 있습니다. 두 경우 모두 Gitaly가 인스턴스에 구성된 서명 키로 커밋에 암호학적으로 서명합니다.

예를 들어 사용자 A가 사용자 B가 작성한 제안을 적용하면 커밋에는 다음이 포함됩니다:

Author: User A <a@example.com>
Committer: GitLab <noreply@gitlab.com>

Co-authored-by: User B <b@example.com>

사전 요구 사항#

GitLab UI 커밋에 커밋 서명을 사용하려면 먼저 서명을 구성해야 합니다.

그룹 또는 프로젝트에 대한 웹 기반 커밋 서명 켜기#

히스토리

GitLab 18.3에서 configure_web_based_commit_signing 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 18.9에서 GitLab.com에 활성화되었습니다.
GitLab 18.10에서 일반 공급되었습니다. 기능 플래그 configure_web_based_commit_signing 이 제거되었습니다.

웹 기반 커밋 서명은 그룹의 모든 프로젝트에 대해 켜거나 개별 프로젝트에 대해 켤 수 있습니다.

웹 기반 커밋 서명을 켜면 GitLab UI(웹 에디터, 웹 IDE, 머지 리퀘스트)를 통해 이루어진 모든 커밋이 인스턴스에 구성된 서명 키로 자동으로 서명됩니다.

그룹의 경우#

사전 요구 사항:

그룹에 대한 Owner 권한이 있어야 합니다.

그룹의 모든 프로젝트에 대해 웹 기반 커밋 서명을 켜려면 다음 단계를 수행합니다:

상단 표시줄에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Settings > Repository를 선택합니다.
General을 확장합니다.
Sign web-based commits 확인란을 선택합니다.

그룹의 프로젝트는 이 설정을 상속합니다.

프로젝트의 경우#

사전 요구 사항:

프로젝트에 대한 Maintainer 또는 Owner 권한이 있어야 합니다.

Note

해당 프로젝트는 웹 기반 커밋 서명이 이미 켜져 있는 그룹에 속해 있지 않아야 합니다. 그룹 설정이 켜져 있으면 프로젝트 확인란을 사용할 수 없습니다.

프로젝트에 대해 웹 기반 커밋 서명을 켜려면 다음 단계를 수행합니다:

상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Settings > Repository를 선택합니다.
General을 확장합니다.
Sign web-based commits 확인란을 선택합니다.

커밋의 커미터 필드#

Git에서 커밋에는 작성자와 커미터가 모두 있습니다. 웹 커밋의 경우 Committer 필드를 구성할 수 있습니다. 이 필드를 업데이트하려면 GitLab UI 커밋에 대한 커밋 서명 구성을 참고합니다.

GitLab은 Committer 필드가 커밋을 생성한 사용자로 설정되어 있어야 하는 여러 보안 기능을 제공합니다. 예를 들면 다음과 같습니다:

푸시 규칙: (Reject unverified users 또는 Commit author's email).
머지 리퀘스트 승인 차단.

인스턴스가 서명한 커밋은 Committer 필드에 인스턴스 이메일 주소가 들어가므로, Commit author's email 푸시 규칙은 대신 Author 필드를 확인합니다. Reject unverified users 푸시 규칙은 GitLab UI에서 생성된 커밋에 대해 Author 필드를 확인합니다. 푸시 미러 등에서 일반 Git 푸시로 들어온 서명된 커밋에 대해서는 GitLab이 이 규칙을 건너뜁니다.

REST API를 사용하여 생성된 커밋#

REST API를 사용하여 생성된 커밋도 웹 기반 커밋으로 간주됩니다. REST API 엔드포인트를 사용하면 커밋의 author_name 및 author_email 필드를 설정할 수 있으며, 이를 통해 다른 사용자를 대신하여 커밋을 생성할 수 있습니다.

커밋 서명이 활성화되어 있으면 API 요청을 보낸 사용자와 다른 author_name 및 author_email을 가진 REST API 커밋은 거부됩니다.

문제 해결#

리베이스 후 웹 커밋이 서명되지 않게 됨#

다음 경우에 브랜치에서 이전에 서명된 커밋이 서명되지 않은 상태가 됩니다:

GitLab UI에서 생성된 커밋에 대해 커밋 서명이 구성되어 있습니다.
GitLab UI에서 머지 리퀘스트를 리베이스합니다.

이는 이전 커밋이 수정되어 대상 브랜치 위에 추가되기 때문입니다. GitLab은 이러한 커밋에 서명할 수 없습니다.

이 문제를 우회하려면 로컬에서 브랜치를 리베이스한 다음 변경 사항을 GitLab으로 다시 푸시합니다.

GitLab UI에서 서명된 커밋

GitLab v19.5

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed, GitLab Dedicated

원문 보기

번역일: 2026-09-18

요약

히스토리

서명된 GitLab UI 커밋에 Verified 배지를 표시하는 기능이 GitLab 16.3에서 gitaly_gpg_signing 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
rotated_signing_keys 옵션에 지정된 여러 키로 서명을 검증하는 기능이 GitLab 16.3에서 도입되었습니다.
gitaly_gpg_signing 기능 플래그가 GitLab 17.0에서 GitLab Self-Managed 및 GitLab Dedicated에 대해 기본적으로 활성화되었습니다.

Feature flag

GitLab 사용자 인터페이스에서 커밋을 생성하면 그 커밋은 사용자가 직접 푸시하는 것이 아닙니다. 대신 사용자를 대신하여 커밋이 생성됩니다.

Note

예를 들어 사용자 A가 사용자 B가 작성한 제안을 적용하면 커밋에는 다음이 포함됩니다:

Author: User A <a@example.com>
Committer: GitLab <noreply@gitlab.com>

Co-authored-by: User B <b@example.com>

사전 요구 사항#

GitLab UI 커밋에 커밋 서명을 사용하려면 먼저 서명을 구성해야 합니다.

그룹 또는 프로젝트에 대한 웹 기반 커밋 서명 켜기#

히스토리

GitLab 18.3에서 configure_web_based_commit_signing 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 18.9에서 GitLab.com에 활성화되었습니다.
GitLab 18.10에서 일반 공급되었습니다. 기능 플래그 configure_web_based_commit_signing 이 제거되었습니다.

웹 기반 커밋 서명은 그룹의 모든 프로젝트에 대해 켜거나 개별 프로젝트에 대해 켤 수 있습니다.

웹 기반 커밋 서명을 켜면 GitLab UI(웹 에디터, 웹 IDE, 머지 리퀘스트)를 통해 이루어진 모든 커밋이 인스턴스에 구성된 서명 키로 자동으로 서명됩니다.

그룹의 경우#

사전 요구 사항:

그룹에 대한 Owner 권한이 있어야 합니다.

그룹의 모든 프로젝트에 대해 웹 기반 커밋 서명을 켜려면 다음 단계를 수행합니다:

상단 표시줄에서 Search or go to를 선택하고 그룹을 찾습니다.
왼쪽 사이드바에서 Settings > Repository를 선택합니다.
General을 확장합니다.
Sign web-based commits 확인란을 선택합니다.

그룹의 프로젝트는 이 설정을 상속합니다.

프로젝트의 경우#

사전 요구 사항:

프로젝트에 대한 Maintainer 또는 Owner 권한이 있어야 합니다.

Note

프로젝트에 대해 웹 기반 커밋 서명을 켜려면 다음 단계를 수행합니다:

상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Settings > Repository를 선택합니다.
General을 확장합니다.
Sign web-based commits 확인란을 선택합니다.

커밋의 커미터 필드#

GitLab은 Committer 필드가 커밋을 생성한 사용자로 설정되어 있어야 하는 여러 보안 기능을 제공합니다. 예를 들면 다음과 같습니다:

푸시 규칙: (Reject unverified users 또는 Commit author's email).
머지 리퀘스트 승인 차단.

REST API를 사용하여 생성된 커밋#

커밋 서명이 활성화되어 있으면 API 요청을 보낸 사용자와 다른 author_name 및 author_email을 가진 REST API 커밋은 거부됩니다.

문제 해결#

리베이스 후 웹 커밋이 서명되지 않게 됨#

다음 경우에 브랜치에서 이전에 서명된 커밋이 서명되지 않은 상태가 됩니다:

GitLab UI에서 생성된 커밋에 대해 커밋 서명이 구성되어 있습니다.
GitLab UI에서 머지 리퀘스트를 리베이스합니다.

이는 이전 커밋이 수정되어 대상 브랜치 위에 추가되기 때문입니다. GitLab은 이러한 커밋에 서명할 수 없습니다.

이 문제를 우회하려면 로컬에서 브랜치를 리베이스한 다음 변경 사항을 GitLab으로 다시 푸시합니다.