This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
ongoing @igor.drozdov @stanhu devops create 2023-07-28

SSH 인증서

요약

GitLab.com에서 고객은 자체 최상위 그룹(나중에 조직)을 얻습니다. 자체 관리형과 비교하여 조직 전체 설정을 이 수준에서 관리해야 합니다.

현재, SaaS(SSH, HTTPS)에서 제공된 Git 액세스 제어 옵션은 사용자 프로필에 설정된 자격 증명(액세스 토큰, SSH 키)에 의존합니다. 사용자 프로필이 조직의 통제를 벗어나기 때문에 고객은 해당 키가 기밀로 유지되고 만료일이 정책을 준수하는지를 평가할 방법이 없습니다. 또한 키가 유출된 경우 피해 제어를 할 방법이 거의 없으며 고객은 Git 액세스 흐름에 MFA(다중 인증 요소)를 적용할 수 없습니다.

고객은 매일 개발자가 MFA를 통해 내부 시스템에 액세스할 수 있는 임시 SSH 인증서를 요청할 수 있는 프로세스를 갖고 있을 수 있습니다. SaaS에서도 동일한 방식으로 작업할 수 있도록 하려면, GitLab.com SaaS와 공개 Certificate Authority(CA) 파일을 공유할 수 있는 방법이 필요합니다. 이는 Git 액세스 제어를 위한 목적입니다.

동기

  • 사용자가 GitLab.com SaaS와 공개 Certificate Authority(CA) 파일을 공유하여 Git 액세스 제어를 할 수 있도록 합니다.
  • SSH 인증서를 통한 인증을 이미 지원하는 경쟁 제품과 GitLab 간의 제품 갭을 메웁니다.

목표

본 문서는 다음 요구 사항을 충족하기 위한 기능을 구현하기 위한 아키텍처 디자인을 제안합니다:

  • 인증서 발급에 사용되는 CA 파일의 공개 키(CA.pub)를 그룹에 추가할 수 있습니다.
  • CA에 의해 발급된 인증서를 사용하여 해당 그룹 및 해당 조상의 프로젝트에 대한 Git 액세스를 얻을 수 있습니다.
  • 인증서를 사용하여 해당 그룹과 해당 조상 외부 프로젝트에 대한 Git 액세스를 얻을 수 없습니다.

비목표

본 문서는 SSH 인증서를 통한 인증을 지원하기 위한 핵심 기능을 제공하는 데 초점을 맞춥니다. 잠재적인 개선 사항은 추후 작업에 설명되어 있습니다.

제안

최소 기능 제품(MVC)

그룹 관리자는 인증서 파일(ssh-keygen -f CA 사용)로 사용될 SSH 키 쌍을 생성합니다.:

  • 비공개 키는 사용자 인증서를 발급하는 데 사용됩니다.
  • 공개 키는 사용자 인증서를 통해 해당 그룹에 액세스를 부여하기 위해 그룹에 추가됩니다.

사용자 인증서

그룹 관리자는 CA 비공개 키를 사용하여 사용자 인증서를 발급하고 GitLab 사용자 이름 또는 사용자의 주 이메일을 키 식별으로 지정합니다:

ssh-keygen -s CA -I user@example.com -V +1d user-key.pub

결과적으로 다음 구조의 사용자 인증서가 생성됩니다:

ssh-keygen -L -f ssh_host_ed25519_key-cert.pub

ssh_host_ed25519_key-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:dRVV49XJHt85X1seqr9xXyxyuuGTbtFV6Lbwlrx6BIQ
        Signing CA: RSA SHA256:UAcgUeGoXrs8WOT/N+bmqY2vB9145Mc5NaN1Y977NCI (using rsa-sha2-512)
        Key ID: "user@example.com"
        Serial: 1
        Valid: from 2023-07-31T18:20:00 to 2023-08-01T18:21:34
        Principals: (none)
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc
  • Type은 사용자 인증서의 유형입니다. GitLab Shell에서는 사용자 인증서만 허용되며 다른 유형은 모두 거부됩니다.
  • Public Key는 사용자의 공개 키입니다.
  • Signing CACA의 공개 키입니다. 해당 지문은 사용자 인증서와 관련된 그룹을 찾는 데 사용됩니다.
  • Key ID는 사용자 이름 또는 주 이메일입니다. GitLab 사용자와 사용자 인증서를 연결하는 데 사용됩니다.
  • Serial은 사용자 인증서의 일련 번호입니다. 동일한 CA에 의해 생성된 다른 인증서와 구분하는 데 사용될 수 있습니다.
  • Valid는 유효 기간을 나타냅니다. 이 값은 GitLab Shell에 의해 유효성이 검증됩니다: 만료된 인증서와 유효하지 않은 인증서는 거부됩니다.
  • Principals, Critical OptionsExtensions은 사용자 인증서에 추가 정보를 삽입하는 데 사용됩니다. 이러한 필드는 잠재적으로 추가 제한을 적용하기 위해 나중에 사용될 수 있습니다.

애플리케이션 동작

GitLab Shell은 SSH를 통해 보내진 명령을 처리하는 프로젝트입니다. 사용자가 공개 키를 사용하여 SSH 연결을 설정하고 인증을 시도하면 GitLab Shell은 내부 API 요청을 보내어 /authorized_keys 엔드포인트에 키가 GitLab 사용자와 연관되어 있는지 여부를 감지합니다. 인증서가 사용된 경우, GitLab Shell은 이를 인식하고 대신에 /authorized_certs로 요청을 수행할 수 있습니다.

  1. 그룹 관리자는 CA.pub 파일을 그룹에 추가합니다.
  2. 사용자는 CA로 서명된 인증서를 사용하여 인증을 시도합니다.
  3. GitLab Shell은 /authorized_certsCA의 지문과 사용자 식별 정보(깃랩 사용자 이름 또는 주 이메일)을 보냅니다.
  4. GitLab Rails은CA.pub의 지문이 추가된 그룹과 사용자를 찾습니다. 지문을 통해 CA와 그룹 간의 일대일 관계를 정의합니다.
  5. GitLab Shell은 설정된 연결에 대한 네임스페이스 전체 경로를 기억합니다.
  6. GitLab Shell은 특정 프로젝트에 대한 사용자 액세스가 필요할 때마다 /allowed 엔드포인트로 요청을 보냅니다. 네임스페이스 전체 경로가 /allowed 엔드포인트에 전달됩니다.
  7. GitLab Rails은 사용자가 해당 프로젝트에 대한 액세스 권한이 있는지 여부를 확인하기 위해 네임스페이스가 프로젝트의 네임스페이스 또는 해당 조상과 일치하는지 확인합니다.
  8. 위의 모든 확인이 성공하면 사용자는 프로젝트에 액세스할 수 있습니다.
sequenceDiagram User->>+GitLab Shell: SSH 인증서를 사용하여 인증 GitLab Shell->>+GitLab Rails: /authorized_certs?key=서명 키의 지문&사용자_식별_정보=사용자이름 또는 주 이메일 GitLab Rails-->>-GitLab Shell: CA를 구성하고 사용자 이름이 포함된 네임스페이스로 응답 GitLab Shell-->>User: 성공적으로 인증됨 User->>+GitLab Shell: 특정 프로젝트에 대한 Git 명령 GitLab Shell->>+GitLab Rails: /allowed [namespace=네임스페이스] GitLab Rails-->>-GitLab Shell: 해당 사용자가 이 네임스페이스에서 프로젝트에 액세스할 수 있음을 응답 GitLab Shell-->>User: 성공

예제

  1. CA.pub를 구성하는 그룹 외부 프로젝트에 액세스합니다.

    다음과 같은 그룹 계층 구조가 있는 경우

    a/b/c/d/e/f
        |
        └/g/h/i
    
    • 그룹 관리자가 dCA.pub를 추가하고 사용자가 CA로 서명된 인증서를 사용하여 인증됩니다.
    • 사용자가 a/b/c/d/e/f/project를 복제할 때, 우리는 a/b/c/d/e/project 프로젝트 전체 경로와 a/b/c/d 네임스페이스 전체 경로를 보내줍니다. : 사용자는 d가 프로젝트의 네임스페이스의 상위 항목이기 때문에 프로젝트를 복제할 수 있습니다.
    • 사용자가 a/b/c/g/h/i/project를 복제할 때, 사용자는 프로젝트를 복제할 수 없습니다. 왜냐하면 d가 상위 항목 목록에 포함되어 있지 않기 때문입니다.
  2. CA.pub를 구성하는 그룹은 다른 네임스페이스로 이전됩니다.

기존 인증서는 여전히 유효합니다. 왜냐하면 전체 네임스페이스 경로가 연결 당 저장되기 때문입니다. 사용자가 다시 연결할 때 /authorized_certs로 다른 요청이 전송되고 새로운 전체 네임스페이스 경로가 반환됩니다.

오픈 질문

여러 SSH 인증서를 사용하여 다른 프로젝트에 접근하기

사용자는 다른 프로젝트에 접근하기 위해 다른 SSH 인증서를 가질 수 있습니다. 사용자가 SSH 연결을 설정할 때, SSH 클라이언트는 성공적으로 인증하는 옵션 목록을 반복합니다. 현재 아키텍처에서는 하나의 네임스페이스에 액세스 권한을 부여하는 첫 번째 인증서가 허용됩니다. 심지어 사용자가 다른 프로젝트에 액세스해야 할 때라도 말이죠.

예를 들어:

  1. 사용자는 ab 그룹에 대한 유효한 인증서를 가지고 있습니다.
  2. 사용자는 a를 사용하여 성공적으로 인증됩니다.
  3. 사용자는 b/project를 클론하려고 시도하였으나 실패합니다.

이 시나리오에 대한 해결책은 SSH 연결 중 Git이 특정 인증서를 사용하도록 구성하는 것입니다. 다음을 .gitconfig 파일에 추가하십시오:

[core]
    sshCommand = ssh git@gitlab.com -i cert.pub

단일 인증서는 취소할 수 없습니다

단일 사용자 인증서의 취소는 이 MVP의 범위를 벗어납니다. 이 기능을 구현하는 것은 가능하지만 실현 가능성을 논의해야 합니다.

이를 지원하는 것은 구현 및 UI/UX를 복잡하게 만들 것입니다. 하지만, 유출된 인증서의 위험은 다음과 같은 조치로 크게 줄일 수 있습니다:

  • 사용자 인증서의 만료일. 문서에서 강력히 권장해야 합니다.
  • 현재 사용자 인증서를 폐기하는 CA의 로테이션.
  • 사용자 인증서의 사용을 제한할 수 있는 source-address 기능의 구현.

인증서는 여러 GitLab 인스턴스에서 사용될 수 있습니다

GitLab 인스턴스 정보는 사용자 인증서에 포함되지 않습니다. 사용자가 그 인스턴스에서 KeyId 값을 인식하는 한, 여러 GitLab 인스턴스에서 사용할 수 있음을 의미합니다.

가능한 해결책:

  • Extensions를 사용하여 특정 인스턴스에 사용자 인증서의 사용을 제한하는 선택적 필드를 후속작업으로 구현할 수 있습니다. extension:login@gitlab.com=username을 지정하는 것이 더 안전하고 유연한 옵션입니다. 두 가지 모두 지원할 수 있겠지만요.

CA는 여러 그룹에서 재사용할 수 없습니다

CA.pub 지문은 고유해야 하며 여러 그룹에서 재사용될 수 없습니다. 1:1 관계가 선택된 것은 사용자가 액세스할 수 있는 단일 그룹을 찾을 수 있도록 하기 위함입니다.

다른 옵션은 Extensions 또는 Critical Options를 사용하여 네임스페이스를 사용자 인증서에 내장하는 것입니다.

장점:

  • CA는 여러 그룹에서 재사용될 수 있습니다.
  • 사용자 인증서는 액세스할 그룹을 묻는 대신 어느 그룹에 액세스해야 하는지 알려줍니다.

단점:

  • 사용자 인증서 형식에 대한 사용자 정의 요구가 필요합니다.
  • 다른 그룹이 CA.pub를 추가하는 경우 사용자는 의도치 않게 해당 그룹에 액세스할 수 있습니다.

가능한 해결책:

  • Extensions 또는 후속작업에서 Critical Options을 사용하여 사용자 인증서의 사용을 특정 그룹으로 제한하는 선택적 필드를 구현할 수 있습니다. CA는 여전히 재사용할 수 없지만 사용자 인증서는 다른 그룹에 사용될 수 없습니다.

반복 계획

구성요소 마일스톤 그룹 변경 사항
GitLab Shell 16.3 소스 코드 GitLab Shell에서 SSH 인증서를 사용한 인증 구현
GitLab Rails 16.4 소스 코드 내부 GitLab Rails API 엔드포인트 authorized_certs를 구현하여 CA.pub를 구성하는 그룹을 찾는다.
GitLab Rails 16.4 소스 코드 그룹이 CA.pub를 추가/제거할 수 있는 GitLab Rails API 엔드포인트를 구현한다.
GitLab Rails 다음 2-3개 마일스톤 인증 및 권한 부여 그룹 설정 UX를 구현하여 CA.pub를 추가/제거하는 옵션을 구현한다.
GitLab Rails 다음 2-3개 마일스톤 인증 및 권한 부여 SSH 인증서만 사용하도록 강제하는 옵션과 개인 SSH 키 및 접근 토큰을 금지하는 옵션을 구현한다.

후속 조치

이 청사진의 범위를 벗어나지만 해당 주제와 관련된 기능은 다음과 같습니다.

  • 인스턴스 또는 그룹의 Git을 HTTPS로 비활성화하여 SSH 인증서만 사용하도록 강제하는 것: 필수 기능.
  • 그룹 수준 SSH 키만 사용하도록 강제하여 개인 SSH 키의 사용을 금지하는 것: 필수 기능.
  • 사용자 인증서의 사용을 일련의 IP 주소로 제한하는 source-address Critical Option 지정: 선호 기능.
  • 사용자 인증서의 사용을 일련의 인스턴스로 제한하는 login@hostname=username Extensions 지정: 선호 기능.
  • SSH 인증서를 사용하여 커밋에 서명하는 것: 선호 기능.
  • 단일 사용자 인증서를 취소하는 것. 이 기능은 복잡한 UI/UX를 필요로 하며, 다른 기능을 사용하여 리스크를 크게 줄일 수 있습니다.