about me
20'S LIFE IN SYDNEY and BUSAN
예상치 못한 인프라의 변경에 따른 사고 (Configuration Drift)
AWS와 같은 클라우드 서비스에 여러분이 인프라 관리자로 일하고 있다고 가정해봅시다.
일반적으로 IAM을 통해 각 팀 또는 개인에게 필요한 만큼의 권한을 주고 인프라를 사용할 수 있게 할 것입니다.
그렇지만 도구를 각자의 손에 쥐어줄 경우 모두가 이를 제대로 사용하라는 법은 없기 마련입니다.
예를 들어, 프로덕션 레벨에 있는 어떤 특정한 인스턴스를 권한을 갖고 있는 누군가가 실수로 삭제해서 제품에 영향을 미칠 경우 이를 어떻게 알아내고, 어떻게 고칠 수 있을까요? 꼭 지우는 것만이 위험 요소가 아닙니다.
어떤 보안 그룹의 설정을 변경하여 시스템 전체에 영향을 미치는 경우는 또 어떨까요?
이처럼, 예상치 못한 인프라 변경에 대한 사고와 미치는 영향을 Configuration Drift 라고 부릅니다.
어떻게 알아내고, 어떻게 고칠까?
사건을 알아내는 방법은 접근 방법에 따라 조금씩 다릅니다. AWS를 기준으로 접근 방법과, 도구를 알아봅시다.
잘못 설정된것을 찾기 위한 도구: AWS Config
- 바른 설정을 지정해놓고, 찾고 고칠 수 있게 만들어준다
사고 감지 도구: AWS CloudFormation Drift Detection
이러한 관리형 서비스 외에 보다 개발 방법에 가까운 솔루션은 다음이 있습니다.
- 정상 작동 상태를 파일로 저장: Terraform state files
Terraform의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있습니다.
Action Items
Chapter - Terraform의 Hands on 까지 따라해본 후 terraform plan 명령이 어떤 명령인지 알아봅시다.
어떻게 방지할까?
불변한(Immutable) 인프라스트럭처는 인프라 변경을 원천적으로 막을 수 있는 방법론입니다. 실제로 인프라를 수동 설정으로 변경할 수 있지만, 다음의 실천적인 방법을 통해 애초에 그 가능성을 막는 것입니다. 원칙들을 살펴봅시다.
한번 생성했으면 수정하지 않는다.
프로비저닝 및 배포했으면, 콘솔에 접속해서 수동으로 설정하지 않습니다.
즉 변경은 삭제 후 생성을 의미합니다.
인스턴스 내부 구성(사용자 스크립트 등)이 필요할 경우 AMI로 만들어 놓습니다.
즉 Develop → Deploy → Configure가 아니라
Develop → Configure → Deploy여야 합니다.
코드형 인프라(IaC)를 사용합니다.
댓글