pull_request_target 🤐로 외부 포크를 구축할 때 환경 보호 규칙을 사용하여 비밀 보호

GitHub Actions를 사용하여 분기된 리포지토리에서 끌어오기 요청을 작성하는 것은 비밀과 관련하여 약간 까다로울 수 있습니다. documentation에 따라 GITHUB_TOKEN를 제외하고 워크플로가 포크된 저장소에서 트리거될 때 비밀이 러너에게 전달되지 않습니다. 이는 포크된 저장소 내에 포함될 수 있는 신뢰할 수 없는 코드의 자동 실행을 방지하기 위한 것입니다.
즉, 워크플로에 포함되어야 하는 암호가 있는 경우 pull_request 트리거를 사용할 수 없습니다.

다행히 pull_request_target comes to rescue .

...the pull_request_target event behaves in an almost identical way to the pull_request event with the same set of filters and payload. However, instead of running against the workflow and code from the merge commit, the event runs against the workflow and code from the base of the pull request. This means the workflow is running from a trusted source...

이제 비밀에 액세스할 수 있지만 잘못된 코드를 작성하고 있습니다.

분명히 다음 코드로 이 문제를 극복하려는 사람들이 있습니다.

#INSECURE
steps:
- uses: actions/checkout@v2
  with:
    ref: ${{ github.event.pull_request.head.sha }} # Check out the code of the PR

다른 보안 조치를 취하지 않으면 안전하지 않기 때문에 권장하지 않으며 정당합니다.

GitHub의 자체 기사Preventing pwn requests에서 저자Jaroslav Lobačevski는 PR에 pull_request_target 레이블이 지정되었는지 여부를 확인하는 조건과 함께 safe to test를 사용할 것을 제안합니다. 이와 같이:

    jobs:
      build:
        name: Build and test
        runs-on: ubuntu-latest
        if: contains(github.event.pull_request.labels.*.name, 'safe to test')

이것은 완벽하게 유효한 접근 방식이지만 포크를 빌드하는 동안 승인되지 않은 코드 실행을 방지하는 더 좋고 편리한 방법을 찾은 것 같습니다.

환경 보호 규칙

불과 몇 달 전에 GitHub는 Environment protection rules 을 소개했습니다. 이 기능의 주요 목적은 주어진 조건이 충족될 때까지 워크플로 실행을 일시 중지하는 규칙을 적용하여 배포 중에 환경을 보호하는 것입니다. 사람의 승인, 특정 시간 경과 등이 있습니다. 그러나 일반적인 용도로 사용할 수 있습니다. 우리의 경우 저장소 비밀을 보호하고 신뢰할 수 없는 코드의 실행을 방지하는 데 사용할 것입니다.

빌드 보호

사람의 승인이 필요한 "끌어오기 요청 통합"이라는 더미 환경을 추가하는 것부터 시작하겠습니다.



우리의 기본 빌드 절차는 이 환경과 연결되며 더미 워크플로 단계approve가 선행되어 워크플로를 시작하고 풀 요청 작성자에게 더 진행하기 전에 검토가 필요함을 알립니다.

on:
  pull_request_target:
    branches: [ master ]

jobs:
  approve: # First step
    runs-on: ubuntu-latest

    steps:
    - name: Approve
      run: echo For security reasons, all pull requests need to be approved first before running any automated CI.

  build: # Second step
    runs-on: ubuntu-latest

    needs: [approve] # Require the first step to finish
    environment:
      name: Integrate Pull Request # Our dummy environment
    steps:
    - ...

이렇게 하면 누군가가 제출된 코드를 검토할 때까지 워크플로가 진행되지 않으므로 다음 단계에서 안전하게 ${{ github.event.pull_request.head.sha }}를 확인하고 빌드할 수 있습니다. 따라서 빌드는 PR의 기반과 PR의 실제 코드에서 신뢰할 수 있는 워크플로를 사용하여 실행됩니다.

실제로 작동하는 방식

누군가 풀 요청을 제출하면 워크플로가 트리거되고 즉시 일시 중지됩니다.

검토자 또는 검토자 그룹이 이메일 알림을 받습니다.

검토자가 링크를 클릭하고 저장소로 이동하여 제출된 PR에 원치 않는 코드가 포함되어 있지 않은지 확인하고 최종적으로 승인합니다.

빌드 진행

모든 승인이 감사됨

Codecov에 대한 몇 마디

이 워크플로를 구현하는 동안 GitHub Checkout Action과 유사하게 Codecov 작업이 기본적으로 pointed to the PR's Base이고 재정의해야 하는 문제에 직면했습니다. 이는 다음을 통해 달성할 수 있습니다.

- name: Codecov
  uses: codecov/codecov-action@v1
  with:
    token: ${{ secrets.CODECOV_TOKEN }}
    override_pr: ${{ github.event.number }}
    override_commit: ${{ github.event.pull_request.head.sha }}

다음 경고 메시지를 제거하려면:

Issue detecting commit SHA. Please run actions/checkout with fetch-depth > 1 or set to 0

결제 작업의 fetch-depth도 2로 설정해야 합니다.

steps:
- uses: actions/checkout@v2      
  with:
    fetch-depth: 2

참고: 조건부 workflow step 및 shell script을 사용하는 대체 접근 방식을 찾았습니다. 그러나 커밋 SHA를 재정의하는 것이 훨씬 쉽습니다.

요약

이 접근 방식의 장점은 보류 중인 워크플로에 대한 전자 메일 알림을 받고 클릭 한 번으로 검토 및 승인할 수 있는 검토자 그룹을 할당할 수 있다는 것입니다.
제 생각에는 모든 이벤트가 기록되고 레이블을 사용하는 것보다 의미론적으로 더 정확하기 때문에 프로세스가 더 투명합니다.

전체 워크플로를 탐색하려면 내 프로젝트WopiHost를 확인하십시오.
pull_request_target의 세부 사항에 대해 자세히 알아보려면 documentation로 이동하십시오.