GitHub Actions에 대한 정책은 무엇입니까?
엔터프라이즈 정책은 엔터프라이즈 구성원이 GitHub Actions를 사용할 때 사용할 수 있는 옵션을 제어합니다.
엔터프라이즈 정책을 시행하지 않으면 조직 소유자 및 "조직 작업 정책 관리" 권한이 있는 사용자가 조직의 GitHub Actions에 대한 전체 제어 권한을 갖습니다.
참고
조직의 리포지토리에서 CodeQL code scanning 기본 설정과 GitHub Code Quality 워크플로를 실행하려면 GitHub Actions이(가) 활성화되어 있어야 합니다. 하지만 CodeQL의 기본 설정은 공용 작업이나 재사용 가능한 워크플로의 접근 제한과 같은 GitHub Actions 정책의 제약을 받지 않고 code scanning 내에서 독립적으로 작동합니다.
정책 적용
- GitHub Enterprise Server의 오른쪽 위 모서리에서 프로필 사진과 Enterprise settings를 차례로 클릭합니다.
- 페이지의 왼쪽에 있는 엔터프라이즈 계정 사이드바에서 정책을 클릭합니다.
- " 정책"에서 작업을 클릭합니다.
- 각 정책을 구성한 후 저장을 클릭합니다.
"정책" 페이지의 각 섹션에 대한 자세한 내용은 계속 읽어보세요.
정책
"정책" 섹션에서 다음 옵션을 사용하여 엔터프라이즈 내의 조직에서 GitHub Actions을(를) 사용할 수 있는 조직을 제어할 수 있습니다.
- 모든 조직에 GitHub Actions 사용 설정
- 특정 조직에 GitHub Actions 사용 설정
- 모든 조직에 GitHub Actions 사용 중지
참고
GitHub Actions를 비활성화하거나 하나 이상의 조직에서 해당 기능을 사용하지 않도록 설정하면, 영향을 받는 조직에서 code scanning과 GitHub Code Quality 분석을 사용할 수 없게 됩니다.
공용 작업에 대한 액세스 제어
기업은 종종 공급망 거버넌스의 일환으로 잘 테스트된 공개 작업 그룹 에 대한 액세스를 제한하려고 합니다. GitHub에서 사용할 수 있는 정책을 이용하면 code scanning 및 GitHub Code Quality에서 사용하는 동적 워크플로를 막지 않으면서 액세스를 제어할 수 있습니다.
다음 옵션들을 활용하면 code scanning 및 GitHub Code Quality에 대해 예외나 추가 구성 없이 엄격한 제어를 적용할 수 있습니다.
-
**모든 작업 허용**: 작성자나 정의한 위치에 관계없이 작업을 모두 사용할 수 있습니다. -
**엔터프라이즈 작업 **: 엔터프라이즈 내 리포지토리에 정의된 작업 만 사용할 수 있습니다. - 선택 작업 허용____: 엔터프라이즈 내 리포지토리에 정의된 모든 작업 을(를) 사용할 수 있으며, 사용자가 지정한 조건과 일치하는 작업 도 사용할 수 있습니다.
선택 작업 허용____
이 옵션을 선택하면 엔터프라이즈 내의 작업 이(가) 허용되며, 다른 작업을(를) 허용하기 위한 다음 옵션이 제공됩니다.
-
**GitHub에서 만든 작업을 허용합니다.**[`actions`](https://github.com/actions) 및 [`github`](https://github.com/github) 조직에 있는 GitHub에서 만든 모든 작업을 허용합니다. -
**확인된 작성자의 마켓플레이스 작업 허용:** <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-verified" aria-label="The verified badge" role="img"><path d="m9.585.52.929.68c.153.112.331.186.518.215l1.138.175a2.678 2.678 0 0 1 2.24 2.24l.174 1.139c.029.187.103.365.215.518l.68.928a2.677 2.677 0 0 1 0 3.17l-.68.928a1.174 1.174 0 0 0-.215.518l-.175 1.138a2.678 2.678 0 0 1-2.241 2.241l-1.138.175a1.17 1.17 0 0 0-.518.215l-.928.68a2.677 2.677 0 0 1-3.17 0l-.928-.68a1.174 1.174 0 0 0-.518-.215L3.83 14.41a2.678 2.678 0 0 1-2.24-2.24l-.175-1.138a1.17 1.17 0 0 0-.215-.518l-.68-.928a2.677 2.677 0 0 1 0-3.17l.68-.928c.112-.153.186-.331.215-.518l.175-1.14a2.678 2.678 0 0 1 2.24-2.24l1.139-.175c.187-.029.365-.103.518-.215l.928-.68a2.677 2.677 0 0 1 3.17 0ZM7.303 1.728l-.927.68a2.67 2.67 0 0 1-1.18.489l-1.137.174a1.179 1.179 0 0 0-.987.987l-.174 1.136a2.677 2.677 0 0 1-.489 1.18l-.68.928a1.18 1.18 0 0 0 0 1.394l.68.927c.256.348.424.753.489 1.18l.174 1.137c.078.509.478.909.987.987l1.136.174a2.67 2.67 0 0 1 1.18.489l.928.68c.414.305.979.305 1.394 0l.927-.68a2.67 2.67 0 0 1 1.18-.489l1.137-.174a1.18 1.18 0 0 0 .987-.987l.174-1.136a2.67 2.67 0 0 1 .489-1.18l.68-.928a1.176 1.176 0 0 0 0-1.394l-.68-.927a2.686 2.686 0 0 1-.489-1.18l-.174-1.137a1.179 1.179 0 0 0-.987-.987l-1.136-.174a2.677 2.677 0 0 1-1.18-.489l-.928-.68a1.176 1.176 0 0 0-1.394 0ZM11.28 6.78l-3.75 3.75a.75.75 0 0 1-1.06 0L4.72 8.78a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L7 8.94l3.22-3.22a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path></svg>로 레이블이 지정된 확인된 작성자가 만든 모든 GitHub Marketplace 작업을 허용합니다.GitHub Connect을(를) 사용하도록 설정하고 GitHub Actions(으)로 구성한 경우에만 사용할 수 있습니다. 자세한 내용은 GitHub Connect를 사용하여 GitHub.com 작업에 대한 자동 액세스 사용을 참조하세요.
-
**지정된 작업 허용:** 지정한 작업를 허용합니다. 개별 작업 또는 전체 조직 및 리포지토리를 지정할 수 있습니다.
작업를 지정할 때 다음 구문을 사용합니다.
- 특정 태그에 대한 액세스를 제한하거나 작업의 SHA를 커밋하려면 워크플로에서 사용된 것과 동일한 구문을 사용하여 작업를 선택합니다.
- 작업의 경우 구문은
OWNER/REPOSITORY@TAG-OR-SHA입니다. 예를 들어actions/javascript-action@v1.0.1을 사용하여 태그를 선택하거나actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f를 사용하여 SHA를 선택합니다.
- 작업의 경우 구문은
- 패턴을 지정하려면 와일드카드 문자
*를 사용합니다. *space-org로 시작하는 조직에서 모든 작업를 허용하려면space-org*/*를 사용합니다.- octocat으로 시작하는 리포지토리에서 모든 작업를 허용하려면
*/octocat**@*을 사용합니다.
- octocat으로 시작하는 리포지토리에서 모든 작업를 허용하려면
- 여러 패턴을 지정하려면,
,를 사용하여 패턴을 구분합니다. *octocat및octokit조직의 모든 작업 수행을 허용하려면octocat/*, octokit/*을 사용합니다.
정책은 실행기 파일 시스템(uses: 경로가 ./로 시작)에서 로컬 작업에 대한 액세스를 제한하지 않습니다.
러너
기본적으로 리포지토리에 대한 관리자 액세스 권한이 있는 모든 사용자는 리포지토리에 대한 자체 호스트형 실행기를 추가할 수 있으며 자체 호스트형 실행기에는 위험이 있습니다.
- 자체 관리형 실행기는 매번 새로운 임시 가상 머신에서 호스팅된다는 보장이 없습니다. 이에 따라 워크플로에서 신뢰할 수 없는 코드로 손상될 수 있습니다.
- 리포지토리를 포크하고 풀 요청을 만들 수 있는 사용자는 자체 호스트 실행기 환경을 공격하여, 리포지토리에 쓰기 접근 권한이 있을 수도 있는 기밀정보와
GITHUB_TOKEN에 접근할 수 있습니다.
"실행기" 섹션에서 리포지토리 수준 자체 호스트형 실행기를 사용하지 않도록 설정하여 이러한 위험을 중재할 수 있습니다.
참고
리포지토리 수준 자체 호스트형 실행기 생성을 사용하지 않도록 설정한 경우 워크플로는 엔터프라이즈 또는 조직 수준에서 자체 호스트형 실행기에 계속 액세스할 수 있습니다.
사용자 지정 이미지
"사용자 지정 이미지" 섹션에서 다음 액세스 정책을 사용하여 사용자 지정 이미지를 만들고 관리할 수 있는 엔터프라이즈의 조직을 제어할 수 있습니다.
-
**모든 조직에 사용하도록 설정**: 나중에 만든 모든 조직을 포함하여 모든 조직에서 사용자 지정 이미지를 사용하거나 만들 수 있습니다. -
**특정 조직에 대해 사용**: 선택한 조직만 사용자 지정 이미지를 사용하거나 만들 수 있습니다. -
**모든 조직에 대해 사용 안 함**: 어떤 조직도 사용자 지정 이미지를 사용하거나 만들 수 없습니다.
사용자 지정 이미지 보존 정책
사용자 지정 이미지 버전이 보존되는 기간과 비활성 상태인 시기를 정의할 수 있습니다.
-
* 기본값: 20개 버전 * 구성 가능한 범위: 1~100개 버전**이미지당 최대 버전**: 각 이미지의 보존 버전 수를 제한합니다. 이 제한을 초과하면 사용되지 않은 가장 오래된 이미지 버전이 자동으로 삭제됩니다. -
* 기본값: 30일 * 구성 가능한 범위: 1~90일**사용되지 않는 버전 보존**: 지정된 일 수 동안 사용되지 않은 이미지 버전을 삭제합니다. 실행기 풀에 할당되었지만 적극적으로 사용되지 않는 이미지 버전도 사용되지 않는 것으로 간주됩니다. -
* 기본값: 60일 * 구성 가능한 범위: 7~90일**최대 버전 사용 기간**: 지정된 일 수보다 일찍 만든 이미지 버전을 사용하지 않도록 설정합니다. 정책 제한이 증가할 때까지 러너에서 비활성화된 이미지 버전을 사용할 수 없습니다.
아티팩트, 로그 및 캐시 설정
이러한 정책은 아티팩트, 로그 및 캐시의 스토리지를 제어합니다.
아티팩트 및 로그 보존
기본적으로 워크플로에서 생성된 아티팩트 및 로그 파일은 90일 동안 보존됩니다. 이 보존 기간을 1일에서 400일 사이로 변경할 수 있습니다.
변경 내용은 새 아티팩트 및 로그 파일에만 적용됩니다.
최대 및 기본 캐시 크기 제한
기본적으로:
- GitHub Actions이(가) GitHub Enterprise Server 인스턴스에 대해 외부 스토리지에서 사용하는 총 캐시 스토리지는 리포지토리당 최대 10GB로 제한됩니다.
- 리포지토리에 대해 설정할 수 있는 최대 허용 크기는 25GB입니다.
데이터 재사용 가능 항목.작업.캐시 제거 프로세스 %}
각 리포지토리의 기본 총 캐시 크기와 리포지토리에 허용되는 최대 총 캐시 크기를 모두 사용자 지정할 수 있습니다. 예를 들어 각 리포지토리의 기본 총 캐시 크기를 5GB로 지정하되 관리자가 개별 리포지토리에 대해 최대 15GB의 총 캐시 크기를 구성할 수 있도록 허용할 수 있습니다.
조직 소유자는 조직의 각 리포지토리에 적용되는 더 낮은 총 캐시 크기를 설정할 수 있습니다. 리포지토리에 대한 관리자 액세스 권한이 있는 사용자는 리포지토리의 총 캐시 크기를 엔터프라이즈 또는 조직 정책 설정에서 허용하는 최대 캐시 크기까지 설정할 수 있습니다.
프라이빗 리포지토리의 포크 풀 리퀘스트 워크플로우
사용자가 프라이빗 및 내부 리포지토리의 pull_request 이벤트에 대해 워크플로를 실행하는 방법을 제어할 수 있습니다.
-
**포크 끌어오기 요청에서 워크플로를 실행합니다**. 사용자는 포크 끌어오기 요청에서 워크플로를 실행할 수 있습니다. 기본적으로 워크플로는 비밀에 대한 액세스 권한이 없는 읽기 전용 권한이 있는 `GITHUB_TOKEN`를 사용합니다. -
**끌어오기 요청에서 워크플로에 쓰기 토큰을 보냅니다**. 워크플로는 쓰기 권한이 있는 `GITHUB_TOKEN`를 사용합니다. -
**풀 리퀘스트에서 워크플로로 비밀 정보를 보냅니다**. 모든 비밀은 끌어오기 요청에 사용할 수 있습니다. -
**포크 끌어오기 요청 워크플로에 대한 승인이 필요합니다**. 쓰기 권한이 없는 공동 작업자의 끌어오기 요청에 대한 워크플로는 실행하기 전에 쓰기 권한이 있는 사람의 승인이 필요합니다.
엔터프라이즈에 대한 정책을 사용할 수 있도록 설정한 경우, 개별 조직 또는 리포지토리에서 정책을 선택적으로 사용하지 않도록 설정할 수 있습니다. 엔터프라이즈에 대해 정책을 사용하지 않도록 설정한 경우, 개별 조직 또는 리포지토리에서 정책을 사용하도록 설정할 수 없습니다.
워크플로 권한
"워크플로 권한" 섹션에서 기본 권한을 GITHUB_TOKEN에 부여하도록 설정할 수 있습니다.
-
**읽기 및 쓰기 권한:** 엔터프라이즈나 조직이 만들어진 시기에 따라 `GITHUB_TOKEN`에 대한 기본 사용 권한은 다음과 같습니다.* 2023년 2월 2일 이후에 생성됨 – 기본적으로 모든 범위에 대한 읽기 전용 액세스 권한으로 설정됩니다. * 2023 년 2월 2일 이전에 생성됨 – 모든 범위에 대한 읽기 및 쓰기 액세스가 기본값입니다.
-
**리포지토리 콘텐츠 및 패키지 읽기 권한**: 기본적으로 `GITHUB_TOKEN`는 `contents` 및 `packages` 범위에 대한 읽기 권한만 갖습니다. 더 많은 권한 설정은 개별 조직 또는 리포지토리에 대한 기본값으로 선택할 수 없습니다.
리포지토리에 대한 쓰기 액세스 권한이 있는 모든 사용자는 워크플로 파일의 GITHUB_TOKEN 키를 편집하여 특정 워크플로에 대해 permissions에 부여된 권한을 수정할 수 있습니다.
**GitHub Actions가 끌어오기 요청을 생성하고 승인하도록 허용**은 기본적으로 비활성화되어 있습니다. 이 설정을 사용하도록 설정하면 `GITHUB_TOKEN`에서 끌어오기 요청을 만들고 승인할 수 있습니다.