배포 키 관리

배포 스크립트를 자동화할 때 서버에서 SSH 키를 관리하는 다양한 방법과 가장 적합한 방법을 알아봅니다.

이 문서의 내용

SSH 에이전트 전달, OAuth 토큰을 사용하는 HTTPS, 배포 키 또는 컴퓨터 사용자를 사용하여 배포 스크립트를 자동화할 때 서버에서 SSH 키를 관리할 수 있습니다.

SSH 에이전트 전달

대부분의 경우, 특히 프로젝트의 시작 부분에서 SSH 에이전트 전달은 가장 빠르고 간단한 사용 방법입니다. 에이전트 전달은 로컬 개발 컴퓨터에서 사용하는 것과 동일한 SSH 키를 사용합니다.

SSH 에이전트 포워딩의 장점

  • 새 키를 생성하거나 추적할 필요가 없습니다.
  • 키 관리가 없습니다. 서버에서 사용자는 로컬에서 수행하는 것과 동일한 권한을 갖습니다.
  • 서버에 저장된 키가 없으므로 서버가 손상된 경우 손상된 키를 찾아 제거할 필요가 없습니다.

SSH 에이전트 포워딩의 단점

  • 배포하려면 사용자가 SSH에 있어야 합니다. 그러지 않으면 자동화된 배포 프로세스를 사용할 수 없습니다.
  • SSH 에이전트 전달은 Windows 사용자에 대해 실행하는 데 문제가 될 수 있습니다.

SSH 에이전트 포워딩 설정

  1. 로컬로 에이전트 전달을 켭니다. 자세한 내용은 SSH 에이전트 전달에 대한 가이드를 참조하세요.
  2. 에이전트 전달을 사용하도록 배포 스크립트를 설정합니다. 예를 들어 bash 스크립트에서 에이전트 전달을 사용하도록 설정하려면 다음과 같이 입력합니다. ssh -A serverA 'bash -s' < deploy.sh

OAuth 토큰을 사용하는 HTTPS 복제

SSH 키를 사용하지 않으려면 OAuth 토큰을 사용하는 HTTPS를 사용할 수 있습니다.

OAuth 토큰을 사용하는 HTTPS 복제의 장점

  • 서버에 액세스할 수 있는 모든 사용자는 리포지토리를 배포할 수 있습니다.

  • 사용자는 로컬 SSH 설정을 변경할 필요가 없습니다.

  • 여러 토큰이 필요하지 않습니다(각 사용자에 대해 하나씩만 필요함). 서버당 하나의 토큰으로 충분합니다.

  • 토큰은 언제든지 해지하여 기본적으로 일회용 암호로 전환할 수 있습니다.

  • OAuth API를 사용하여 새 토큰 생성을 쉽게 스크립팅할 수 있습니다.

OAuth 토큰을 사용하는 HTTPS 복제의 단점

  • 올바른 액세스 범위로 토큰을 구성했는지 확인해야 합니다.
  • 토큰은 기본적으로 암호이며 동일한 방식으로 보호되어야 합니다.

OAuth 토큰을 사용하는 HTTPS 복제 설정

personal access token을(를) 만드는 방법에 대한 가이드를 참조하세요.

배포 키

배포 키를 사용하여 서버에 대한 GitHub Enterprise Server 인스턴스 리포지토리에서 프로젝트를 시작할 수 있습니다. 이것은 단일 리포지토리에 대한 액세스 권한을 부여하는 SSH 키입니다. GitHub Enterprise Server는 키의 퍼블릭 부분을 개인 계정 대신 리포지토리에 직접 연결하고 키의 프라이빗 부분은 서버에 남아 있습니다. 자세한 내용은 "배포 제공"을(를) 참조하세요.

쓰기 권한이 있는 키 배포는 관리자 액세스 권한이 있는 조직 멤버 또는 개인 리포지토리의 협력자와 동일한 작업을 수행할 수 있습니다. 자세한 내용은 "조직의 리포지토리 역할" 및 "개인 계정 리포지토리에 대한 권한 수준"을(를) 참조하세요.

리포지토리 액세스 및 권한에 대한 향상된 보안 및 세분화된 제어를 위해 GitHub 앱을 대신 사용하는 것이 좋습니다. GitHub 앱을 빌드할 시기 결정하기을(를) 참조하세요.

배포 키의 장점

  • 리포지토리 및 서버에 액세스할 수 있는 모든 사용자가 프로젝트를 배포할 수 있습니다.
  • 사용자는 로컬 SSH 설정을 변경할 필요가 없습니다.
  • 배포 키는 기본적으로 읽기 전용이지만 리포지토리에 추가할 때 쓰기 권한을 부여할 수 있습니다.

배포 키의 단점

  • 배포 키는 단일 리포지토리에 대한 액세스 권한만 부여합니다. 더 복잡한 프로젝트에는 동일한 서버로 풀할 리포지토리가 많을 수 있습니다.
  • 배포 키는 일반적으로 암호로 보호되지 않으므로 서버가 손상된 경우 키에 쉽게 액세스할 수 있습니다.
  • 배포 키는 만료 날짜가 없는 자격 증명입니다.
  • 배포 키는 조직 멤버 자격에 직접 연결되지 않습니다. 배포 키를 만든 사용자가 리포지토리에서 제거되는 경우, 배포 키는 특정 사용자에 연결되지 않고 리포지토리에 연결되므로 계속 활성화됩니다.

배포 키 설정

  1. 서버에서 ssh-keygen 프로시저를 실행하고 생성된 퍼블릭 및 프라이빗 rsa 키 쌍을 저장하는 위치를 기억합니다.

  2. GitHub에서 리포지토리의 기본 페이지로 이동합니다.

  3. 리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

    탭을 보여 주는 리포지토리 헤더의 스크린샷. "설정" 탭이 진한 주황색 윤곽선으로 강조 표시됩니다.

  4. 왼쪽 사이드바에서 배포 키를 선택합니다.

  5. 배포 키 추가를 선택합니다.

  6. "제목" 필드에서 제목을 입력합니다.

  7. 공개 키를 "키" 필드에 붙여 넣습니다.

  8. 이 키가 리포지토리에 대한 쓰기 액세스 권한을 갖도록 하려면 쓰기 액세스 허용을 선택합니다. 쓰기 액세스 권한이 있는 배포 키를 사용하면 배포가 리포지토리로 푸시됩니다.

  9. 키 추가를 클릭합니다.

REST API를 사용하여 배포 키를 만들 수도 있습니다. 자세한 내용은 배포 키에 대한 REST API 엔드포인트을(를) 참조하세요.

서버 하나에서 여러 리포지토리 사용

한 서버에서 여러 리포지토리를 사용하는 경우 각 서버에 대해 전용 키 쌍을 생성해야 합니다. 여러 리포지토리에 대해 배포 키 하나를 다시 사용할 수 없습니다.

서버의 SSH 구성 파일(일반적으로 ~/.ssh/config)에서 각 리포지토리에 대한 별칭 항목을 추가합니다. 예시:

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key
  • Host my-GHE-hostname.com-repo-0 - 리포지토리의 별칭
  • Hostname my-GHE-hostname.com - 별칭과 함께 사용할 호스트 이름을 구성합니다.
  • IdentityFile=/home/user/.ssh/repo-0_deploy_key - 별칭에 프라이빗 키를 할당합니다.

그런 다음 호스트 이름의 별칭을 사용하여 해당 별칭에 할당된 고유 배포 키를 사용하는 SSH를 사용하여 리포지토리와 상호 작용할 수 있습니다. 예시:

git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

GitHub App 설치 액세스 토큰

서버가 하나 이상의 조직에서 리포지토리에 액세스해야 하는 경우, GitHub App을(를) 사용하여 필요한 액세스를 정의한 다음, 해당 GitHub App에서 _엄격한 범위_의 설치 액세스 토큰을 생성할 수 있습니다. 설치 액세스 토큰은 범위를 단일 또는 여러 리포지토리로 지정할 수 있으며, 세분화된 권한을 가질 수 있습니다. 예를 들어 리포지토리의 콘텐츠에 대한 읽기 전용 액세스 권한을 가진 토큰을 생성할 수 있습니다.

GitHub Apps은(는) GitHub Enterprise Server의 첫 번째 클래스 행위자이므로, 설치 액세스 토큰은 모든 GitHub 사용자와 분리되어 "서비스 토큰"에 필적합니다. 또한 설치 액세스 토큰에는 작업하는 조직의 크기에 따라 크기가 조정되는 전용 트래픽률 제한이 있습니다. 자세한 내용은 GitHub Apps의 속도 제한을 참조하세요.

설치 액세스 토큰의 장점

  • 잘 정의된 권한 집합 및 만료 시간(API를 사용하여 수동으로 해지된 경우 1시간 이하)이 있는, 범위가 엄격하게 지정된 토큰
  • 조직에 따라 증가하는 전용 속도 제한
  • GitHub 사용자 ID에서 분리되므로, 라이선스가 부여된 사용자 수를 소비하지 않습니다.
  • 암호를 부여하지 않으므로 직접 로그인할 수 없음

설치 액세스 토큰의 단점

  • GitHub App을(를) 만들려면 추가 설정이 필요합니다.
  • 설치 액세스 토큰은 1시간 후에 만료되므로, 일반적으로 코드를 사용하여 주문형으로 다시 생성해야 합니다.

설치 액세스 토큰의 설정

  1. GitHub App을(를) 공개로 할지 비공개로 할지 결정합니다. GitHub App이(가) 조직 내의 리포지토리에서만 작동하는 경우, 비공개를 원할 가능성이 높습니다.
  2. GitHub App 앱에 필요한 권한(예: 리포지토리 콘텐츠에 대한 읽기 전용 액세스 권한)을 결정합니다.
  3. 조직의 설정 페이지를 통해 GitHub App을(를) 만듭니다. 자세한 내용은 GitHub App 만들기를 참조하세요.
  4. GitHub App id을(를) 메모해 둡니다.
  5. GitHub App의 프라이빗 키를 생성 및 다운로드하고 안전하게 저장합니다. 자세한 내용은 프라이빗 키 생성을 참조하세요.
  6. 작업이 필요한 리포지토리에 GitHub App을(를) 설치하고, 필요에 따라 조직의 모든 리포지토리에 GitHub App을(를) 설치할 수 있습니다.
  7. GitHub App과(와) 액세스할 수 있는 조직 리포지토리 간의 연결을 나타내는 installation_id을(를) 식별합니다. 각 GitHub App 및 조직 쌍에는 최대 하나의 installation_id이(가) 있습니다. 인증된 앱에 대한 조직 설치 가져오기를 통해 installation_id를 식별할 수 있습니다. 이를 위해서는 JWT를 사용하여 GitHub App(으)로 인증해야 하며, 자세한 내용은 GitHub App(으)로 인증을 참조하세요.
  8. 해당 REST API 엔드포인트를 사용하여 설치 액세스 토큰을 생성하고, 앱에 대한 설치 액세스 토큰을 만듭니다. 이를 위해서는 JWT를 사용하여 GitHub App(으)로 인증해야 하며, 자세한 내용은 GitHub App(으)로 인증 및 설치로 인증을 참조하세요.
  9. 이 설치 액세스 토큰을 사용하여 REST 또는 GraphQL API를 통해 아니면 Git 클라이언트를 통해 리포지토리와 상호 작용합니다.

자세한 내용은 GitHub 앱에 대한 설치 액세스 토큰 생성을(를) 참조하세요.

컴퓨터 사용자

서버가 여러 리포지토리에 액세스해야 하는 경우 GitHub Enterprise Server 인스턴스에서 새 계정을 생성하고 자동화에만 사용할 SSH 키를 연결할 수 있습니다. GitHub Enterprise Server 인스턴스의 이 계정은 사람이 사용하지 않으므로 _컴퓨터 사용자_라고 합니다. 컴퓨터 사용자는 개인 리포지토리에서 협력자로(읽기 및 쓰기 액세스 권한 부여), 조직 리포지토리에서 외부 협력자로(읽기, 쓰기 또는 관리자 액세스 권한 부여) 또는 자동화해야 하는 리포지토리에 대한 액세스 권한이 있는 팀에 추가할 수 있습니다(팀의 사용 권한 부여).

컴퓨터 사용자의 장점

  • 리포지토리 및 서버에 액세스할 수 있는 모든 사용자가 프로젝트를 배포할 수 있습니다.
  • 사람이 아닌 사용자가 로컬 SSH 설정을 변경할 필요가 없습니다.
  • 여러 키가 필요하지 않고 서버당 1개가 적절합니다.

컴퓨터 사용자의 단점

  • 조직만 컴퓨터 사용자를 읽기 전용 액세스로 제한할 수 있습니다. 개인 리포지토리는 항상 공동 협력자에게 읽기/쓰기 권한을 부여합니다.
  • 배포 키와 같은 컴퓨터 사용자 키는 일반적으로 암호로 보호되지 않습니다.

컴퓨터 사용자 설정

  1. 서버에서 ssh-keygen 프로시저를 실행하고 퍼블릭 키를 컴퓨터 사용자 계정에 연결합니다.
  2. 컴퓨터 사용자 계정에 자동화하려는 리포지토리에 대한 액세스 권한을 부여합니다. 조직에서 계정을 협력자, 외부 협력자 또는 팀으로 추가하여 이러한 액세스 권한을 부여할 수 있습니다.

추가 참고 자료