GitActions: 환경변수 저장하기

CICD의 가장 보편적으로 사용되는 방식중 하나는 Jenkins와 나머지 하나는 Git Actions이다.

 

그렇다면 여기서 GitActions를 사용할때에, 보안과 직결되는 환경변수의 키값을 관리하는 것도 하나의 중요한 포인트이다. 

 

그래서 오늘은 프로젝트를 하면서 키값을 안전하게 보관하는 방식에 대해 내가 사용하면서 느낀 장단점들을 소개해보고자 한다. 

프로젝트 기준은 Spring Boot와 Flask 기준으로 작성하였다.

---

1. application.yaml 파일을 별도의 Repository에서 관리

해당 방식은 통상적으로 아래와 같은 조건에서 사용하기 효율적이다.

 

프로젝트 자체를 깃허브에서 Public으로 배포해야하지만, application.yaml내의 키값은 숨겨야 할때.

이부분은 쉽게 말해서 .gitignore에서는 application.yaml을 추가함으로서 레포지토리에 올라갈 때는 올라가지 않지만 해당 파일을 다른 private 레포지토리에 저장을 하는 방식이다. 

 

그렇다면 실제 배포될때는 어떻게 사용하느냐? 아래와 같이 다른 레포지토리에 올라간 코드를 그대로 git secret에 저장해주는 방식을 사용하면 된다. 

application key

또한 실제 배포를 해줄때에는 해당 시크릿키를 넘겨 받아서 배포해주면 된다. 

 - name: Set environment yml file
        run: |
          mkdir ./src/main/resources
          cd ./src/main/resources
          touch ./application.yml
          echo "${{ secrets.APPLICATION }}" >> ./application.yml
        shell: bash

해당 workflow를 보면 secrets.APPLICATION의 키를 application.yml로 사용한다 정도로 해석하면 될 것 같다.

 

 

장점: 키값 하나하나 저장할 필요없이 전체 코드를 저장해주면 되기에 편리하다.

단점: application.yaml을 저장해주기 위해 추가적인 레포지토리를 만들어야한다. 

아키텍쳐

2. application.yaml의 키 값들을 Git Secret에서 관리

두번째로는 가장 간편하고 통용되는 방식중 하나이기에 빠르게 설명하고 넘어가겠다.

해당 방식은 다른 레포지토리나 os 내에서 관리할 필요없이 모든 것을 git secret에서 관리하는 방식이다. 

git secret

1번과 다른 점은 1번에서는 전체 yaml파일을 복사해서 넣어줬다면 이번에는 특정 키값들만 저장해서 사용하는 방식이다. 

 

장점: application.yaml에서 숨기고 싶은 키 값만 시크릿키에 지정, 저장할 수 있다.

단점: 숨겨야하는 키 값이 늘어날수록 시크릿 키 관리가 복잡해진다.

 

3. 중요 키값들을 서버의 os 내에서 관리

위 1, 2번 과정에는 보안적인 측면에서 공통적인 취약점이 있다. 첫번째로 사실 깃허브 레포지토리에서만 숨기는거지 도커로 배포할 경우 도커 안에서는 키 값들이 그대로 저장되어 있기에 기본적으로 public이라는 도커 네트워크에서는 취약점을 드러낼 수 밖에 없다. 때문에 이런 경우에는 키 값들을 배포가 되어 돌아가는 서버의 os에 저장할수 있다. 

 

예를 들어 application.yml 코드가 아래와 같이 저장되어 있다고 가정했을 때

cloud:
  aws:
    s3:
      bucket-name: ${AWS_BUCKET_NAME}
    credentials:
      accessKey: ${AWS_ACCESS_KEY}
      secretKey: ${AWS_SECRET_KEY}
    region:
      static: ${AWS_REGION}
    stack:
      auto: false
  ai:
    url: ${FLASK_SERVER}

 

해당 키값은 깃 시크릿이 아닌, 배포 서버의 .env파일에 아래와 같이 저장해주면 된다.

 

DB_URL=jdbc:mysql://your-database-url
DB_USERNAME=your-database-username
DB_PASSWORD=your-database-password
FRONT_URL=your-frontend-url
BACKEND_DOMAIN=your-backend-domain

키 값은 다르지만 예시용으로만 참고 바람

 

이런식으로 된다면, 키 값이 바뀔경우 깃 시크릿 수정이 아닌, 직접 ssh로 서버에 들어간 다음 env파일을 수정해주는 방식으로 진행 하면된다.

 

장점: 보안성 높음. 이전 키 값들 조회 가능.

단점: 키값 수정 혹은 추가시 ssh로 서버에 들어가서 수정해야하는 번거로운 작업 필요.

 

---

위 3가지 경우 중 어떤 방식이 정답이다 혹은 제일 효율적이다라는 것은 없다고 생각한다. 다만 프로젝트의 유연성, 특성에 따라 필요한 방식을 잘 채택해서 관리하는 것이 중요하다!