Vault

Vault를 구글 인증을 통해서 로그인하도록 설정해본다. Admin Directory API를 통해서 workspace의 user와 group의 정보를 가져올 수 있고, 해당 정보를 통해서 인증 조건을 추가할 수 있다. 예로 특정 workspace group에 속한 계정만 인증에 성공할 수 있도록 조건을 추가할 수 있다. Admin Directory API에 요청하기 위해서 필요한 권한을 설정할 수 있는데, Service Account의 key 파일을 생성하는 대신에, Application Default Credentials를 활용해보았다. Application Default Credentials를 사용하는 과정에서 삽질을 많이 했는데, 혹시나 동일한 작업을 하는 분들은 나처럼 시간을 허비하지 않기를 바라며 글을 작성한다.🥹

Vault에서 다양한 credentials를 보관하게 된다. 따라서 어떤 접근들이 있었는지 Audit Log들을 남겨서 관리하고 싶었다. Vault에서 Audit Device 기능을 제공하여서 file, syslog, socket등으로 Vault API 요청과 응답을 로그로 남길 수 있다. socket은 log 손실의 위험이 있고, syslog는 Vault Pod에서 추가적인 package설치와 설정이 필요하다. 따라서 Kubernetes에서 Vault를 운영하는 과정에서 file 방식으로 Audit log를 남겨보았다.

Vault의 secret engine을 사용하여 네이버 클라우드의 임시 인증키를 발행하고 싶었다. 네이버클라우드는 AWS, Azure처럼 builtin plugin으로 제공하지 않는다. 하지만 custom secret engine을 vault framework SDK를 통해서 쉽게 만들 수 있다. 네이버 클라우드에서 STS API를 제공하기 때문에, custom secret engine을 통해서 임시 인증키를 발행하는 것을 테스트 해보게 되었다. 처음에 구조를 이해하는데 좀 시간이 걸렸지만, Vault Tutorial에서 친절하게 설명하고 있어서 비교적 쉽게 만들 수 있었다.

GitOps에서 Secret을 어떻게 관리할지 고민을 하였고, 개발자들의 인지부하를 줄이기 위해서 Vault UI로 자신의 앱의 비밀값을 관리하는 것이 제일 효율적이라는 판단을 했다. Vault secrets operator가 GA로 공유가 되었고, Secrets Store CSI나 External secrets 프로젝트보다 깔끔한 방식이라는 생각이 들었다. Vault secrets operator의 CRD로 vault secret과 kubernetes secret의 sync를 맞추고, reloader로 secret이 변경되었을 때 다시 pod를 배포하는 것을 테스트해보았다.