쿠버네티스에선 컨피그맵과 시크릿을 통해 환경변수나 파일을 전달해줄 수 있습니다. 특히 민감한 정보인 경우 시크릿을 통해 배포하게 됩니다. 하지만 시크릿은 문제가 하나 있습니다. 이름은 시크릿인데.. 인코딩만 해줄뿐 전혀 시크릿스럽지 못합니다. 따라서 시크릿을 사용하는 Helm Chart 을 생성한 후, 깃허브에 올리게 된다면 결국 그 시크릿 값은 그대로 노출됩니다. 프라이빗 레포지토리라 해도, 민감한 정보는 깃 허브에 올리면 안된다고, 깃헙 자체에서도 가이드합니다 그럼 이런 시크릿을 어떻게 시크릿스럽게 사용할 수 있을까요? 다행히 이미 좋은 솔루션이 존재합니다. 바로 HashiCorp 의 Vault 입니다. Vault 는 Secret Manager 시스템으로 이름 그대로 시크릿을 관리해주는 시스템입니다...

Iptables 를 알아보기 전에 먼저 Netfilter 에 대해 알아보죠 ! Netfilter 와 Iptables AWS EC2 인스턴스를 생성할 때 Security Group 이라는 것을 설정합니다. 이름 그대로 외부로 들어오는 트래픽을 조절할 수 있게 해주는 방화벽 기능이죠. EC2 인스턴스 앞단에 이를 처리해주는 아마 물리적인 기계가 있어서 어떤 트래픽은 허용하고, 어떤 트래픽은 거부하겠죠. Security Group 이 하드웨어 방화벽 이라면 Netfilter 는 소프트웨어 방화벽이라고 생각하면 이해하기 쉽습니다. Netfilter 는 다음과 같은 특징이 있습니다. 소프트웨어 방화벽 패킷 필터링 리눅스 커널 내부의 프레임워크 포트 주소, 변환, 포트 포워딩 및 패킷 변경 라우팅 전후에 데이터 및..

왜 Helm 을 사용하나요? Helm 이 무엇인지 알아보기 전에 왜 필요한지 먼저 알아보죠 ! 🧐 Consistency 쿠버네티스에 리소스를 배포하려면 아래 이미지처럼 yaml 로 작성해주어야합니다. yaml 이 1,2 개라면 관리가 어렵지 않겠지만 10개 정도만 되도 관리하기가 매우 힘들고 불편해집니다. 또한 kubectl edit을 통해 쿠버네티스의 리소스를 업데이트 해줄 수 있는데, 여러 개발자가 관리를 하게 된다면 일관성(Consistency) 문제가 발생할 수 있습니다. Revision History 어떠한 애플리케이션이 Deploy, ConfigMap, Service, Ingress yaml 로 배포된다고 가정해보죠. 이때 ConfigMap 과 Service 가 업데이트 되어서 yaml 이 변..