들어가며

Github public Repository를 사용하는 경우 민감 정보를 관리하는건 중대사항이라고 할 수 있다. 민감 정보가 들어간 yml 파일이 Github에 올라가게 되면 해커에 의해 끔찍한 일이 벌어질 수 있다.

그래서 이를 방지하고자 몇가지 방법을 사용할 수 있는데 다음과 같다.

1. Git SubModule 사용
2. 환경 변수 사용
3. 외부에서 파일 읽기

금나와라뚝딱은 이번에 Git SubModule을 사용해서 민감정보를 관리했다.

이 방식을 요약해서 설명하자면, private로 GitHub Repository를 생성해서 민감 정보를 넣어놓고 원본 public Repository에서 해당 private Repository를 서브모듈로 구성해 사용하는 방식이다. 이렇게 하면 원본 public Repository에서 민감 정보에 접근하려 해도 민감 정보가 있는 경로는 private Repository이기 때문에 권한이 있는 사용자만 접근할 수 있다.

Git SubModule을 사용한 yml 관리의 단점

1. 값 변경시 커밋이 필수

설정값을 변경하고 싶으면 변경 후 커밋 & 푸쉬를 해야한다. 재빠르게 변경하고 싶을때는 문제가 되겠지만 코드리뷰를 할 수 있기 때문에 안전한 방법이기도 하다.

2. 커밋 과정이 번거롭다

yml을 수정하려면 SubModule 경로로 가서 커밋 → 푸쉬를 하고 다시 원래의 프로젝트 경로로 돌아와서 서브모듈 수정사항을 커밋 후 푸쉬해줘야 한다.

3. 다른 협업자가 파일을 수정했을 경우 로컬 리포지토리를 업데이트 해야한다.

yml을 수정했다는 연락을 받으면 SubModule 경로로 가서 pull 받은 후 나와서 git submodule update 명령어로 서브모듈을 동기화시켜줘야 했다.

4. (번외) yml Copy시 기존 yml파일을 덮어쓴다.

processResources.dependsOn('copyConfigSettings')

task copyConfigSettings(type: Copy) {
    from 'src/main/config' //서브모듈 경로
    into 'src/main/resources/'
}

build {
    dependsOn copyConfigSettings
}

금나와라뚝딱에서는 build시 위와같이 서브모듈 경로에 있는 yml을 원래 프로젝트 resources 경로에 copy했는데, 이렇게 되면 설정값을 변경 후 테스트로 로컬에서 build를 하게되면 변경된 설정값이 다시 기존의 서브모듈에 저장된 값으로 변경되어서 build 되기 때문에 테스트 jar 파일을 만들기가 까다로웠다.

전환 시작