3/26 Git Action

1. Github Workflows

• 정의
  • 하나 이상의 작업을 실행하는 구성 가능한 자동화된 프로세스
  • 이벤트가 일어나면 자동으로 jobs를 수행하는 자동화된 프로세스
  • 깃헙 저장소를 기반으로 일련의 workflow를 자동화하도록 도와주는 CI/CD 도구
  • 이벤트 == trigger
    • ex. 이벤트, repository_dispatch, 예약된 시간, 수동
    • ex. 푸시, 릴리스 생성, 이슈 등
  • 작업
  • 단계: 단계 안의 작업들구성요소

    

• 작동 방식
  • .github/workflows의 YAML파일에서 수행됨
    • 예시

    • 

    • on : 이벤트 트리거
    • jobs
      • runs-on: 가상 환경 os 버전
      • steps: 진행할 step들 나열
        • name
        • uses
        • with
        • run
• Github Action에서 → 내 repository로 push하려면 권한 필요
  • PAT(Personal Access Token)
  • 생성: Settings → Personal access tokens
  • 사용: Settings → Secrets and variables - Actions
• Github Action에 추가
•  

name: Run Python Script and Commit File

on:
    workflow_dispatch:

jobs:
    build:
        runs-on: ubuntu-latest

        steps:
            - name: Checkout repository
              uses: actions/checkout@v2
              with:
                  persist-credentials: false # 이 줄을 추가합니다

            - name: Set up Python
              uses: actions/setup-python@v2
              with:
                  python-version: "3.x"

            - name: Install dependencies
              run: |
                  python -m pip install --upgrade pip
                  pip install requests

            - name: Run script
              run: python crawl_naver.py

            - name: Commit file
              run: |
                  git config --local user.name '깃헙 이름'
                  git config --local user.email '깃헙 이메일'
                  git add naver.txt
                  git commit -m "Add naver.txt"
            - name: Push
              uses: ad-m/github-push-action@master
              with:
                  branch: "main"
                  github_token: ${{ secrets.GH_TOKEN }} # 여기서 GH_TOKEN은 GitHub Secrets에 저장된 PAT입니다.

2. CI/CD

• CI (Continuous Integration, 지속적 통합)
  • 개발자들이 작성한 코드를 지속적으로 메인 브랜치에 통합하는 프로세스
• CD (Continuous Deployment/Delivery, 지속적 배포)
  • 코드 변경 사항이 자동으로 프로덕트 환경에 배포되는 프로세스
    •  

 

 

---

추가: actions/checkout@v2의 persist-credentials: false

jobs:
    build:
        runs-on: ubuntu-latest

        steps:
            - name: Checkout repository
              uses: actions/checkout@v2
              with:
                  persist-credentials: false # 이 줄을 추가합니다

 

persist-crendentials가 뭘까?

 

 

actions/checkout/README.md

The auth token is persisted in the local git config. This enables your scripts to run authenticated git commands. The token is removed during post-job cleanup. Set persist-credentials: false to opt-out.

 

actions/checkout동안 얻은 auth token은 local git config동안 유지된다는 것. 내가 토큰을 안 줬는데 어떻게 작동하는 지는 모르겠다

이 토큰은 다 끝나고 post-job cleanup 때 사라지지만, credential이 사라지길 원한다면 'persist-credentials: false'를 넣어줘야 한다.

실제 github action / post-job cleanup

 

이 항목에 대해 issue가 열린 적이 있다 (https://github.com/actions/checkout/issues/485).

Currently one has to resort to explicitly specifying persist-credentials: false to avoid the credentials being persistent. My understanding is that persisting the credentials gives every step in the job that occurs after actions/checkout@v2 implicit access to the token. This is not what people expect and this leads people to write jobs that expose their repo to more risk than they otherwise would.
I propose the persist-credentials feature be removed completely and then v3 be released. Otherwise, if that's not practical, then at least the default should be changed to false.

 

요약하면 actions/checkout@v2이후의 jobs에 대해 토큰에 접근할 권한이 있고, 이것이 사람들이 의도치 않게 repo를 보안 위험에 빠뜨린다는 것, 그래서 그런 특성을 없애거나 default값을 false로 바꾸어 v3를 출시해달라는 요구

 

Agreed this seems a severe security issue, because it means any workflow using actions/checkout basically leaks the token to any process/action in that workflow which can just read it from .git/config.
...
So, depending on whether the token is explicitly passed to some action:
If yes, then it seems the only safety net is to set token permissions. If no, it would be safe by default with this change or with persist-credentials: false, regardless of the token permissions. A workaround is to set token permissions
I guess GitHub sees setting token permissions as the more general solution.If so, fine, but then the default should be secure and so the default workflow permissions should be just contents: read.
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ also has a mention related to this, search for persist-credentials:
If the workflow uses actions/checkout and does not pass the optional parameter persist-credentials as false, it makes it even worse. The default for the parameter is true. It means that in any subsequent steps any running code can simply read the stored repository token from the disk.

마찬가지로 토큰이 그냥 .git/config를 읽을 수 있어 위험하므로

1. 토큰의 권한을 :read로 설정하거나 2. persist-credentials: false를 넣어주라는 말

 

 

 

깃헙의 토큰은 뭐고 SSH 인증은 뭘까?...

 

Github Token

https://docs.github.com/ko/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

Personal access token은 사용자를 대신하여 GitHub 리소스에 액세스하기 위한 것입니다. 조직을 대신하여 리소스에 액세스하거나 장기적인 통합을 위해서는 GitHub App을(를) 사용해야 합니다. 자세한 내용은 "GitHub 앱 만들기 정보"을(를) 참조하세요.

 

ChatGPT

GitHub 토큰은 GitHub API에 대한 액세스를 인증하는 데 사용되는 보안 키입니다. 이 토큰을 사용하면 사용자가 GitHub API를 통해 저장소를 읽거나 쓸 수 있습니다. 주로 워크플로나 자동화된 프로세스에서 GitHub와 상호 작용할 때 사용됩니다.

 

Github API를 쓸 때 권한을 얻기 위해서 쓰는 인증 수단 이라고 정리할 수 있겠다

 

SSH 인증이란 Secure Shell (SSH) 프로토콜을 사용하여 안전하게 인증하고 통신하는 방법, 일반적으로 SSH 인증은 원격 서버에 로그인하거나 데이터를 안전하게 전송하는 데 사용된다. (chatGPT)

원격 서버에 로그인하거나 / SSH 터널을 열 때 ssh -i "key.pem" .... 의 명령어를 쓴 기억이 있다

 

그렇다면 Checkout Repository 단계에서 나는 git token을 준 적이 없는데 얘는 어떻게 내 repo의 checkout 권한을 갖고 있는 걸까? 

해당 repo의 Settings-Secrets and variables로 이미 준 게 아니냐?? 할 수 있는데 이거 주기 전에도 push만 안 됐지 checkout은 그냥 됐다

 

chatGPT의 답변

GitHub Actions에서는 기본적으로 GITHUB_TOKEN이 제공되며, 이 토큰은 해당 레포지토리에 대한 읽기 및 레포지토리의 이슈, PR을 생성 및 관리할 수 있는 권한을 제공합니다. 그러나 코드를 푸시하기 위해서는 추가적인 권한이 필요합니다. 따라서 워크플로우가 코드를 푸시하려면 명시적으로 repo 범위를 가진 개인 액세스 토큰을 사용해야 합니다.
일반적으로 워크플로우에서 코드를 푸시하려면 secrets.GITHUB_TOKEN 대신에 명시적인 개인 액세스 토큰을 사용하게 됩니다. 이렇게 하면 레포지토리에 대한 쓰기 권한을 명시적으로 부여할 수 있습니다.

{{secrets.GH_TOKEN}} 이런 형태로 내가 등록한 개인 액세스 토큰을 쓸 수 있다. 

 

아하 따봉지피티야 고마워 ~!!!

 

---

정리하자면 checkout이나 읽기, 이슈, PR 생성 및 관리할 수 있는 기본적인 GITHUB_TOKEN이 Github Actions에서 제공된다. 바로 위 사진의 Setup Jobs 단계에서 read권한을 획득한 것을 볼 수 있다.

그러나 actions/checkout@v2함수에서 한 번 GITHUB_TOKEN을 획득하면 그 이후 단계에서도 마음대로 .git/config 파일에 접근할 수 있어 보안적으로 취약하다.

그래서 actions/checkout@v2에 persist-credentials: false 옵션을 넣어 이후 단계에서 해당 토큰을 쓰지 못하게 한다.

 

push는 추가적인 권한이 필요하며 이는 직접 PAT(Personal Acess Token)을 발급받아 해당 repo의 Settings-Secrets and Variables - Action에 등록해줘야 Github Action으로 push 해줄 수 있다. 

---

 

여기서 또 드는 의문 ... 내가 github repo에 내 PAT토큰을 등록했으니까 다른 사람도 내 repo에 푸시할 수 있는 거 아닌가?

chatGPT의 답변
GitHub 리포지토리의 Secrets and Variables - Action에 Personal Access Token(PAT)을 등록하는 경우, 그 PAT를 사용하여 설정된 권한의 범위 내에서 리포지토리에 대한 작업을 수행할 수 있는 GitHub Actions 워크플로우를 만들 수 있습니다. 그러나, 이것이 다른 사람들이 직접 당신의 리포지토리에 push할 수 있다는 의미는 아닙니다. 여기에서 중요한 것은 PAT의 사용 권한과 워크플로우의 구성입니다.

* PAT의 권한: PAT에는 리포지토리에 대한 다양한 작업을 수행할 수 있는 권한이 부여될 수 있습니다. 이는 토큰을 생성할 때 선택한 옵션에 따라 다릅니다. 예를 들어, 리포지토리에 push할 권한을 포함하여 생성된 PAT를 워크플로우에서 사용한다면, 해당 워크플로우는 리포지토리에 대한 push 작업을 수행할 수 있습니다.

* 워크플로우의 구성: GitHub Actions 워크플로우는 .github/workflows 디렉토리에 있는 YAML 파일로 구성됩니다. 이 워크플로우 파일 내에서 PAT를 사용하여 리포지토리에 push하는 등의 작업을 정의할 수 있습니다. 워크플로우는 특정 이벤트(예: push, pull request, manual trigger 등)에 의해 자동으로 실행될 수 있습니다.

* 접근 제어: GitHub 리포지토리의 Secrets은 리포지토리의 관리자만이 설정하고 관리할 수 있습니다. 따라서, 다른 사용자가 당신의 리포지토리에 직접 PAT를 사용하여 push할 수 없습니다. 그들이 리포지토리에 push할 수 있는 유일한 방법은 당신이 설정한 워크플로우를 통하는 것입니다. 또한, 리포지토리에 대한 push 권한이 필요한 경우, 해당 사용자에게 적절한 권한을 부여하거나, pull request를 통해 코드 변경을 제안하도록 할 수 있습니다.

결론적으로, PAT를 Secrets and Variables - Action에 등록하는 것은 워크플로우가 해당 PAT의 권한 범위 내에서 작업을 수행할 수 있도록 하는 것이지, 다른 사용자가 직접 당신의 리포지토리에 접근할 수 있게 하는 것은 아닙니다. 이러한 설정과 워크플로우는 리포지토리의 관리자에 의해 제어됩니다.

 

내 github repo에 내 local에 push할 수 있는 이유는 SSH 키와 Personal Access Token (PAT) 등을 사용해 내 local에 github login을 이미 했기 때문

 

---

결국 github actions에서 push를 사용할 수 있다 != 다른 사람이 내 repo에 push할 수 있다 이므로 내가 정해둔 run_python_script.yml만 실행할 수 있다는 말이다(내 repo를 수정할 순 없으니까).