devops

우리 팀에서는 실제 여러 클라우드 환경에서 서비스를 운영, 테스트하고 있기 때문에 서비스 별로 각기 다른 config 파일을 관리해야 한다. 처음엔 환경마다 Parameter store를 이용해 파일과 key들을 관리했지만 환경에 접속해서 매번 수정하는 게 아주 번거로웠다. 특히나 github action에서 action을 위한 secret 환경변수도 레포마다 관리하는 것이 쉽지 않았다. 이렇게 흩어져있는 설정 파일 혹은 key값들을 중앙화시킬 필요가 있었고, 쿠버네티스를 사용하기 때문에 모든 환경에서 작동하는 컴포넌트의 배포 상태와 흐름을 파악할 수 있어야 했다. 이 요구사항들을 바탕으로 Vault, ECR, ArgoCD가 사용되는 Github action CICD 파이프라인을 구축하게 되었다. EKS..

Vault의 시크릿 엔진은 data를 암호화하고 저장하고 생성하는, 어떤 기능을 하는 유연한 특징을 가진 컴포넌트로 보면된다. 어떤 시크릿 엔진은 단순히 데이터 저장과 읽기만 제공하지만, 어떤 것은 서비스와 연결되어 동적인 Credential을 생성하기도 하고 인증 역할을 하기도 한다. 모든 시크릿 엔진은 볼트의 path를 통해서 활성화된다. 그래서 볼트에 요청이 올때 자동으로 해당 경로로 라우팅되어 처리된다. 시크릿 엔진은 개별 경로(path)와 속성이 정해져있기 때문에 사용하는 유저입장에서는 Virtual Filesystem이라고도 볼 수 있음 Lifecycle Enable : 시크릿 엔진의 경로와 함께 Enable된다. (몇몇 시크릿 엔진은 여러 경로로 Enable이 될 수 있음) 각 시크릿 엔진은..

체인의 키를 안전하게 관리하기 위해서 많이들 사용하는 Hashicorp의 Vault 배포 과정을 간단히 정리해보려고 한다. 사실 볼트 서버를 올리는 것은 간단하지만, Policy나 Secret Engine을 효율적으로 사용하고, Plugin을 적용하는 과정이 쉽지 않다. (관련해서는 다음 포스팅에 하나씩 정리해보려고 함) Vault는 튜토리얼에서 dev 버전으로 간단히 올릴 수 있지만, 데이터를 memory에 저장하고 Unseal 상태가 디폴트기 때문에 실제 프로덕션 단계에서는 적합하지 않다. 아래는 실제 환경의 Vault를 배포하는 것을 정리한다. 1. Configuration Vault 서버의 구성파일을 먼저 작성한다. 아래와 같이 스토리지와 API 요청받을 리스너를 입력해준다. ## config.j..