기본 Github 정보

Reading time: 13 minutes

기본 구조

대규모 회사의 기본 github 환경 구조는 여러 조직을 소유하는 엔터프라이즈를 소유하는 것입니다. 각 조직은 여러 리포지토리와 여러 팀을 포함할 수 있습니다. 소규모 회사는 하나의 조직만 소유하고 엔터프라이즈는 소유하지 않을 수 있습니다.

사용자 관점에서 사용자는 다양한 엔터프라이즈 및 조직의 구성원이 될 수 있습니다. 그들 안에서 사용자는 다양한 엔터프라이즈, 조직 및 리포지토리 역할을 가질 수 있습니다.

또한 사용자는 다양한 팀의 일원이 될 수 있으며, 각 팀에서 다른 엔터프라이즈, 조직 또는 리포지토리 역할을 가질 수 있습니다.

마지막으로 리포지토리는 특별한 보호 메커니즘을 가질 수 있습니다.

권한

엔터프라이즈 역할

• 엔터프라이즈 소유자: 이 역할을 가진 사람들은 관리자를 관리하고, 엔터프라이즈 내의 조직을 관리하며, 엔터프라이즈 설정을 관리하고, 조직 전반에 정책을 시행할 수 있습니다. 그러나 그들은 조직 설정이나 콘텐츠에 접근할 수 없습니다. 조직 소유자로 지정되거나 조직 소유 리포지토리에 직접 접근 권한이 부여되지 않는 한 접근할 수 없습니다.
• 엔터프라이즈 구성원: 귀하의 엔터프라이즈가 소유한 조직의 구성원은 자동으로 엔터프라이즈의 구성원이 됩니다.

조직 역할

조직 내에서 사용자는 다양한 역할을 가질 수 있습니다:

• 조직 소유자: 조직 소유자는 조직에 대한 완전한 관리 접근 권한을 가집니다. 이 역할은 제한되어야 하며, 조직 내에서 두 명 이상이어야 합니다.
• 조직 구성원: 조직 내 사람들의 기본 비관리 역할은 조직 구성원입니다. 기본적으로 조직 구성원은 일정한 권한을 가집니다.
• 청구 관리자: 청구 관리자는 조직의 청구 설정을 관리할 수 있는 사용자입니다. 예를 들어, 결제 정보와 같은 설정을 관리합니다.
• 보안 관리자: 조직 소유자가 조직 내의 모든 팀에 부여할 수 있는 역할입니다. 적용되면 팀의 모든 구성원에게 조직 전반의 보안 경고 및 설정을 관리할 수 있는 권한과 모든 리포지토리에 대한 읽기 권한이 부여됩니다.
• 조직에 보안 팀이 있는 경우, 보안 관리자 역할을 사용하여 팀 구성원에게 조직에 필요한 최소한의 접근 권한을 부여할 수 있습니다.
• Github 앱 관리자: 조직이 소유한 GitHub 앱을 관리할 수 있도록 추가 사용자에게 GitHub 앱 관리자 권한을 부여할 수 있습니다.
• 외부 협력자: 외부 협력자는 하나 이상의 조직 리포지토리에 접근할 수 있지만 조직의 명시적인 구성원은 아닌 사람입니다.

이 역할의 권한을 비교할 수 있는 표는 다음에서 확인할 수 있습니다: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

구성원 권한

_https://github.com/organizations/<org_name>/settings/member_privileges_에서 조직의 구성원으로서 사용자가 가지는 권한을 확인할 수 있습니다.

여기에서 구성된 설정은 조직 구성원의 다음 권한을 나타냅니다:

• 모든 조직 리포지토리에 대한 관리자, 작성자, 독자 또는 권한 없음.
• 구성원이 개인, 내부 또는 공개 리포지토리를 생성할 수 있는지 여부.
• 리포지토리 포크가 가능한지 여부.
• 외부 협력자를 초대할 수 있는지 여부.
• 공개 또는 비공식 사이트를 게시할 수 있는지 여부.
• 관리자가 리포지토리에 대해 가지는 권한.
• 구성원이 새로운 팀을 생성할 수 있는지 여부.

리포지토리 역할

기본적으로 리포지토리 역할이 생성됩니다:

• 읽기: 코드 기여자가 아닌 사람들이 프로젝트를 보고 논의하기 위해 추천됩니다.
• 분류: 문제 및 풀 리퀘스트를 능동적으로 관리해야 하는 기여자에게 추천됩니다. 쓰기 접근 권한은 없습니다.
• 쓰기: 프로젝트에 적극적으로 푸시하는 기여자에게 추천됩니다.
• 유지 관리: 리포지토리를 관리해야 하는 프로젝트 관리자에게 추천됩니다. 민감하거나 파괴적인 작업에 대한 접근 권한은 없습니다.
• 관리자: 프로젝트에 대한 완전한 접근 권한이 필요한 사람에게 추천됩니다. 여기에는 보안 관리 또는 리포지토리 삭제와 같은 민감하고 파괴적인 작업이 포함됩니다.

각 역할의 권한을 비교할 수 있는 표는 다음에서 확인할 수 있습니다: https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

또한 _https://github.com/organizations/<org_name>/settings/roles_에서 자신만의 역할을 생성할 수 있습니다.

팀

_https://github.com/orgs/<org_name>/teams_에서 조직 내에서 생성된 팀을 나열할 수 있습니다. 다른 팀의 자식 팀을 보려면 각 부모 팀에 접근해야 합니다.

사용자

조직의 사용자는 _https://github.com/orgs/<org_name>/people_에서 나열할 수 있습니다.

각 사용자의 정보에서 사용자가 속한 팀과 사용자가 접근할 수 있는 리포지토리를 확인할 수 있습니다.

Github 인증

Github는 계정에 인증하고 귀하를 대신하여 작업을 수행하는 다양한 방법을 제공합니다.

웹 접근

github.com에 접근하여 사용자 이름과 비밀번호(및 2FA를 사용할 수 있음)를 사용하여 로그인할 수 있습니다.

SSH 키

하나 이상의 공개 키로 계정을 구성하여 관련 개인 키가 귀하를 대신하여 작업을 수행할 수 있도록 할 수 있습니다. https://github.com/settings/keys

GPG 키

이 키로 사용자를 가장할 수는 없지만 사용하지 않으면 서명 없는 커밋을 보내는 것으로 인해 발견될 수 있습니다. 여기에서 경계 모드에 대해 더 알아보세요.

개인 접근 토큰

응용 프로그램이 귀하의 계정에 접근할 수 있도록 개인 접근 토큰을 생성할 수 있습니다. 개인 접근 토큰을 생성할 때 사용자는 토큰이 가질 권한을 지정해야 합니다. https://github.com/settings/tokens

Oauth 애플리케이션

Oauth 애플리케이션은 귀하의 github 정보의 일부에 접근하거나 귀하를 가장하여 일부 작업을 수행할 수 있는 권한을 요청할 수 있습니다. 이 기능의 일반적인 예는 일부 플랫폼에서 찾을 수 있는 github로 로그인 버튼입니다.

• https://github.com/settings/developers에서 자신의 Oauth 애플리케이션을 생성할 수 있습니다.
• https://github.com/settings/applications에서 귀하의 계정에 접근할 수 있는 모든 Oauth 애플리케이션을 확인할 수 있습니다.
• https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps에서 Oauth Apps가 요청할 수 있는 범위를 확인할 수 있습니다.
• _https://github.com/organizations/<org_name>/settings/oauth_application_policy_에서 조직의 애플리케이션에 대한 제3자 접근을 확인할 수 있습니다.

일부 보안 권장 사항:

• OAuth 앱은 항상 모든 GitHub에서 인증된 GitHub 사용자로서 행동해야 합니다(예: 사용자 알림 제공 시) 및 지정된 범위에만 접근해야 합니다.
• OAuth 앱은 인증된 사용자를 위해 "GitHub로 로그인"을 활성화하여 신원 공급자로 사용할 수 있습니다.
• 단일 리포지토리에서 작동하도록 애플리케이션을 구축하지 마십시오. repo OAuth 범위를 사용하면 OAuth 앱이 인증된 사용자의 모든 리포지토리에서 작동할 수 있습니다.
• 팀이나 회사의 애플리케이션으로 작동하도록 OAuth 앱을 구축하지 마십시오. OAuth 앱은 단일 사용자로 인증되므로, 한 사람이 회사를 위해 OAuth 앱을 생성하고 회사를 떠나면 다른 누구도 접근할 수 없습니다.
• 자세한 내용은 여기에서 확인하세요 여기.

Github 애플리케이션

Github 애플리케이션은 귀하의 github 정보에 접근하거나 귀하를 가장하여 특정 리소스에 대해 특정 작업을 수행할 수 있는 권한을 요청할 수 있습니다. Github 앱에서는 앱이 접근할 리포지토리를 지정해야 합니다.

• GitHub 앱을 설치하려면 조직 소유자이거나 리포지토리에서 관리자 권한이 있어야 합니다.
• GitHub 앱은 개인 계정 또는 조직에 연결해야 합니다.
• https://github.com/settings/apps에서 자신의 Github 애플리케이션을 생성할 수 있습니다.
• https://github.com/settings/apps/authorizations에서 귀하의 계정에 접근할 수 있는 모든 Github 애플리케이션을 확인할 수 있습니다.
• Github 애플리케이션을 위한 API 엔드포인트는 https://docs.github.com/en/rest/overview/endpoints-available-for-github-app입니다. 앱의 권한에 따라 일부에 접근할 수 있습니다.
• _https://github.com/organizations/<org_name>/settings/installations_에서 조직에 설치된 앱을 확인할 수 있습니다.

일부 보안 권장 사항:

• GitHub 앱은 사용자와 독립적으로 작업해야 합니다(앱이 사용자-서버 토큰을 사용하는 경우 제외). 사용자-서버 접근 토큰을 더 안전하게 유지하려면 8시간 후 만료되는 접근 토큰과 새 접근 토큰으로 교환할 수 있는 갱신 토큰을 사용할 수 있습니다. 자세한 내용은 "사용자-서버 접근 토큰 갱신"을 참조하세요.
• GitHub 앱이 특정 리포지토리와 통합되도록 하십시오.
• GitHub 앱은 개인 계정 또는 조직에 연결해야 합니다.
• GitHub 앱이 사용자가 할 수 있는 모든 것을 알고 수행할 것이라고 기대하지 마십시오.
• "GitHub로 로그인" 서비스가 필요할 뿐이라면 GitHub 앱을 사용하지 마십시오. 그러나 GitHub 앱은 사용자 식별 흐름을 사용하여 사용자를 로그인시키고 다른 작업을 수행할 수 있습니다.
• GitHub 사용자로서만 작동하고 사용자가 할 수 있는 모든 작업을 수행하려는 경우 GitHub 앱을 구축하지 마십시오.
• GitHub Actions와 함께 앱을 사용하고 워크플로 파일을 수정하려는 경우, workflow 범위를 포함하는 OAuth 토큰을 사용하여 사용자를 대신하여 인증해야 합니다. 사용자는 워크플로 파일이 포함된 리포지토리에 대한 관리자 또는 쓰기 권한이 있어야 합니다. 자세한 내용은 "OAuth 앱의 범위 이해하기"를 참조하세요.
• 자세한 내용은 여기에서 확인하세요 여기.

Github Actions

이것은 github에서 인증하는 방법이 아니지만, 악의적인 Github Action이 github에 무단 접근을 할 수 있으며, **Action에 부여된 권한에 따라 여러 다양한 공격이 발생할 수 있습니다. 아래에서 더 많은 정보를 확인하세요.

Git Actions

Git actions는 이벤트가 발생할 때 코드를 자동으로 실행할 수 있게 해줍니다. 일반적으로 실행되는 코드는 리포지토리의 코드와 관련이 있습니다(예: 도커 컨테이너를 빌드하거나 PR에 비밀이 포함되어 있지 않은지 확인).

구성

_https://github.com/organizations/<org_name>/settings/actions_에서 조직의 github actions 구성을 확인할 수 있습니다.

github actions의 사용을 완전히 금지하거나, 모든 github actions을 허용하거나, 특정 작업만 허용할 수 있습니다.

또한 Github Action을 실행하기 위해 승인해야 하는 사람과 Github Action이 실행될 때 GITHUB_TOKEN의 권한을 구성할 수 있습니다.

Git 비밀

Github Action은 일반적으로 github 또는 제3자 애플리케이션과 상호작용하기 위해 어떤 종류의 비밀이 필요합니다. 비밀을 평문으로 리포지토리에 넣지 않기 위해, github은 이를 비밀로 설정할 수 있도록 허용합니다.

이 비밀은 리포지토리 또는 조직 전체에 대해 구성할 수 있습니다. 그런 다음 Action이 비밀에 접근할 수 있도록 선언해야 합니다:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Bash 사용 예

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

레포지토리나 조직에 구성된 후 github 사용자들은 다시 접근할 수 없으며, 그들은 변경만 할 수 있습니다.

따라서, github 비밀을 훔치는 유일한 방법은 Github Action을 실행하는 머신에 접근할 수 있는 것입니다 (그 시나리오에서는 Action에 대해 선언된 비밀만 접근할 수 있습니다).

Git Environments

Github는 비밀을 저장할 수 있는 환경을 생성할 수 있도록 허용합니다. 그런 다음, 환경 내의 비밀에 대한 접근을 github action에 다음과 같이 부여할 수 있습니다:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

환경을 모든 브랜치(기본값)에서 접근할 수 있도록 구성하거나, 보호된 브랜치만 접근할 수 있도록 하거나, 어떤 브랜치가 접근할 수 있는지 지정할 수 있습니다.
또한 작업을 실행하기 전에 필요한 리뷰 수를 설정하거나, 배포가 진행되기 전에 일정 시간을 기다릴 수 있습니다.

Git Action Runner

Github Action은 github 환경 내에서 실행되거나 사용자가 구성한 타사 인프라에서 실행될 수 있습니다.

여러 조직에서는 타사 인프라에서 Github Actions를 실행할 수 있도록 허용하는데, 이는 더 저렴하기 때문입니다.

조직의 자체 호스팅 러너를 _https://github.com/organizations/<org_name>/settings/actions/runners_에서 목록화할 수 있습니다.

비-Github 인프라에서 실행되고 있는 Github Actions를 찾는 방법은 Github Action 구성 yaml에서 runs-on: self-hosted를 검색하는 것입니다.

다른 조직의 자체 호스팅 박스 내에서 조직의 Github Action을 실행하는 것은 러너가 속한 곳을 알기 위해 러너에 대해 고유한 토큰이 생성되기 때문에 불가능합니다.

예를 들어, 커스텀 Github Runner가 AWS 또는 GCP 내의 머신에 구성된 경우, Action은 메타데이터 엔드포인트에 접근할 수 있고 머신이 실행 중인 서비스 계정의 토큰을 훔칠 수 있습니다.

Git Action Compromise

모든 작업(또는 악의적인 작업)이 허용되면 사용자는 악의적인 Github Action을 사용할 수 있으며, 이는 실행되고 있는 컨테이너를 손상시킬 수 있습니다.

Branch Protections

브랜치 보호는 사용자가 저장소에 대한 완전한 제어를 갖지 않도록 설계되었습니다. 목표는 일부 브랜치 내에서 코드를 작성할 수 있기 전에 여러 보호 방법을 설정하는 것입니다.

저장소의 브랜치 보호는 _https://github.com/<orgname>/<reponame>/settings/branches_에서 찾을 수 있습니다.

브랜치에 다양한 보호를 적용할 수 있습니다(예: master):

• 병합 전에 PR을 요구할 수 있습니다(따라서 브랜치에 직접 코드를 병합할 수 없습니다). 이 옵션을 선택하면 다른 여러 보호가 적용될 수 있습니다:
• 승인 수를 요구합니다. PR을 승인하기 위해 1명 또는 2명 이상의 추가 승인을 요구하는 것이 일반적이므로 단일 사용자가 직접 코드를 병합할 수 없습니다.
• 새 커밋이 푸시될 때 승인을 무효화합니다. 그렇지 않으면 사용자가 정당한 코드를 승인한 후 악의적인 코드를 추가하고 병합할 수 있습니다.
• 코드 소유자의 리뷰를 요구합니다. 저장소의 코드 소유자 중 최소 1명이 PR을 승인해야 합니다(따라서 "무작위" 사용자가 승인할 수 없습니다).
• 풀 리퀘스트 리뷰를 무효화할 수 있는 사람을 제한합니다. 풀 리퀘스트 리뷰를 무효화할 수 있는 사람이나 팀을 지정할 수 있습니다.
• 지정된 행위자가 풀 리퀘스트 요구 사항을 우회할 수 있도록 허용합니다. 이러한 사용자는 이전 제한을 우회할 수 있습니다.
• 병합 전에 상태 검사가 통과해야 합니다. 커밋을 병합하기 전에 통과해야 하는 몇 가지 검사가 있습니다(예: 평문 비밀이 없는지 확인하는 github action).
• 병합 전에 대화 해결을 요구합니다. 코드에 대한 모든 댓글은 PR을 병합하기 전에 해결되어야 합니다.
• 서명된 커밋을 요구합니다. 커밋은 서명되어야 합니다.
• 선형 기록을 요구합니다. 병합 커밋이 일치하는 브랜치에 푸시되는 것을 방지합니다.
• 관리자를 포함합니다. 이 설정이 없으면 관리자는 제한을 우회할 수 있습니다.
• 일치하는 브랜치에 푸시할 수 있는 사람을 제한합니다. PR을 보낼 수 있는 사람을 제한합니다.

References

• https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization
• https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server
• https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github
• https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards
• https://docs.github.com/en/actions/security-guides/encrypted-secrets