프로젝트의 보안 강화
요청자에게 전송된 이메일 사용자화
서비스 데스크 티켓을 위한 사용자 정의 템플릿 사용
지원 봇 사용자
- 지원 봇의 표시 이름 변경
외부 참가자가 코멘트를 추가할 때 이슈 재오픈
커스텀 이메일 주소
추가 서비스 데스크 별칭 이메일 사용
- 서비스 데스크 별칭 이메일 구성
  - 암호화된 자격 증명 사용
  - Microsoft Graph
- 서비스 데스크 별칭 이메일을 구성합니다
다중 노드 환경에서 이메일 수신 구성
- Helm 차트(Kubernetes)
- Linux 패키지(Omnibus)
  - 모든 노드 설정
  - 단일 이메일 수신 노드 설정

서비스 데스크 구성

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed

새로운 프로젝트에서는 기본적으로 서비스 데스크가 활성화되어 있습니다. 활성화되지 않은 경우 프로젝트 설정에서 활성화할 수 있습니다.

전제 조건:

프로젝트의 유지자 역할을 적어도 갖고 있어야 합니다.
GitLab Self-managed의 경우 GitLab 인스턴스에 수신 이메일을 설정해야 합니다. 이메일 하위 주소 지정을 사용해야 하지만, catch-all 메일함을 사용할 수도 있습니다. 이를 위해서는 관리자 액세스 권한이 있어야 합니다.
프로젝트의 이슈 추적기가 활성화되어 있어야 합니다.

프로젝트에서 서비스 데스크를 활성화하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
서비스 데스크 활성화 토글을 켭니다.
선택 사항. 필드를 작성합니다.
- 서비스 데스크 별칭 이메일에 접미사 추가.
- 아래 모든 서비스 데스크 이슈에 추가할 템플릿 디렉터리이 비어 있는 경우, 리포지터리에 설명 템플릿을 생성합니다.
변경 사항 저장을 선택합니다.

이제 이 프로젝트에 대해 서비스 데스크가 활성화되었습니다. 아무나 아래 서비스 데스크에 사용할 이메일 주소로 이메일을 보내면, GitLab은 해당 이메일의 내용으로 비밀 이슈를 생성합니다.

프로젝트의 보안 강화

서비스 데스크 프로젝트의 보안을 강화하려면 다음을 수행해야 합니다:

서비스 데스크 이메일 주소를 이메일 시스템의 별칭 뒤에 두어 나중에 변경할 수 있도록 해야 합니다.
GitLab 인스턴스에서 Akismet을 활성화하여 이 서비스에 스팸 확인을 추가해야 합니다. 차단되지 않은 이메일 스팸은 많은 스팸 이슈가 생성되는 결과를 낳을 수 있습니다.

요청자에게 전송된 이메일 사용자화

GitLab 13.2에서 GitLab Premium에서 GitLab Free로 이동되었습니다.
UNSUBSCRIBE_URL, SYSTEM_HEADER, SYSTEM_FOOTER, 그리고 ADDITIONAL_TEXT 플레이스홀더는 GitLab 15.9에 소개되었습니다.
%{ISSUE_DESCRIPTION}는 GitLab 16.0에 소개되었습니다.
%{ISSUE_URL}는 GitLab 16.1에 소개되었습니다.

요청자에게 이메일이 전송될 때:

요청자가 서비스 데스크로 이메일을 보내어 새 티켓을 제출하는 경우.
서비스 데스크 티켓에 새로운 공개 코멘트가 추가된 경우.
- 코멘트를 편집하는 것은 새로운 이메일을 전송하지 않습니다.

이러한 이메일 메시지의 본문을 서비스 데스크 이메일 템플릿을 사용하여 사용자 정의할 수 있습니다. 템플릿은 GitLab Flavored Markdown과 일부 HTML 태그를 포함할 수 있습니다. 예를 들어, 당신의 조직의 브랜드 가이드에 따라 이메일 형식을 지정할 수 있습니다. 또한 서비스 데스크 티켓이나 GitLab 인스턴스에 특정한 동적 콘텐츠를 표시하기 위해 다음과 같은 플레이스홀더를 포함할 수 있습니다.

플레이스홀더	`thank_you.md`	`new_note.md`	설명
`%{ISSUE_ID}`	예	예	티켓 IID.
`%{ISSUE_PATH}`	예	예	티켓 IID가 붙은 프로젝트 경로.
`%{ISSUE_URL}`	예	예	티켓의 URL. 외부 참가자는 프로젝트가 공개되어 있고 티켓이 비밀이 아닌 경우에만 티켓을 확인할 수 있습니다 (서비스 데스크 티켓은 기본적으로 비밀입니다).
`%{ISSUE_DESCRIPTION}`	예	예	티켓 설명. 사용자가 설명을 편집한 경우, 외부 참가자에게 전달되어서는 안 되는 민감한 정보를 포함할 수 있습니다. 이 플레이스홀더를 사용할 때는 주의 깊게 사용하고 이상적으로는 설명을 수정하지 않고 팀이 템플릿 디자인을 인식하는 경우에만 사용하세요.
`%{UNSUBSCRIBE_URL}`	예	예	구독 취소 URL.
`%{NOTE_TEXT}`	아니오	예	사용자가 티켓에 추가한 새 코멘트. 요청자가 그들의 서비스 데스크 티켓의 업데이트를 볼 수 있도록 이 플레이스홀더를 포함하는 데 주의하세요.

감사 이메일

서비스 데스크를 통해 요청자가 이슈를 제출하면, GitLab은 감사 이메일을 전송합니다. 추가 구성 없이 기본 감사 이메일을 GitLab이 전송합니다.

사용자 정의 감사 이메일 템플릿을 작성하려면:

리포지터리의 .gitlab/service_desk_templates/ 디렉터리에서 thank_you.md라는 파일을 생성합니다.
Markdown 파일에 GitLab Flavored Markdown, 일부 선택된 HTML 태그 및 응답을 사용자 정의하기 위한 플레이스홀더를 작성합니다.

새 코멘트 이메일

서비스 데스크 티켓에 새로운 공개 코멘트가 있으면, GitLab은 새 코멘트 이메일을 전송합니다. 추가 구성 없이 GitLab은 코멘트의 내용을 전송합니다.

이메일을 회사 브랜드에 맞게 유지하려면, 사용자 정의 새 코멘트 이메일 템플릿을 생성할 수 있습니다. 다음과 같이 수행하세요:

리포지터리의 .gitlab/service_desk_templates/ 디렉터리에 new_note.md라는 파일을 생성합니다.
텍스트, GitLab Flavored Markdown, 일부 선택된 HTML 태그 및 새 코멘트 이메일을 사용자 정의하기 위한 플레이스홀더를 작성합니다. 이메일 수신자가 코멘트의 내용을 볼 수 있도록 템플릿에 %{NOTE_TEXT}를 포함해야 합니다.

인스턴스 수준의 이메일 헤더, 푸터 및 추가 텍스트

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab 15.9에서 도입되었습니다.

인스턴스 관리자는 GitLab 인스턴스에 헤더, 푸터 또는 추가 텍스트를 추가하고 GitLab에서 전송되는 모든 이메일에 이를 적용할 수 있습니다. 사용자 정의 thank_you.md 또는 new_note.md를 사용하는 경우 해당 내용에 %{SYSTEM_HEADER}, %{SYSTEM_FOOTER}, 또는 %{ADDITIONAL_TEXT}를 템플릿에 추가하십시오.

더 많은 정보는 시스템 헤더 및 푸터 메시지 및 사용자 정의 추가 텍스트를 참조하세요.

서비스 데스크 티켓을 위한 사용자 정의 템플릿 사용

각 프로젝트마다 하나의 설명 템플릿을 선택하여 모든 새로운 서비스 데스크 티켓 설명에 추가할 수 있습니다.

설명 템플릿은 여러 수준에서 설정할 수 있습니다:

템플릿은 상속됩니다. 예를 들어 프로젝트에서는 인스턴스 또는 프로젝트의 상위 그룹에 설정된 템플릿에도 액세스할 수 있습니다.

전제 조건:

설명 템플릿을 만들었어야 합니다.

서비스 데스크에서 사용자 정의 설명 템플릿을 사용하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
드롭다운 디렉터리에서 모든 서비스 데스크 이슈에 추가할 템플릿을 검색하거나 선택합니다.

지원 봇 사용자

서비스 데스크는 특별한 지원 봇 사용자가 이슈를 생성함으로써 작동합니다. 이 사용자는 과금 대상 사용자가 아니므로 라이선스 제한 수에는 포함되지 않습니다.

GitLab 16.0 및 이전 버전에서 서비스 데스크 이메일에서 생성된 코멘트는 생성자로 GitLab Support Bot으로 표시됩니다. GitLab 16.1 및 이후에서는 이러한 코멘트가 이메일을 보낸 사용자의 이메일로 표시됩니다. 이 기능은 GitLab 16.1 이후에서만 적용됩니다.

지원 봇의 표시 이름 변경

지원 봇 사용자의 표시 이름을 변경할 수 있습니다. 서비스 데스크에서 보낸 이메일의 From 헤더에는 이 이름이 표시됩니다. 기본 표시 이름은 GitLab Support Bot입니다.

커스텀 이메일 표시 이름 수정 방법:

왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
이메일 표시 이름 아래에 새로운 이름을 입력합니다.
변경 사항 저장을 선택합니다.

외부 참가자가 코멘트를 추가할 때 이슈 재오픈

GitLab 16.7에서 도입되었습니다.

이메일을 통해 외부 참가자가 이슈에 새 코멘트를 추가하면 GitLab를 구성하여 닫혔던 이슈를 다시 엽니다. 이로써 이슈의 담당자에 대한 내부 코멘트가 추가되고, 그들을 위해 할 일이 생성됩니다.

실제 적용 방법에 대한 자세한 내용은 짧은 소개 비디오를 참조하세요.

전제 조건:

프로젝트의 유지자(Maintainer) 역할 이상이어야 합니다.

이 설정을 활성화하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
외부 참가자의 새 코멘트로 인해 이슈 재오픈 확인란을 선택합니다.
변경 사항 저장을 선택합니다.

커스텀 이메일 주소

Status: Beta

GitLab 16.3에서 service_desk_custom_email 플래그와 함께 도입. 기본 설정은 비활성화됨.
GitLab 16.4에서 GitLab.com 및 Self-managed에 적용됨.
SMTP 인증 방법 선택 기능이 GitLab 16.6에 도입되었습니다.
GitLab 16.7에 service_desk_custom_email 피처 플래그가 제거되었습니다.
로컬 네트워크가 GitLab Self-managed에서 허용되었습니다.

브랜드 식별성을 유지하고 지원 요청자들 사이에서 신뢰를 유발하는 커스텀 이메일 주소를 구성하세요.

개요는 짧은 소개 비디오를 참조하세요.

이 기능은 베타 상태입니다. 베타 기능은 제품 출시 전에는 본격적으로 변하지는 않지만, 출시 전에 크게 변할 가능성이 있습니다. 사용자들이 베타 기능을 사용하고 피드백 이슈에서 피드백을 제공하도록 권장합니다.

전제 조건

프로젝트 당 하나의 커스텀 이메일 주소를 사용할 수 있으며, 인스턴스 전체에서 고유해야 합니다.

사용하려는 커스텀 이메일 주소는 다음 요구 사항을 모두 충족해야 합니다:

이메일 전달을 설정할 수 있어야 합니다.
전달된 이메일은 원래의 From 헤더를 유지해야 합니다.
서비스 제공업체가 하위 주소 지원해야 합니다. 이메일 주소는 로컬 부분(‘@’ 문자 이전 모든 내용)과 도메인 부분으로 구성됩니다.
이메일 하위 주소를 사용하면 로컬 부분에 ‘+’ 기호 뒤에 어떤 텍스트든 추가하여 이메일 주소의 고유 변형을 만들 수 있습니다. 이메일 주소가 support@example.com일 때, 이 주소에 support+1@example.com로 이메일을 보내고 이를 받는지 확인해야 합니다.
SMTP 자격 증명이 있어야 합니다(이상적으로는 앱 비밀번호를 사용해야 합니다). 사용자 이름과 암호는 Advanced Encryption Standard(AES) 및 256비트 키를 사용하여 데이터베이스에 저장됩니다.
SMTP 호스트는 GitLab Self-managed의 네트워크(또는 GitLab SaaS의 공용 인터넷)에서 해결할 수 있어야 합니다.
프로젝트의 유지자(Maintainer) 역할 이상이어야 합니다.
프로젝트에 대해 서비스 데스크가 설정되어 있어야 합니다.

사용자 정의 이메일 주소 구성

귀하의 이메일 주소를 사용하여 서비스 데스크 이메일을 보내고 싶을 때 사용자 정의 이메일 주소를 구성하고 확인하세요.

왼쪽 사이드바에서 검색 또는 참조를 선택하고 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장하고 사용자 정의 이메일 주소 구성 섹션을 찾습니다.
해당 프로젝트의 서비스 데스크 주소를 확인하고 이메일 제공업체(Gmail 등)와 함께 이 사용자 정의 이메일 주소에서 서비스 데스크 주소로의 이메일 전달을 설정합니다.
GitLab으로 돌아와서 필드를 작성합니다.
저장 및 연결 테스트를 선택합니다.

구성이 저장되었으며, 사용자 정의 이메일 주소의 확인이 트리거되었습니다.

확인

구성을 완료한 후, 모든 프로젝트 소유자 및 사용자 정의 이메일 구성을 저장한 관리자는 알림 이메일을 받습니다.
제공된 SMTP 자격 증명을 사용하여 확인 이메일이 사용자 정의 이메일 주소(하위 주소 부분이 있는)로 전송됩니다. 해당 이메일에는 확인 토큰이 포함되어 있습니다. 이메일 전달이 올바르게 설정되고 모든 전제 조건이 충족되면, 해당 이메일은 서비스 데스크 주소로 전달되어 GitLab에 의해 수신됩니다. GitLab은 다음 조건을 확인합니다.
1. GitLab이 SMTP 자격 증명을 사용하여 이메일을 보낼 수 있는지 확인합니다.
2. 하위 주소 지원 여부(+verify 하위 주소를 포함).
3. 전달 후에도 From 헤더가 유지되는지 확인합니다.
4. 확인 토큰이 올바른지 확인합니다.
5. 30분 이내에 이메일이 수신되었는지 확인합니다.

일반적으로 이 프로세스는 몇 분 정도 소요됩니다.

언제든지 확인을 취소하거나 실패했을 경우, 사용자 정의 이메일 재설정을 선택합니다. 설정 페이지는 이에 해당하는 업데이트를 수행하고 확인의 현재 상태를 반영합니다. SMTP 자격 증명이 삭제되며, 사용자 정의 이메일을 다시 구성할 수 있습니다.

실패 및 성공의 경우, 모든 프로젝트 소유자와 확인 프로세스를 트리거한 사용자는 확인 결과를 나타내는 알림 이메일을 받습니다. 확인이 실패한 경우, 이메일에는 실패 이유의 세부 정보도 포함됩니다.

확인이 성공하면, 사용자 정의 이메일 주소를 사용할 수 있습니다. 이제 사용자 정의 이메일 주소를 통해 서비스 데스크 이메일을 보낼 수 있습니다.

구성 문제 해결

사용자 정의 이메일을 구성하는 동안 다음과 같은 문제가 발생할 수 있습니다.

잘못된 자격 증명

잘못된 자격 증명을 사용했다는 오류가 발생할 수 있습니다.

이는 SMTP 서버가 인증에 성공하지 않았다고 반환되었을 때 발생합니다.

다음을 해결하려면:

SMTP 자격 증명을 확인하십시오, 특히 사용자 이름 및 암호를 확인하십시오.
때로는 GitLab이 SMTP 서버에서 지원하는 인증 방법을 자동으로 선택하지 못할 수 있습니다.
- 사용 가능한 인증 방법을 시도합니다(일반, 로그인, CRAM-MD5).
- ‘swaks’ 명령 줄 도구를 사용하여 SMTP 서버가 지원하는 인증 방법을 확인합니다.
  1. 다음 명령을 자격 증명과 함께 실행하고 250-AUTH로 시작하는 줄을 찾습니다:
    swaks --to user@example.com \ --from support@example.com \ --auth-user support@example.com \ --server smtp@example.com:587 \ -tls-optional \ --auth-password your-app-password
  2. 사용자 정의 이메일 설정 양식에서 지원되는 인증 방법 중 하나를 선택합니다.

잘못된 전달 대상

잘못된 전달 대상을 사용했다는 오류가 발생할 수 있습니다.

이는 확인 이메일이 프로젝트별 서비스 데스크 주소와 일치하지 않는 이메일 주소로 전달되었을 때 발생합니다. 사용자 정의 이메일 구성 양식에 표시된 추가 서비스 데스크 별칭 주소 (service_desk_email에서 생성된)로의 전달은 지원되지 않기 때문에 발생합니다.

다음을 해결하려면:

이메일을 전달할 올바른 이메일 주소를 찾습니다.
- 프로젝트 소유자와 확인 프로세스를 트리거한 사용자에게서 받는 확인 결과 이메일에서 주소를 찾습니다.
- 사용자 정의 이메일 설정 양식의 이메일 전달할 서비스 데스크 이메일 주소 입력에서 주소를 복사합니다.
모든 이메일을 사용자 정의 이메일 주소로 올바른 대상 이메일 주소로 전달합니다.

사용자 정의 이메일 주소 활성화 또는 비활성화

사용자 정의 이메일 주소가 확인되면, 관리자는 사용자 정의 이메일 주소를 통해 서비스 데스크 이메일을 보내거나 보내지 않도록 사용할 수 있습니다.

사용자 정의 이메일 주소를 활성화하려면:

왼쪽 사이드바에서 검색 또는 참조를 선택하고 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
사용자 정의 이메일 활성화 토글 스위치를 켭니다. 외부 참가자에게 보내는 서비스 데스크 이메일은 SMTP 자격 증명을 사용하여 전송됩니다.

사용자 정의 이메일 주소를 비활성화하려면:

왼쪽 사이드바에서 검색 또는 참조를 선택하고 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
사용자 정의 이메일 비활성화 토글 스위치를 끕니다. 이메일 전달을 설정했기 때문에 사용자 정의 이메일 주소로의 이메일은 계속 처리되며 프로젝트에서 서비스 데스크 티켓으로 표시됩니다.
외부 참가자에게 보내는 서비스 데스크 이메일은 이제 GitLab 인스턴스의 기본 발신 이메일 구성을 사용하여 전송됩니다.

사용자 정의 이메일 구성 변경 또는 제거

사용자 정의 이메일 구성을 변경하려면, 이를 재설정하고 제거한 후 다시 사용자 정의 이메일을 구성해야 합니다.

프로세스 중 언제든지 구성을 재설정하려면 사용자 정의 이메일 재설정을 선택합니다. 이렇게 하면 자격 증명이 데이터베이스에서 삭제됩니다.

사용자 정의 이메일 회신 주소

외부 참가자는 이메일로 회신하여 서비스 데스크 티켓에 답변할 수 있습니다. GitLab은 이와 관련된 32자 회신 키를 사용하는 이메일 회신 주소를 사용합니다. 사용자 정의 이메일이 구성되면 GitLab은 해당 이메일에서 회신 주소를 생성합니다.

회사 소유 도메인을 사용하여 Google Workspace 사용

회사 소유 도메인을 사용하여 Google Workspace를 사용할 때 서비스 데스크용 사용자 정의 이메일 주소를 설정합니다.

전제 조건:

이미 Google Workspace 계정이 있어야 합니다.
테넌트에 대한 새 계정을 만들 수 있어야 합니다.

Google Workspace를 사용하여 사용자 정의 서비스 데스크 이메일 주소를 구성하려면:

Google Workspace 계정 구성
이메일 전달 설정
사용자 정의 이메일 주소 구성

Google Workspace 계정 구성

먼저, Google Workspace 계정을 만들고 구성해야 합니다.

Google Workspace에서:

사용하려는 사용자 정의 이메일 주소(support@example.com과 같은)용 새 계정을 만듭니다.
해당 계정으로 로그인하고 이중 인증을 활성화합니다.
앱 비밀번호 만들기를 통해 SMTP 암호로 사용할 앱 비밀번호를 만듭니다. 이를 안전한 위치에 저장하고 문자 사이에 공백을 제거합니다.

이제 이메일 전달 설정을 해야 합니다.

이메일 전달 구성

다음 단계에서는 GitLab과 Google Workspace 간에 이동이 필요합니다.

GitLab에서:

좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
이메일 전달을 위한 서비스 데스크 이메일 주소 아래의 이메일 주소를 확인합니다.

Google Workspace에서:

사용자 정의 이메일 계정에 로그인하고 전달 및 POP/IMAP 설정 페이지를 엽니다.
전달 주소 추가를 선택합니다.
사용자 정의 이메일 양식에서 서비스 데스크 이메일 주소를 입력합니다.
다음을 선택합니다.
입력 사항을 확인하고 진행을 선택합니다. Google은 서비스 데스크 이메일 주소로 이메일을 보내어 확인 코드를 요구합니다.

GitLab에서:

프로젝트의 이슈로 이동하고 Google의 확인 이메일로부터 새 이슈가 생성될 때까지 기다립니다.
이슈를 열고 확인 코드를 확인합니다.
(선택 사항) 이슈를 삭제합니다.

Google Workspace에서:

확인 코드를 입력하고 확인을 선택합니다.
오는 메일 복사본을 전송을 선택하고 드롭다운 디렉터리에서 서비스 데스크 이메일 주소가 선택되었는지 확인합니다.
페이지 하단에서 변경 사항 저장을 선택합니다.

다음으로, 사용자 지정 이메일 주소 구성을 위해 계속합니다.

사용자 지정 이메일 주소 구성

GitLab에서:

좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장하고 사용자 정의 이메일 설정을 찾습니다.
다음 필드를 작성합니다:
- 사용자 정의 이메일 주소: 여러분의 사용자 정의 이메일 주소.
- SMTP 호스트: smtp.gmail.com.
- SMTP 포트: 587.
- SMTP 사용자명: 사용자 정의 이메일 주소로 미리 채워집니다.
- SMTP 암호: 이전에 사용자 정의 이메일 계정에 대해 생성한 앱 암호.
- SMTP 인증 방법: GitLab이 서버에서 지원하는 방법을 선택하도록 합니다 (권장됨).
저장 및 연결 테스트를 선택합니다.
검증 과정 이후에 여러분은 사용자 정의 이메일 주소를 활성화할 수 있어야 합니다.

알려진 문제

일부 서비스 제공업체는 더 이상 SMTP 연결을 허용하지 않습니다. 종종 사용자별로 이를 활성화하고 앱 암호를 생성할 수 있습니다.
Microsoft Exchange는 From 헤더를 보존하지 않으므로 동일한 테넌트의 사용자 정의 이메일을 사용할 수 없습니다. 해결책으로는:
- GitLab SaaS에서 사용자 정의 이메일 주소에서 발신된 이메일을 GitLab SaaS의 서비스 데스크 이메일로 전달하기 위해 전송 규칙을 사용합니다. 현재 테넌트 외부의 이메일 주소로 전달하면 원본 From 헤더가 보존됩니다.
- GitLab Self-managed에서 사용자 정의 이메일 주소나 GitLab 인스턴스 incoming_email 또는 service_desk_email을 사용하기 위해 다른 서비스 제공업체의 서브도메인이나 다른 도메인을 사용합니다.

추가 서비스 데스크 별칭 이메일 사용

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab 13.0에서 도입.
GitLab 13.8에서 피처 플래그가 제거되었습니다.

인스턴스 수준에서 서비스 데스크에 대한 추가 별칭 이메일 주소를 사용할 수 있습니다.

이를 위해 인스턴스 구성에서 service_desk_email을 구성해야 합니다. 또한 서비스 데스크 별칭 이메일의 사용자 정의 접미사를 구성할 수도 있습니다.

서비스 데스크 별칭 이메일 구성

GitLab.com에서는 contact-project+%{key}@incoming.gitlab.com을 이메일 주소로 사용하는 사용자 정의 메일함이 이미 구성되어 있습니다. 프로젝트 설정에서 여전히 사용자 정의 접미사를 구성할 수 있습니다.

서비스 데스크는 기본적으로 오는 이메일 구성을 사용합니다. 그러나 서비스 데스크를 위한 별도의 이메일 주소를 설정하려면 프로젝트 설정에서 사용자 정의 접미사를 사용하여 service_desk_email을 구성해야 합니다.

전제 조건:

address는 @ 앞의 user 부분에 %{key} 자리 표시자를 포함해야 합니다. 이 자리 표시자는 이슈를 생성해야 하는 프로젝트를 식별하는 데 사용됩니다.
service_desk_email 및 incoming_email 구성은 항상 서로 다른 메일함을 사용하여 서비스 데스크 이메일이 올바르게 처리되도록 해야 합니다.

IMAP를 사용하여 서비스 데스크를 위한 사용자 정의 메일함을 구성하려면 다음 스니펫을 구성 파일에 추가합니다:

Linux 패키지 (Omnibus)

GitLab 15.3 이상에서 서비스 데스크는 보통의 Sidekiq 작업을 대기열에 추가하는 대신 Iwebhook (내부 API 호출)을 기본으로 사용합니다. GitLab 15.3에서 Linux 패키지 설치에서 webhook를 사용하려면 비밀 파일을 생성해야 합니다. 자세한 내용은 merge request 5927을 참조하십시오. GitLab 15.4에서 Linux 패키지 설치를 다시 구성하면 이 비밀 파일이 자동으로 생성되므로 별도의 비밀 파일 설정이 필요하지 않습니다. 자세한 내용은 issue 1462를 참조하십시오.

gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@gmail.com"
gitlab_rails['service_desk_email_email'] = "project_contact@gmail.com"
gitlab_rails['service_desk_email_password'] = "[REDACTED]"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_idle_timeout'] = 60
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_host'] = "imap.gmail.com"
gitlab_rails['service_desk_email_port'] = 993
gitlab_rails['service_desk_email_ssl'] = true
gitlab_rails['service_desk_email_start_tls'] = false

직접 컴파일 (소스)

service_desk_email:
  enabled: true
  address: "project_contact+%{key}@example.com"
  user: "project_contact@example.com"
  password: "[REDACTED]"
  host: "imap.gmail.com"
  delivery_method: webhook
  secret_file: .gitlab-mailroom-secret
  port: 993
  ssl: true
  start_tls: false
  log_path: "log/mailroom.log"
  mailbox: "inbox"
  idle_timeout: 60
  expunge_deleted: true

구성 옵션은 오는 이메일을 구성할 때와 동일합니다.

암호화된 자격 증명 사용

GitLab 15.9에서 도입됨.

서비스 데스크 이메일 자격 증명을 구성 파일의 평문으로 저장하는 대신, 선택적으로 암호화된 파일을 사용하여 수신 이메일 자격 증명을 저장할 수 있습니다.

전제 조건:

암호화된 자격 증명을 사용하려면 먼저 암호화된 구성을 활성화해야 합니다.

암호화된 파일에 대한 지원되는 구성 항목은 다음과 같습니다:

user
password

Linux package (Omnibus)

초기에 /etc/gitlab/gitlab.rb에서 서비스 데스크 구성이 다음과 같았다면:

gitlab_rails['service_desk_email_email'] = "service-desk-email@mail.example.com"
gitlab_rails['service_desk_email_password'] = "examplepassword"

암호화된 비밀을 편집합니다:

sudo gitlab-rake gitlab:service_desk_email:secret:edit EDITOR=vim

서비스 데스크 이메일 비밀의 암호화되지 않은 내용을 입력합니다:
```
user: 'service-desk-email@mail.example.com'
password: 'examplepassword'
```
/etc/gitlab/gitlab.rb를 편집하고 service_desk 설정을 제거합니다.
파일을 저장하고 GitLab을 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```

Helm 차트 (Kubernetes)

서비스 데스크 이메일 비밀을 저장하기 위해 Kubernetes 시크릿을 사용합니다. 자세한 정보는 Helm IMAP secrets에서 확인하세요.

Docker

초기에 docker-compose.yml에서 서비스 데스크 구성이 다음과 같았다면:

version: "3.6"
services:
  gitlab:
    image: 'gitlab/gitlab-ee:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['service_desk_email_email'] = "service-desk-email@mail.example.com"
        gitlab_rails['service_desk_email_password'] = "examplepassword"

컨테이너 내부로 들어가 암호화된 비밀을 편집합니다:

sudo docker exec -t <container_name> bash
gitlab-rake gitlab:service_desk_email:secret:edit EDITOR=editor

서비스 데스크 비밀의 암호화되지 않은 내용을 입력합니다:
```
user: 'service-desk-email@mail.example.com'
password: 'examplepassword'
```
docker-compose.yml를 편집하고 service_desk 설정을 제거합니다.
파일을 저장하고 GitLab을 다시 시작합니다:
```
docker compose up -d
```

Self-compiled (source)

초기에 /home/git/gitlab/config/gitlab.yml에서 서비스 데스크 구성이 다음과 같았다면:

production:
  service_desk_email:
    user: 'service-desk-email@mail.example.com'
    password: 'examplepassword'

암호화된 비밀을 편집합니다:

bundle exec rake gitlab:service_desk_email:secret:edit EDITOR=vim RAILS_ENVIRONMENT=production

서비스 데스크 비밀의 암호화되지 않은 내용을 입력합니다:
```
user: 'service-desk-email@mail.example.com'
password: 'examplepassword'
```
/home/git/gitlab/config/gitlab.yml를 편집하고 service_desk_email: 설정을 제거합니다.

파일을 저장하고 GitLab과 Mailroom을 다시 시작합니다:

# systemd를 사용하는 시스템
sudo systemctl restart gitlab.target
   
# SysV init을 사용하는 시스템
sudo service gitlab restart

Microsoft Graph

GitLab 14.9에서 도입된 대체 Azure 배포.
GitLab 15.11에서 Self-compiled (source) 설치를 위해 도입됨.

service_desk_email을 Microsoft Graph API를 사용하여 IMAP 대신 Microsoft Exchange Online 메일함을 읽도록 구성할 수 있습니다. Microsoft Graph용 OAuth 2.0 응용 프로그램을 수신 이메일과 동일한 방식으로 설정하세요.

Linux package (Omnibus)

다음과 같은 내용으로 /etc/gitlab/gitlab.rb를 편집하고 원하는 값을 대체합니다:

  gitlab_rails['service_desk_email_enabled'] = true
  gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
  gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
  gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
  gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
  gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
  gitlab_rails['service_desk_email_inbox_options'] = {
    'tenant_id': '<YOUR-TENANT-ID>',
    'client_id': '<YOUR-CLIENT-ID>',
    'client_secret': '<YOUR-CLIENT-SECRET>',
    'poll_interval': 60  # Optional
  }

미국 정부용 Microsoft Cloud나 기타 Azure 배포를 위해 azure_ad_endpoint 및 graph_endpoint 설정을 구성합니다. 예시:

  gitlab_rails['service_desk_email_inbox_options'] = {
    'azure_ad_endpoint': 'https://login.microsoftonline.us',
    'graph_endpoint': 'https://graph.microsoft.us',
    'tenant_id': '<YOUR-TENANT-ID>',
    'client_id': '<YOUR-CLIENT-ID>',
    'client_secret': '<YOUR-CLIENT-SECRET>',
    'poll_interval': 60  # Optional
  }

Helm 차트 (Kubernetes)

서비스 데스크 이메일의 OAuth 2.0 애플리케이션 클라이언트 시크릿을 포함하는 Kubernetes 시크릿을 생성합니다:
```
kubectl create secret generic service-desk-email-client-secret --from-literal=secret=<YOUR-CLIENT_SECRET>
```

GitLab 서비스 데스크 이메일 인증 토큰을 위한 Kubernetes 시크릿을 생성합니다. GitLab 설치를 위한 Helm 릴리스 이름으로 <name>을 대체하세요:

kubectl create secret generic <name>-service-desk-email-auth-token --from-literal=authToken=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

Helm 값들을 내보냅니다:

helm get values gitlab > gitlab_values.yaml

gitlab_values.yaml을 편집합니다:

global:
  appConfig:
  serviceDeskEmail:
    enabled: true
    address: "project_contact+%{key}@example.onmicrosoft.com"
    user: "project_contact@example.onmicrosoft.com"
    mailbox: inbox
    inboxMethod: microsoft_graph
    azureAdEndpoint: https://login.microsoftonline.com
    graphEndpoint: https://graph.microsoft.com
    tenantId: "YOUR-TENANT-ID"
    clientId: "YOUR-CLIENT-ID"
    clientSecret:
      secret: service-desk-email-client-secret
      key: secret
    deliveryMethod: webhook
    authToken:
      secret: <name>-service-desk-email-auth-token
      key: authToken

미국 정부용 Microsoft Cloud나 기타 Azure 배포를 위해 azureAdEndpoint 및 graphEndpoint 설정을 구성합니다. 이러한 필드는 대소문자를 구분합니다:

global:
  appConfig:
  serviceDeskEmail:
    [..]
    azureAdEndpoint: https://login.microsoftonline.us
    graphEndpoint: https://graph.microsoft.us
    [..]

파일을 저장하고 새 값들을 적용합니다:

helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab

Docker

docker-compose.yml을 편집합니다:

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['service_desk_email_enabled'] = true
        gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
        gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
        gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
        gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
        gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
        gitlab_rails['service_desk_email_inbox_options'] = {
          'tenant_id': '<YOUR-TENANT-ID>',
          'client_id': '<YOUR-CLIENT-ID>',
          'client_secret': '<YOUR-CLIENT-SECRET>',
          'poll_interval': 60  # Optional
        }

파일을 저장하고 GitLab을 다시 시작합니다:
```
docker compose up -d
```

미국 정부용 Microsoft Cloud나 기타 Azure 배포를 위해 azure_ad_endpoint 및 graph_endpoint 설정을 구성합니다:

docker-compose.yml을 편집합니다:

version: "3.6"
services:
  gitlab:
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        gitlab_rails['service_desk_email_enabled'] = true
        gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
        gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
        gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
        gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
        gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
        gitlab_rails['service_desk_email_inbox_options'] = {
          'azure_ad_endpoint': 'https://login.microsoftonline.us',
          'graph_endpoint': 'https://graph.microsoft.us',
          'tenant_id': '<YOUR-TENANT-ID>',
          'client_id': '<YOUR-CLIENT-ID>',
          'client_secret': '<YOUR-CLIENT-SECRET>',
          'poll_interval': 60  # Optional
        }

파일을 저장하고 GitLab을 다시 시작합니다:
```
docker compose up -d
```

Self-compiled (source)

/home/git/gitlab/config/gitlab.yml을 편집합니다:

  service_desk_email:
    enabled: true
    address: "project_contact+%{key}@example.onmicrosoft.com"
    user: "project_contact@example.onmicrosoft.com"
    mailbox: "inbox"
    delivery_method: webhook
    log_path: "log/mailroom.log"
    secret_file: .gitlab-mailroom-secret
    inbox_method: "microsoft_graph"
    inbox_options:
      tenant_id: "<YOUR-TENANT-ID>"
      client_id: "<YOUR-CLIENT-ID>"
      client_secret: "<YOUR-CLIENT-SECRET>"
      poll_interval: 60  # Optional

미국 정부용 Microsoft Cloud나 기타 Azure 배포를 위해 azure_ad_endpoint 및 graph_endpoint 설정을 구성합니다. 예시:

     service_desk_email:
       enabled: true
       address: "project_contact+%{key}@example.onmicrosoft.com"
       user: "project_contact@example.onmicrosoft.com"
       mailbox: "inbox"
       delivery_method: webhook
       log_path: "log/mailroom.log"
       secret_file: .gitlab-mailroom-secret
       inbox_method: "microsoft_graph"
       inbox_options:
         azure_ad_endpoint: "https://login.microsoftonline.us"
         graph_endpoint: "https://graph.microsoft.us"
         tenant_id: "<YOUR-TENANT-ID>"
         client_id: "<YOUR-CLIENT-ID>"
         client_secret: "<YOUR-CLIENT-SECRET>"
         poll_interval: 60  # Optional

서비스 데스크 별칭 이메일을 구성합니다

프로젝트의 서비스 데스크 설정에서 사용자 정의 접미사를 설정할 수 있습니다.

접미사는 소문자(a-z), 숫자(0-9), 언더스코어(_)만 포함할 수 있습니다.

구성된 사용자 정의 접미사가 있다면, 이에 따라 새로운 서비스 데스크 이메일 주소가 생성되며, service_desk_email_address 설정과 <project_full_path>-<custom_suffix> 형식의 키로 구성됩니다.

필수 조건:

서비스 데스크 별칭 이메일을 구성해야 합니다.

왼쪽 사이드바에서 검색 또는 이동하여 프로젝트를 찾습니다.
설정 > 일반을 선택합니다.
서비스 데스크를 확장합니다.
이메일 주소 접미사 아래에 사용할 접미사를 입력합니다.
변경 사항 저장을 선택합니다.

예를 들어, mygroup/myproject 프로젝트의 서비스 데스크 설정이 다음과 같이 구성된 경우:

이메일 주소 접미사는 support로 설정됨.
서비스 데스크 이메일 주소는 contact+%{key}@example.com로 구성됨.

이 프로젝트의 서비스 데스크 이메일 주소는: contact+mygroup-myproject-support@example.com 입니다. incoming email 주소는 여전히 작동합니다.

사용자 정의 접미사를 구성하지 않으면 기본 프로젝트 식별이 프로젝트를 식별하는 데 사용됩니다.

다중 노드 환경에서 이메일 수신 구성

다중 노드 환경은 확장성, 장애 허용성 및 성능 이유로 GitLab이 여러 서버에서 실행되는 설정입니다.

GitLab은 mail_room이라는 별도의 프로세스를 사용하여 incoming_email 및 service_desk_email 메일함에서 새로운 읽지 않은 이메일을 수신합니다.

Helm 차트(Kubernetes)

GitLab Helm 차트는 여러 하위 차트로 구성되며, 그 중 하나가 Mailroom subchart입니다. common settings for incoming_email 및 common settings for service_desk_email을 구성합니다.

Linux 패키지(Omnibus)

다중 노드 Linux 패키지 설치 환경에서 mail_room을 하나의 노드에서만 실행합니다. 이를 rails 노드(예: application_role)에서 실행하거나 완전히 별도로 실행합니다.

모든 노드 설정

웹 UI 및 생성된 이메일에서 이메일 주소를 렌더링하기 위해 각 노드에 incoming_email 및 service_desk_email에 대한 기본 설정을 추가합니다.
/etc/gitlab/gitlab.rb에서 incoming_email 또는 service_desk_email 섹션을 찾습니다:
incoming_email
```
gitlab_rails['incoming_email_enabled'] = true
gitlab_rails['incoming_email_address'] = "incoming+%{key}@example.com"
```
service_desk_email
```
gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.com"
```

GitLab은 mail_room에서 GitLab 애플리케이션으로의 이메일 전송 방법을 제공합니다. 각 이메일 설정에 대해 delivery_method를 구성할 수 있습니다.

권장 사항: webhook (GitLab 15.3 이상의 기본 설정)은 이메일 페이로드를 API POST 요청을 통해 GitLab 애플리케이션으로 전송합니다. 인증에는 공유 토큰이 사용됩니다. 이 방법을 선택하는 경우 mail_room 프로세스가 API 엔드포인트에 액세스할 수 있도록 하고 공유 토큰을 모든 애플리케이션 노드에 분배하세요.

incoming_email

gitlab_rails['incoming_email_delivery_method'] = "webhook"
      
# mail_room이 연락할 수 있는 URL입니다. 내부 URL 또는 IP를 사용할 수도 있지만, mail_room이 해당 주소를 통해 GitLab API에 액세스할 수 있도록하세요.
# "/"로 끝나지 않도록 주의하세요.
gitlab_rails['incoming_email_gitlab_url'] = "https://gitlab.example.com"
      
# 랜덤 토큰이 포함된 공유 비밀 파일입니다. 모든 노드에서 동일하게 만들어야 합니다.
gitlab_rails['incoming_email_secret_file'] = ".gitlab_mailroom_secret"

service_desk_email

gitlab_rails['service_desk_email_delivery_method'] = "webhook"
      
# mail_room이 연락할 수 있는 URL입니다. 내부 URL 또는 IP를 사용할 수도 있지만, mail_room이 해당 주소를 통해 GitLab API에 액세스할 수 있도록하세요.
# "/"로 끝나지 않도록 주의하세요.
gitlab_rails['service_desk_email_gitlab_url'] = "https://gitlab.example.com"
      
# 랜덤 토큰이 포함된 공유 비밀 파일입니다. 모든 노드에서 동일하게 만들어야 합니다.
gitlab_rails['service_desk_email_secret_file'] = ".gitlab_mailroom_secret"

GitLab 16.0에서 폐기되었으며 17.0에서 제거 예정: webhook 설정에 문제가 있는 경우, sidekiq를 사용하여 Redis를 통해 이메일 페이로드를 직접 GitLab Sidekiq에 전달할 수 있습니다.

incoming_email

# Redis 구성을 사용하여 Sidekiq 작업을 직접 추가합니다.
gitlab_rails['incoming_email_delivery_method'] = "sidekiq"

service_desk_email

# Redis 구성을 사용하여 Sidekiq 작업을 직접 추가합니다.
gitlab_rails['service_desk_email_delivery_method'] = "sidekiq"

이메일 수신을 실행하지 않아야 하는 모든 노드에서 mail_room을 비활성화하세요. 예를 들어, /etc/gitlab/gitlab.rb에서:
```
mailroom['enabled'] = false
```
변경 사항이 적용되려면 GitLab을 다시 구성하세요.

단일 이메일 수신 노드 설정

모든 노드를 설정하고 mail_room 프로세스를 비활성화한 후, mail_room을 단일 노드에서 활성화하세요. 이 노드는 주기적으로 incoming_email과 service_desk_email의 메일함을 확인하고 새로운 읽지 않은 이메일을 GitLab으로 이동합니다.

이메일 수신을 추가로 처리하는 기존 노드를 선택합니다.
incoming_email 및 service_desk_email에 대한 전체 구성 및 자격 증명을 추가합니다.
이 노드에서 mail_room을 활성화합니다. 예를 들어, /etc/gitlab/gitlab.rb에서:
```
mailroom['enabled'] = true
```
변경 사항이 적용되려면 이 노드에서 GitLab을 다시 구성하세요.

서비스 데스크 구성

프로젝트의 보안 강화

요청자에게 전송된 이메일 사용자화

감사 이메일

새 코멘트 이메일

인스턴스 수준의 이메일 헤더, 푸터 및 추가 텍스트

서비스 데스크 티켓을 위한 사용자 정의 템플릿 사용

지원 봇 사용자

지원 봇의 표시 이름 변경

외부 참가자가 코멘트를 추가할 때 이슈 재오픈

커스텀 이메일 주소

전제 조건

사용자 정의 이메일 주소 구성

확인

구성 문제 해결

잘못된 자격 증명

잘못된 전달 대상

사용자 정의 이메일 주소 활성화 또는 비활성화

사용자 정의 이메일 구성 변경 또는 제거

사용자 정의 이메일 회신 주소

회사 소유 도메인을 사용하여 Google Workspace 사용

Google Workspace 계정 구성

이메일 전달 구성

사용자 지정 이메일 주소 구성

알려진 문제

추가 서비스 데스크 별칭 이메일 사용

서비스 데스크 별칭 이메일 구성

암호화된 자격 증명 사용

Microsoft Graph

서비스 데스크 별칭 이메일을 구성합니다

다중 노드 환경에서 이메일 수신 구성

Helm 차트(Kubernetes)

Linux 패키지(Omnibus)

모든 노드 설정

단일 이메일 수신 노드 설정

도움말

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

도움받기