본문 바로가기
  • Let's study
DevOps/CI·CD

[Github Actions] GitHub Secrets와 환경 변수의 범위, 비밀 값 관리

by 코딩고수이고파 2026. 11. 5.

자동화를 구성하면서 인증 토큰이나 비밀 파일을 어디에 보관하고 어떻게 전달할지도 다뤘다.

가장 중요했던 것은 비밀 값을 안전한 곳에 저장하는 것과, 최종 결과물에 포함하지 않는 것은 별개의 문제라는 점이었다.

Secrets와 Variables 구분하기

GitHub Actions에서 민감한 값은 Secrets, 일반 설정값은 Variables로 관리할 수 있다.

 

값 적절한 저장 위치
외부 서비스 API 키 Secrets
데이터베이스 비밀번호 Secrets
이미지 이름 backend-deploy Variables

워크플로에서는 다음처럼 참조한다.

${{ secrets.API_KEY }}
${{ vars.IMAGE_NAME }}

 

Repository Secrets는 저장소 설정의 Secrets and variables → Actions에서 추가한다. 저장 후 기존 값은 다시 조회할 수 없지만 교체할 수 있다.

Secret을 환경 변수로 전달하기

이번에는 PRIVATE_HTML에 저장한 내용을 파일로 만들었다.

- name: private_html 생성
  env:
    NO_HTML: ${{ secrets.PRIVATE_HTML }}
  run: echo "$NO_HTML" > src/private.html

 

 

이름 의미
PRIVATE_HTML GitHub Secret의 이름
NO_HTML 해당 Step의 환경 변수 이름
src/private.html 내용을 기록할 파일 경로
GitHub Secret: PRIVATE_HTML
          ↓
Step 환경 변수: NO_HTML
          ↓
파일: src/private.html

 

NO_HTML을 다른 이름으로 바꾼다면 env의 키와 run에서 참조하는 변수 이름을 함께 바꿔야 한다.

다음 Step에서도 사용할 값 전달하기

저장소 소유자 이름은 소문자로 바꿔 이미지 경로에 사용했다.

- name: set lower case owner name
  run: |
    echo "OWNER_LC=${OWNER,,}" >> ${GITHUB_ENV}
  env:
    OWNER: "${{ github.repository_owner }}"

 

${OWNER,,}는 Bash에서 문자열을 소문자로 바꾸는 표현이다.

여기서는 결과를 $GITHUB_ENV에 기록한다. 이후 같은 Job의 Step에서 OWNER_LC를 사용해야 하기 때문이다.

 

${{ env.OWNER_LC }}

 

범위를 비교하면 다음과 같다.

 

설정 사용 범위
Step의 env 해당 Step
$GITHUB_ENV에 기록한 값 같은 Job의 이후 Step
Job의 outputs 의존하는 다른 Job에서 명시적으로 참조

$GITHUB_ENV에 기록했다고 다른 Job까지 자동으로 공유되는 것은 아니다.

Git에 안 올렸어도 이미지에는 들어갈 수 있다

Secrets에서 파일을 만들면 해당 값을 Git에 커밋하지 않고 빌드 과정에 제공할 수 있다.

하지만 그 파일을 이미지에 복사하면 비밀 값은 이미지에 포함된다.

Secrets에 저장
→ 러너에서 파일 생성
→ 이미지에 COPY
→ 이미지에 파일 내용 포함

 

Secrets를 사용했다는 사실만으로 배포 이미지까지 비밀 값이 보호되는 것은 아니다.

이번 파일 생성 방식은 Git에 파일을 올리지 않고 빌드에 제공하는 흐름을 이해하는 데 사용했다. 실제 인증 키나 비밀번호라면 가능한 한 이미지에 넣지 않고, 실행 시 환경 변수나 비밀 값 관리 도구로 전달하는 방식을 고려해야 한다.

나중에 삭제해도 과거 내용이 남을 수 있다

비밀 값을 제거할 때는 현재 상태만 보면 안 된다.

Git에서 파일을 삭제하고 커밋해도 이전 커밋에는 내용이 남을 수 있다. 이미지에 파일을 복사한 뒤 다음 레이어에서 삭제해도 이전 레이어에는 내용이 남을 수 있다.

현재 파일에서 안 보임
≠ 과거 기록이나 이미지 레이어에도 없음

 

이미지 패키지를 비공개로 바꾸는 것도 이미 내려받은 사본까지 회수하지는 못한다.

실제 액세스 키가 노출됐다면 노출된 키를 폐기하고, 필요한 경우 새 키를 발급해 사용하는 곳도 교체해야 한다.

저장소와 패키지 공개 범위 확인하기

Git 저장소는 소스 코드를 보관하고, GHCR 패키지는 이미지를 보관한다.

저장소가 비공개라는 이유만으로 이미지도 비공개라고 판단하면 안 된다. 이미지의 공개 범위는 GHCR 패키지 설정에서 따로 확인해야 한다.

다만 비공개 이미지라고 비밀 값을 넣어도 안전하다고 단정할 수는 없다. 이미지를 내려받을 수 있는 사람은 내부 파일을 확인할 수 있기 때문이다.

이번에는 비밀 값의 흐름을 끝까지 따라가는 관점이 필요하다는 것을 배웠다.

어디에 저장했는지, 어느 Step에 전달했는지, 파일이나 이미지에 포함됐는지까지 확인해야 한다.

댓글