-
질문 & 답변
카테고리
-
세부 분야
데브옵스 · 인프라
-
해결 여부
해결됨
강의 잘들었습니다! 포트폴리오 마무리에서 배포관련해서 궁금한점이 좀더 있어서 질문드립니다.
24.02.29 02:44 작성 조회수 693
3
우선 프론트와 백엔드 , DB를 각각 인스턴스를 만들어서 배포하는 로직을 잘봤습니다.
궁금한점이
jar파일을 github에 올리게되면
application.yml or perterties 안에있는
민감정보들이 노출되는 문제가 있다고 생각이드는데
이런 민감정보는 어떤식으로 가리는게 좋을까요
답변을 작성해보세요.
2
이준형(Foo)
지식공유자2024.02.29
락곤님 안녕하세요~
좋은 질문입니다.
일반적으로 이런 민감정보는 GitHub 레포지토리가 Private 이더라도 가급적 노출시키지 않는게 좋은데요,
노출시키지 않기 위해서는 간단히 처리하기 위해선 Jasypt 같은걸로 암호화 시키는 것도 좋은 방법입니다.
다만, 실무에서처럼 여러 서비스를 관리해야하는 경우 Vault를 사용하는게 더 일반적이고 관리에 용이합니다.
Vault는 쉽게 생각하면 이런 민감 정보를 저장하고 있는 Map인데요, 여기에는 그냥 접근할 수 있는게 아니라 인증할 수 있는 Key가 필요합니다.
그럼 여기서 또 궁금한 내용은, Vault에 접근할 수 있는 Key는 도대체 어디에 보관하는지겠죠? Vault에 접근할 수 있는 Key를 다시 application.yaml 이나 properties에 보관하면 무용지물일테니까요.
여러 방식이 있지만, 쿠버네티스를 사용하지 않는 경우와 사용하는 경우 각각 어떤식으로 하는지 '일반적인' 방법에 대해 소개해드리겠습니다.
먼저, 쿠버네티스를 사용하지 않는 경우 CI/CD 툴(Jenkins 같은)에 의해 배포 스크립트를 작성해서 배포하게 될텐데요, 이때 배포 스크립트에 Vault Key를 환경 변수로 넣어서 실행시켜줍니다. Vault Key를 환경 변수로 넣어서 배포하면 애플리케이션이 실행될 때 당연히 Vault에 접근하여 민감정보를 가져올 수 있을겁니다.
반면 쿠버네티스를 사용하는 경우 별도의 CI/CD 툴을 사용할 수도 있겠지만, 쿠버네티스는 이런 민감정보를 저장하기 위한 리소스를 제공합니다. 바로 Secret 이라는 건데요, Secret에 Vault Key를 저장해두고, 애플리케이션이 실행될 때는 그 값을 가져와서 사용합니다.
위에서 소개한 두 가지 방식 모두 CI/CD 툴이나 쿠버네티스 클러스터의 접근 권한을 가지고 있지 않으면 접근할 수 없는 값입니다. 따라서 안전하게 보관할 수 있습니다.
+) 그럼 CI/CD 툴이나 쿠버네티스 클러스터의 접근 권한은 어떻게 얻냐? 하면 이 부분은 보통 회사 내에서 사용하는 LDAP 계정(그냥 웹 서비스 로그인 할 때 사용하는 ID/PW 같은)을 사용해서 접근할 수 있게 만듭니다.
궁금하신 내용에 대한 답변이 되었을까요?
또 궁금한 내용 있으면 질문 주세요.
감사합니다.
락곤
질문자2024.03.02
답변 정말 감사합니다.
민감정보처리부분때문에 많은 CI/CD 영상과 배포 영상을 찾아봤지만
민감정보를 가리고 배포하는 영상은 보지못해서 감이 안왔었는데
영상 처럼 바로 1번방법 .jar파일을 리눅스에서 wget할때는 Jasypt 같은 암호화를 사용해서 민감정보를 암호화고 ,
2번방법 .CI/CD 툴을 쓸땐 깃헙 액션을 예로들면 깃허브 시크릿키에 설정하면 되는거였군요 .
2번방법은 자료가 많이 없어서 부딪혀보며 테스트를 해봐야겠네요추가질문) 도커파일을 만들어서 도커 허브에 jar파일을 올릴때도 jasypt를 써도 무방할까요?
직접 써보니 jasypt password만 잘관리하면 무방한거같네욧..!
락곤
질문자2024.03.02
선생님 추가 질문드립니다 정말 죄송합니다
제가 프론트는 리액트를 사용해
vercel로 배포를 완료했습니다.
https:// 배포가되었고
백엔드는 강사님 로직처럼
벌쳐에 인스턴스 만들어서
wget으로 jar 실행 시켰고
프론트 와 백엔드 통신 엔드포인트도 각각 도메인 으로 설정을했는데
strict-origin-when-cross-origin
응답 헤더 (0)
요청 헤더
네트워크 로그 행 이름: id-check158.247.236.98/api/v1/auth
이런 애러가생깁니다
제가 추측하기론
프론트는 vercel에서 https 로 배포가 된거같은데
백엔드는 http 여서 뭔가 오류가 생긴거같은데
인스턴스에 jar 파일 실행시켰어요
postman으로 직접 백엔드 인스턴스에 헬첵 요청을 보냈을땐 응답이가는데
vercel로 보냈을땐 안가네요... 아예 백엔드에 로그가 찍히지않아요
아마 백엔드에도 https를 적용해야하는거같은데
어떤식으로 설정해야하는지 힌트라도 주실수있나요
자꾸질문해서 죄송합니다
이준형(Foo)
지식공유자2024.03.02
질문하시는게 죄송할일인가요 ㅎㅎㅎ..
오히려 좋습니다.
아마 추측하신대로
프론트엔드는 https인데 백엔드는 http인게 첫번째 문제일 것 같습니다.
웹 브라우저에서 보안 정책상 다운그레이드되는 요청(https -> http)을 차단하고 있을거에요.
https로 바꾸더라도 문제는 하나 더 있는데, 백엔드 쪽에 CORS 관련 허용할 도메인을 지정해야합니다. 백엔드 애플리케이션 입장에서 아무곳에서나 API 요청이 오는걸 허용하고 싶지 않은거죠. 허용해줄 대상을 지정해야합니다.
따라서 아래 2가지를 해야 정상적으로 작동할 것 같습니다.
vercel을 사용하고 있는 프론트엔드 페이지에서 백엔드 애플리케이션쪽을 호출할 때 https가 될 수 있도록 백엔드 애플리케이션 쪽에 인증서를 추가(도메인이 있어야 합니다 ㅠ)
백엔드 애플리케이션쪽에 vercel에서 실행되고 있는 프론트엔드 페이지의 도메인 주소를 CORS 설정에 허용(allow) 설정
아마 이렇게 해주면 CORS 이슈 없이 정상적으로 동작할 것 같습니다!
1
락곤
질문자2024.03.04
몇일째 삽질하다 ...마지막으로 답변남겨봅니다..!
vultr에서
인스턴스를 생성후 ->
자바버전을 17 번경->
톰켓 wget으로 설치후 ->
8080 포트 방화벽 해제 ->
실행했더니 http: ~~~:8080 고양이 보입니다.
인스턴스 ip 주소로
가비아 도메인 구매후 A 레코드 연결완료
[백엔드 도메인주소]:8080 고양이보임.
zerossl cname 까지 설정후
3개의 인증 파일 을
scp를 통해 /opt/certs/ 경로에 저장
tomcat은 /opt/tomcat/conf/server.xml에서
https://help.zerossl.com/hc/en-us/articles/360060120393-Installing-SSL-Certificate-on-Tomcat
이렇게 지정해주고
저장했습니다.
톰캣 재실행 하고
check 를했는데 왜 ㅜㅜㅜ,,,,, 안될까요 삽질 너무 어렵네요
P.S ( 이것이 취업을 위한 백엔드 개발이다 with 자바) 책 잘받았습니다.
잘 읽고 블로그에 올려 많이많이 공유하겠습니다!! 감사합니다
락곤
질문자2024.03.05
삽질 해결 후기.
우선 톰캣으로 인증을 하려다
스프링부트에서 직접인증서를 올려서 https는 적용했습니다.
그럼에도 계속 options에서 플라이웨이트 cors가나와
스프링부트 에서 cors설정을 했는데도 안되서 삽질 계속하다
브라우저 캐시 삭제후 다시해보니 되네요
감사합니다 강사님 강의때문에 배포에 대한 지식을 더욱얻을수있었습니다.
삽질 20시간정도 한후기입니다.
이준형(Foo)
지식공유자2024.03.05
ㄷ ㄷ 고생하셨네요~
오래 삽질하셨지만, 삽질하신 내용이 락곤님한테 좋은 양분이 되었을겁니다~
아무튼 고생 많으셨고 강의 잘 들어주셔서 감사합니다~
책도 잘 읽어주세요!! ㅎㅎ
답변 2