작성
·
9
·
수정됨
1
강사님 안녕하세요. 잘 배우고 있습니다.
강의를 보다가 든 생각인데 실제로 Secret을 현업에서 관리하게 될 때는 아래와 같은 구조로 이뤄질 것 같은데 맞나요?
신규 피쳐에 새로운 시크릿이 필요하다. 개발자가 devops 팀에 추가를 요청한다.
devops 에서 마스터 노드로 접근하여 kubectl 을 통해 secret 을 생성한다.
해당 사항을 개발자가 노티 받고, 배포를 진행한다.
SealedSecret이라는 걸 알게 되었는데, 이걸 이용하면 개발자가 직접 추가할 수도 있고, git에도 비대칭 암호화된 값이 남아 안전하다고 합니다.
보통 SealedSecret 방식을 적용하여 프로젝트를 운영하나요, 아니면 책임 관리 소재에서 저 과정을 거치나요?
답변 1
0
안녕하세요.
통상 개발자가 쿠버네티스를 모르는 경우가 많습니다. 그래서 devops용으로만 Git Repository를 별도로 관리하기 때문에 평문으로 Secret을 Commit하고, 운영자들 끼리기만 접근 관리하는 게 가장 기본적인 1단계 라고 보시면 됩니다.
이때 평문이 아닌 말씀하신 SealedSecret나 그 외에 Secret의 데이터를 암호화시켜 주는 여러 보안 툴이 있고요. 그걸 사용하는 건, 보안을 중시했을 때의 선택 사항이 되요.
하지만 개발자가 쿠버네티스로 본인의 App을 직접 만들 정도로 성숙해진 팀이라고 했을 때는, DevOps에서 중요 데이터를 안전하게 가이드 해줘야 할 의무가 있고요. 이때 쿠버네티스 내부에 SealedSecret이 적용되 있으니 Secret을 어떻게 만들고 사용하라는 가이드를 줄 수 가 있어요.
근데 이때 운영이라고해서 꼭 어떤 절차로 진행을 해야 된다는 건 없고요. 통상 그런 절차는 각자의 사이트 환경에 따라 담당자가 고민해보고, 정리를 합니다.
그리고 Secret 관련 보안 솔루션은 여러가지가 있는데, SealedSecret도 운영에서 가볍고, 쉽게 사용할 수 있는 방법 중에 하나 이긴 합니다.