SSAFY에서 프로젝트를 진행할 땐, 주요 환경변수(외부 API Key 같은거)를 GitLab에 바로 올리지 않습니다.
(물론 Git Repository가 private이긴 하지만, 혹시 모르니까..?)
그렇기 때문에, 이걸 AWS EC2에 배포할 때, 팀들마다 다양한 방법을 사용합니다.
제가 있던 팀에선 AWS EC2에 작성해둔 Dockerfile에 환경변수를 명시하는 방법을 사용했습니다.
밑의 코드를 보다시피, Spring Boot의 환경 변수를 Dockerfile에 선언해주었는데, 정상적으로 환경변수가 적용됩니다.
Spring Boot 배포용 Dockerfile
FROM adoptopenjdk/openjdk11
# DB
ENV DB_URL=
ENV DB_USERNAME=
ENV DB_PASSWORD=
# jwt
ENV JWT_SECRET_KEY=
# Social Login
ENV KAKAO_CLIENT_ID=
# S3
ENV S3_BUCKET=
ENV CREDENTIALS_ACCESS_KEY=
ENV CREDENTIALS_SECRET_KEY=
ENV REGION_STATIC=
COPY ./mt-0.0.1-SNAPSHOT.jar /mt-0.0.1-SNAPSHOT.jar
CMD ["java", "-jar", "mt-0.0.1-SNAPSHOT.jar"]그럼 이게 그대로 프로젝트에 적용되는 이유는 뭘까..? 그리고 이게 맞는, 안전한 방법일까..?
Dockerfile와 환경변수
Dockerfile이란 (Docker 이미지 생성 → 컨테이너 실행)을 위해 Docker 이미지에 대한 정보나 설정 파일을 기술해둔 스크립트 파일입니다.
작성한 Dockerfile 라인 순서대로 수행하며 Docker 이미지를 생성하는 것입니다.
만약 Docker 이미지화를 하려는 것이 Spring Boot라면, Spring Boot가 빌드되는 것 입니다.
그럼 당연히 미리 ENV를 Dockerfile에 기술해뒀기 때문에, (환경변수를 알고있는) 도커 컨테이너가 실행시킨 Spring Boot에 적용할 수 있는 것입니다.
그럼 가장 중요한 고민은 “과연 이게 안전한 방법일까? 현업에서도 이런 방법을 사용할까?” 입니다.
많은 블로그들을 찾아보고, ChatGPT를 통해 알아본 결과,
환경 변수를 Dockerfile에 하드코딩하는 것은 일반적으로 안전한 방법이 아닙니다.
이는 Docker 이미지를 빌드할 때 민감한 정보를 노출시킬 수 있기 때문입니다.
Docker 이미지는 공개되거나 공유되는 경우가 많기 때문에, 보안 정보를 노출시키는 것은 위험합니다.
대신에, **Docker Secrets, Docker Configs**를 통해 환경 변수를 안전하게 전달할 수 있습니다.
1. Docker Secrets:
Docker Swarm을 사용할 때, 민감한 정보를 안전하게 보관하고 전달하는데 사용됩니다.
Docker Secrets는 암호, API 키, 인증 토큰 등과 같이 민감한 정보를 안전하게 관리할 수 있습니다.
2. Docker Configs:
Docker Swarm을 사용할 때, 설정 파일을 안전하게 보관하고 전달하는데 사용됩니다.
Docker Configs는 애플리케이션의 설정 파일을 관리하고 암호화된 형태로 전달할 수 있습니다.공통적으로 나온게 Docker Swarm입니다.
다음 글에선 Dokcer Swarm을 사용해 환경변수와 관련된 보안을 강화하는 방식을 사용해보겠습니다.
