personal-access-tokens

2 개의 포스트

github

초보자를 위한 GitHub: 자주 묻는 질문에 대한 답변 (새 탭에서 열림)

이 글은 GitHub 초보자가 자주 묻는 SSH 키와 Personal Access Token(PAT)의 개념, 생성 방법, 보안상 주의점을 설명한다. SSH는 컴퓨터의 개인 키와 GitHub에 등록한 공개 키를 이용해 인증하며, PAT는 명령줄이나 API 접근에 사용하는 권한 기반 자격 증명이다. 글의 후반부에서는 병합과 리베이스 차이도 다룰 예정이지만, 제공된 내용은 해당 질문의 제목에서 끝난다. ## SSH 키의 개념과 역할 - SSH 키는 다음 두 파일로 구성된 키 쌍이다. - **개인 키(private key)**: 컴퓨터에 보관하며 절대 공유하지 않는다. - **공개 키(public key)**: GitHub 등에 등록해도 된다. - GitHub는 등록된 공개 키와 사용자의 컴퓨터에 있는 개인 키가 일치하는지 확인해 인증한다. - SSH를 설정하면 GitHub에 코드를 push하거나 pull할 때 비밀번호를 반복해서 입력하지 않아도 된다. ## SSH 키 생성 및 ssh-agent 등록 - 터미널에서 Ed25519 방식의 키를 생성한다. ```bash ssh-keygen -t ed25519 -C YOUR_EMAIL@DOMAIN.COM ``` - 저장 경로를 물으면 기본 경로를 사용하기 위해 Enter를 누른다. - 개인 키를 보호할 passphrase를 설정한다. - `ssh-agent`는 개인 키를 안전하게 보관해 매번 passphrase를 입력하지 않도록 돕는다. - 생성한 키를 agent에 추가한다. ```bash ssh-add ~/.ssh/id_ed25519 ``` ## 공개 키를 GitHub에 등록하기 - 공개 키 내용을 확인한다. ```bash cat ~/.ssh/id_ed25519.pub ``` - 출력된 한 줄 전체를 복사한다. - GitHub에서 다음 순서로 등록한다. - 프로필 사진 → **Settings** - 왼쪽 메뉴의 **SSH and GPG keys** - **New SSH key** - 기기를 식별할 수 있는 제목 입력 - 복사한 공개 키 붙여넣기 - **Add SSH key** 클릭 - 개인 키는 GitHub에 업로드하지 않고 로컬 컴퓨터에만 보관해야 한다. ## Personal Access Token(PAT)의 용도 - PAT는 GitHub 도구, 명령줄, GitHub API에서 사용하는 별도의 인증 자격 증명이다. - 토큰마다 접근 가능한 저장소와 권한을 지정할 수 있다. - 필요할 때 폐기(revoke)할 수 있으며, 만료일도 설정할 수 있다. - PAT는 생성 직후 한 번만 표시되므로 비밀번호 관리자 등 안전한 장소에 즉시 저장해야 한다. - 터미널에서 GitHub 비밀번호를 요구할 때 비밀번호 대신 PAT를 사용할 수 있다. ## Fine-grained PAT 생성 - GitHub의 **Settings → Developer settings → Personal access tokens → Fine-grained tokens**로 이동한다. - 토큰 이름과 용도를 설명하는 설명을 입력한다. - 만료일을 지정한다. - 토큰이 접근할 저장소를 전체 또는 특정 저장소로 제한한다. - 필요한 권한을 추가하고 각 권한을 읽기 전용 또는 읽기·쓰기 모드로 설정한다. - 생성 전 설정을 검토한 뒤 토큰을 생성한다. - 권한 범위를 좁게 설정하면 토큰이 유출되었을 때의 피해를 줄일 수 있다. ## Classic PAT 생성 - **Settings → Developer settings → Personal access tokens → Tokens (classic)**으로 이동한다. - **Generate new token (classic)**을 선택한다. - 토큰 이름과 만료일을 지정한다. - 필요한 scope를 선택한다. - 토큰을 생성한 뒤 표시되는 값을 안전하게 복사한다. - Classic 토큰은 권한 범위가 더 포괄적일 수 있으므로, 가능한 경우 필요한 저장소와 권한을 세밀하게 제한할 수 있는 fine-grained 토큰을 우선 고려하는 것이 좋다. ## 실용적인 보안 권장 사항 - SSH 개인 키와 PAT를 다른 사람에게 공유하지 않는다. - PAT에는 필요한 저장소와 최소 권한만 부여한다. - 토큰에는 만료일을 설정하고 더 이상 사용하지 않으면 폐기한다. - PAT는 비밀번호나 소스 코드에 직접 기록하지 말고 비밀번호 관리자나 안전한 시크릿 저장소에 보관한다. - 제공된 글에는 병합(merge)과 리베이스(rebase) 설명이 이어질 예정이지만, 해당 내용은 포함되어 있지 않다.

gitlab

유출된 개인 액세스 토큰 하나로 소유자가 접근할 수 있는 모든 프로젝트가 노출되어서는 안 됩니다. 세분화된 PAT는 각 토큰의 권한을 해당 작업에 맞게 제한합니다. (새 탭에서 열림)

GitLab은 개인 액세스 토큰(PAT)을 작업별·리소스별로 제한하는 세분화된 PAT를 베타로 공개했습니다. 토큰이 특정 프로젝트의 특정 리소스에서 필요한 작업만 수행하도록 설정해, 유출 시 피해 범위를 전체 계정이 아닌 해당 작업과 프로젝트로 줄이는 것이 핵심입니다. 다만 현재 REST API의 약 75%만 지원하므로 정식 출시 전까지는 운영 환경 사용을 권장하지 않습니다. ## 광범위한 PAT의 보안 위험 - `api`나 `read_api`처럼 넓은 범위의 스코프는 사용자가 접근 가능한 여러 프로젝트와 그룹에 권한을 부여합니다. - 하나의 토큰으로 소스 코드 조회, 파이프라인 수정, 컨테이너 레지스트리 접근, CI/CD 변수 복호화 등을 모두 수행할 수 있습니다. - 토큰이 유출되면 공격자가 해당 사용자가 접근 가능한 전체 프로젝트를 악용할 수 있습니다. - 토큰의 권한이 특정 작업이 아니라 사용자 계정에 묶여 있어 피해 범위가 커집니다. ## 작업별 최소 권한 부여 - 세분화된 PAT는 자동화 작업마다 별도의 토큰을 발급하는 방식입니다. - 토큰이 접근할 수 있는 범위를 다음처럼 지정할 수 있습니다. - 개인 프로젝트만 - 사용자가 속한 모든 프로젝트와 그룹 - 선택한 특정 프로젝트와 그룹 - 접근 가능한 리소스별로 권한을 독립 설정할 수 있습니다. - Issues - Merge Requests - Pipelines - Repositories - Container Registry 등 - 각 리소스에 대해 `Create`, `Read`, `Update`, `Delete` 권한을 개별적으로 부여합니다. ## 컨테이너 레지스트리 활용 예시 - 컨테이너 이미지를 빌드하고 업로드하는 파이프라인에는 전체 `api` 토큰 대신 특정 프로젝트의 Container Registry용 토큰을 발급합니다. - 해당 토큰에는 필요한 `Create`와 `Read` 권한만 부여할 수 있습니다. - 토큰이 유출되어도 피해 범위는 전체 프로젝트나 계정이 아닌 해당 프로젝트의 컨테이너 레지스트리로 제한됩니다. ## 토큰 감사와 추가 보호 장치 - 토큰 목록 화면에서 기존 PAT와 세분화된 PAT의 전체 스코프 및 리소스별 권한을 확인할 수 있습니다. - 과도한 권한을 가진 토큰을 보안 검토 중 쉽게 식별할 수 있습니다. - 토큰 만료 기간 제한과 자동 폐기 기능을 함께 사용하면 도난된 토큰의 악용 시간을 줄일 수 있습니다. - 작업별 토큰을 사용하면 유출 이후 조사와 대응 범위도 해당 작업과 프로젝트로 좁힐 수 있습니다. ## 베타 단계의 지원 범위와 제한 - 세분화된 PAT는 현재 REST API 엔드포인트의 약 75%를 지원합니다. - 향후 나머지 REST API와 GraphQL 지원 범위를 확대할 예정입니다. - 정식 출시 전까지는 프로덕션 워크로드에 사용하지 않는 것이 권장됩니다. - 베타 기간에는 기존 PAT와 세분화된 PAT를 동시에 생성해 호환성과 권한 모델을 평가할 수 있습니다. ## 생성 방법 - **User Settings → Personal Access Tokens**로 이동합니다. - **Generate token** 메뉴에서 **Fine-grained token**을 선택합니다. - 접근 가능한 프로젝트·그룹과 리소스별 권한을 설정합니다. - 지원 리소스와 관리자 제어 항목은 GitLab의 세분화된 PAT 문서에서 확인할 수 있습니다. 실무에서는 자동화 작업마다 별도 토큰을 만들고, 특정 프로젝트와 필요한 리소스의 최소 권한만 부여하는 방식이 권장됩니다. 베타 기간에는 프로덕션 적용을 피하고, 먼저 테스트 환경에서 기존 PAT와의 호환성 및 API 지원 범위를 검증하는 것이 안전합니다.