배포 키 관리

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

SSH 에이전트 전달

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

장점

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

단점

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

설정

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

OAuth 토큰을 사용하는 HTTPS 복제

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

장점

서버에 액세스할 수 있는 모든 사용자는 리포지토리를 배포할 수 있습니다.
사용자는 로컬 SSH 설정을 변경할 필요가 없습니다.
여러 토큰이 필요하지 않습니다(각 사용자에 대해 하나씩만 필요함). 서버당 하나의 토큰으로 충분합니다.
토큰은 언제든지 해지하여 기본적으로 일회용 암호로 전환할 수 있습니다.
OAuth API를 사용하여 새 토큰 생성을 쉽게 스크립팅할 수 있습니다.

단점

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

설정

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

키 배포

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

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

장점

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

단점

배포 키는 단일 리포지토리에 대한 액세스 권한만 부여합니다. 더 복잡한 프로젝트에는 동일한 서버로 풀할 리포지토리가 많을 수 있습니다.
배포 키는 일반적으로 암호로 보호되지 않으므로 서버가 손상된 경우 키에 쉽게 액세스할 수 있습니다.

설정

서버에서 ssh-keygen 프로시저를 실행하고 생성된 퍼블릭 및 프라이빗 rsa 키 쌍을 저장하는 위치를 기억합니다.
GitHub Enterprise Server 페이지 오른쪽 위 모서리에서 프로필 사진을 클릭한 다음 프로필을 클릭합니다.
프로필 페이지에서 리포지토리를 클릭한 다음 리포지토리의 이름을 클릭합니다.
리포지토리에서 설정을 클릭합니다.
사이드바에서 배포 키를 클릭한 다음 배포 키 추가를 클릭합니다.
제목을 입력하고 퍼블릭 키를 붙여 넣습니다.
이 키가 리포지토리에 대한 쓰기 액세스 권한을 갖도록 하려면 쓰기 액세스 허용을 선택합니다. 쓰기 액세스 권한이 있는 배포 키를 사용하면 배포가 리포지토리로 푸시됩니다.
키 추가를 클릭합니다.

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

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

서버의 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 서버 간 토큰

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

GitHub 앱은 GitHub Enterprise Server에서 첫 번째 클래스 작업자이므로 서버 간 토큰은 모든 GitHub 사용자와 분리되어 “서비스 토큰”과 비슷합니다. 또한 서버-서버 토큰에는 작업하는 조직의 크기에 따라 크기가 스케일링되는 전용 속도 제한이 있습니다. 자세한 내용은 GitHub Apps의 속도 제한을 참조하세요.

장점

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

단점

GitHub 앱을 만들려면 추가 설정이 필요함
서버-서버 토큰은 1시간 후에 만료되므로 일반적으로 코드를 사용하여 주문형으로 다시 생성해야 함

설정

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

컴퓨터 사용자

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

장점

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

단점

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

설정

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

추가 참고 자료

알림 구성