개요
본 문서는 HashiCorp Strategy Day 2024에 대한 개인적인 소감을 적었습니다.
2023년도 방문 이후 다양한 문제를 마주하면서
2024년에 방문하였을 때는 더욱 많은 주제들에 공감이되었기에 신기한 경험이었습니다. 실제로 도입하여 안정성 & 생산성 향상이 가능한 IaC 기법들을 몇 가지 알게되어 특히 재밌었습니다.
HashiCorp Strategy Day 2023
HashiCorp Strategy Day 2023에서는 조금 더 추상적인 아젠다를 다뤘던 것 같습니다.
전통적인 네트워크 신뢰 모델과 DMZ 그리고 그 한계점
제로 트러스트 모델이 무엇이고 어떤 특징을 가지는지
신원(Identity) 기반의 인증 체계
Human, Machine, Machine to Machine, Machine to Human
당시에는 Terraform으로 인프라를 마이그레이션, 배포 마이그레이션 하는 것에 집중을 하던 시기였기 때문에 그냥 신기한 느낌이 들었던 것 같습니다.
HashiCorp Strategy Day 2024
전체적으로 Terraform, Vault 운영 전략에 대해서 HashiCorp 측과 고객 사례를 들을 수 있어서 좋았습니다. 특히 올해 HashiCorp 측 발표는 조금 더 유익한 정보 전달에 가까웠다고 느낍니다.
2년 정도 Terraform Community를 쓰고 있고 보안 강화를 위해서 Vault Dedicated를 쓰고 있는 상황에서 주제가 적합하게 맞아 떨어져서 더 유익하다 느꼇습니다.
Vault의 다양한 Secrets Engine을 통합해서
“생산성과 보안을 모두 끌어올릴 수 있는 기술을 기르면 재밌겠다”라고 느꼈습니다.
Terraform
Terraform Enterprise 및 HCP 환경에서 어떤 기능들을 사용하시는지 알 수 있는 좋은 시간이었습니다.
PaC : Policy as Code
CaC : Cost as Code
TaC : Test as Code
CV : Continuous Validation
PaC : Policy as Code
License : Terraform Enterprise, HCP
Sentinel에 대한 내용은 주로 HashiCorp Sentinel Docs에 있었습니다.
Sentinel은 특이하게 HCL*이 아니라 Sentinel Language라는 독자적인 언어를 추가로 사용하는 것으로 보였습니다.
HCL* : HashiCorp Configuration Language로 Packer, Vagrant, Terraform, Vault 등의 다양한 HashiCorp 제품군에서 사용되는 언어입니다.
2017년 첫 릴리즈 이후로 꾸준히 몇 가지 기능들이 추가되고 있는 것으로 보입니다.
다만 아직도 1.0.0 버전이 아니라 마이너 버전들로만 릴리즈 하는 것은 왜일까요?
HCL 언어로 작성된 *.hcl 파일로 Sentinel 설정을 주입하고
Sentinel Language 언어로 작성된 *.sentinel 파일로 실제로 제약 조건을 거는 것 같았습니다.
실제로 어떤 Policy as Code를 구현하는 예시가 있는지 정확히 모르겠으나
HashiCorp/learn-sentinel-write-policy 부분에서는 Terraform Module 안에 Input Validation을 하는 것으로도 충분히 비슷한 목적 달성이 가능하다고 느꼈습니다. 그리고 Gruntwork.io/Terratest로 이미 테스트 코드 기반의 지속적 테스트를 진행하고 있기 때문에 더욱 의아했습니다.
만약 AWS, GCP, Azure 등에 대한 Sentinel Policy Preset이 준비되어 있으며
이들을 Best Practices로 삼아서 우선적인 규정 강제가 가능한 구조이면서 HCL 혹은 Terraform Enterprise를 사용하고 있다면 좋은 기능같이 느껴졌습니다.
다만 Sentinel Language를 추가로 사용하게 되는 부분은 조금 넌센스였습니다.
만약 여러가지 Preset이 준비되어 있으며
이 Preset들로 AWS, GCP, Azure 등에 대한 규정(Compliance)들을 우선적으로 할당할 수 있는 기능 부분이 있다면 충분히 매력적으로 보였습니다.
CaC : Cost as Code
비용 보고서를 쓸 때 피곤한건 역시 비용 절감액(예상액)을 잡는 것 같습니다.
이 금액을 산정할때 가급적이면 실제 비용 기반으로 하거나 예상 비용을 기준으로 잡습니다. 이 경우에 가장 시간이 많이 드는건 AWS Price Calculrator였습니다.
terraform plan과 apply 사용해서 비용 추이를 볼 수 있으면
리소스 타입, 계층형 티어 적용, 리소스 수량 등의 변경으로 인한 비용 변동 추이를 쉽게 확인할 수 있어서 좋아보였습니다.
TaC : Test as Code
Terraform 작동 전체 과정에서 테스트를 통합할 수 있는 것도 매력적으로 보였습니다.
다만 현재는 Terraform Input Validation는 작동 과정에서 도입하였으며, GitHub Action 등의 CI 툴에서 TFLint, Terratest로 코드 품질을 유지하고 있습니다.
Input Validation
Pre/Post Condition : Individual resource, Datasource, Output
Checks : Entire Configuration, Post-plan/apply
Test : Module, separate from plan/apply
이 방식에 대비해서 내장 Terraform Test 기능은 점진적으로 더 도입해서 사용해봐야 장단점을 명확하게 느낄 수 있을 것 같습니다.
Terratest는 진짜 말도안되게 빨라서 편하고 Terraform Code에 diff가 없으면 pass되기도 해서 너무 편한걸…
CV : Continuous Validation
아래와 같은 부분이 테스트 되는 것은 조금 신기했습니다.
Terraform으로 표준화를 해서 잘 만들었는데 누가 수동으로 변경하거나
작동하지 않는 리소스가 있는지 확인하거나
생성 조건을 확인하거나
서비스 상태를 확인하거나
Vault
사실 Vault에 대해서 이야기하는 사람을 많이 보지는 못했던 것 같습니다.
제가 속한 회사의 규모가 작고 다른 인프라 엔지니어와 이야기를 많이 안하는 탓이겠죠.
최근에 민감성 정보를 다루다보니까 이거 이런식으로 관리해도 되나?라는 생각이 많이 드는 것 같습니다.
IAM User CLI Credential, SSM Parameter Store, K8s Secrets & ConfigMap, EC2 KeyPair, GitHub Presonal Key & Credentials…
민감한 정보는 끝이 없지만
오래된 민감성 정보를 갱신하고자 하면 “어디에서 환경변수 쓰고 있는지 몰라서 교체하기가 가히 난감하다”라는 느낌을 받습니다.
특히 EC2 KeyPair는 이런 작은 규모에서도 수백개나 있는데
“더 큰 회사는 수천개, 수만개나 있을텐데 이걸 일일히 관리하는게 말이나되나?”라는 생각도 정말 많이 합니다.
ACL Policies를 기반으로 동작하며,
권한 체계를 세분화할 수 있는 Vault Dedicated에 대한 PoC를 하고 도입함으로써 일부 문제가 해결되기는 했습니다. 하지만 이번 컨퍼런스에서 그 다음 스텝을 확인할 수 있어서 좋았습니다.
Vault Radar
작업을 하다보면 진짜 이상한 곳에 이상한 민감성 정보가 있습니다.
Confluence, Jira, GitHub, SSM Parameter Store, Secrets
민감성 정보에 대한 감지 및 알림이 자동으로 된다는 부분은 꽤 매력적인 선택지처럼 보입니다.
Datasource : Confluence Cloud, GitHub, GitLab, BitBucket, …
Alerting : Slack, MS Teams, PagerDuty, Splunk, …
Ticket : Jira, ServiceNow
다만 Confluence Cloud만 지원을 한다는 점이 좀 아쉬운 것 같습니다.
실제로 Vault Radar를 사용해서 작동 프로세스를 확인해보고 싶은 마음이 조금 있습니다. 추후 PoC 진행하면서 살펴보면 좋아 보입니다.
Vault
Vault에는 기본적으로 손쉽게 사용 가능한 KV Secrets Engine 외에도 다양한 플랫폼과 연동하여 사용할 수 있는 기능이 많습니다.
수많은 Secrets에 대한 Inventory*에 대한 기능 뿐만 아니라 Static Secret, Auto-rotated Secrets, Dynamic Secrets까지 조금 더 안전한 클라우드 환경을 지금 작업 중인 CI/CD Pipeline과 개발자 분들의 작업 환경 개선에 사용될 수 있을 것 같아 보였습니다.
키 교체를 주기적으로 자동으로 진행하면서
인프라 및 개발자 다운타임 없이 진행할 수 있는 환경을 구축하는 것도 재밌어 보입니다.
