[6주차 - Well-Architected 방식으로 워크로드를 안전하게 마이그레이션 및 현대화하기 Workshop ] T101 4기 스터디 (24.07.14)

 

 

 

들어가며

이번 스터디는 HashiCorp 사의 엔지니어이자, T101 3기 스터디 리딩을 해주신 유형욱 님께서 진행하는 특별 세션이었습니다. AWS Workshop Event를 통해 진행되었으며, 사전에 참여자들의 정보를 통해 직접 한 땀 한 땀 실습을 기획하고 배포를 해주셨습니다. 

 

... Shout out, 형욱 님!

 

지난 스터디에서 TFC를 통해 이것저것 해보았기 때문에, 복기(?) 차원에서 들어봐야겠다고 생각했는데 신세계를 맛본 기분이었습니다. Terraform을 이용하여 거버넌스 관리까지 가능하다는 것을 느끼며, IaC 기술의 필요성을 다시 한번 절실히 깨닫게 되었습니다.

 

형욱 님께서 빠르게 워크숍을 진행할 수 있도록, 여러 과정을 자동화해 주셔서 많은 관점에 대한 실습을 빠르게 진행하며 콘셉트를 이해할 수 있었습니다. (준비하시느라 정말 고생이 많으셨을 것 같아요!)

 

아무튼 이번주차 스터디 정리를 시작하겠습니다.

 

---

간략한 HCP 설명

HCP는 HeshiCorp의 Cloud Platform 약자입니다.

TFC를 사용할 때 500개까지의 resource가 무료이고, 그 이후 과금이 발생하더라도 크게 많이 발생하지 않는다고 합니다. 인프라 규모에 따라 다르긴 하겠지만, 설명을 들었을 때 웬만한 외산 SaaS들에 비해 가격 정책이 착한(?) 편이라는 생각이 들었습니다.

 

 

https://www.hashicorp.com/products/terraform/pricing

HashiCorp Terraform: Enterprise Pricing, Packages & Features

 

---

 

워크숍 스튜디오 로그인 - 테라폼 엔터프라이즈 설치형

워크숍 스튜디오링크를 따라 로그인하면 다음과 같이 형욱 님(교육자) 께서 준비하신 일련의 Terraform 실습들을 일목요연하게 확인할 수 있습니다.

 

여기서 소개된 한 가지는 Service Screener라는 툴로 Well-Architectured의 핵심 요소인 보안, 안정성, 운영 우수성, 성능 효율성 및 비용 최적화 모범사례들의 적용여부를 확인할 수 있고, 이를 개선하기 위한 권장사항들을 확인할 수 있다고 합니다.

 

---

 

 

실습 - 컴퓨트 리소스의 attack surface 최소화

첫 번째 워크숍 실습은 attack surface를 최소화하는 방법에 대한 사례였습니다. 

실습환경 - https://github.com/aws-samples/secure-migrations-and-modernizations/tree/main/tf_scenario_code/1_pre-condition-ec2

secure-migrations-and-modernizations/tf_scenario_code/1_pre-condition-ec2 at main · aws-samples/secure-migrations-and-moderniza

 

전체적인 구조는 AWS 리소스(VPC내부에서 AMI 기반으로 EC2 배포)가 Terraform Enterprise를 기반으로 프로비저닝 되어 있는 상황입니다.

 

precondition에서 제한이 걸려있어서 실패하게 실습이 구성되어 있습니다. (허용되는 인스턴스 타입과, 아키텍처 설정이 필요함)

 

[New Run] - [Start] 버튼을 통해 프로비저닝을 시도합니다.

 

실습에서는 프로비저닝 시 ARM CPU로 프로비저닝을 제한하여, 제한을 만족하지 못할 경우 프로비저닝이 실패하도록 하여 조직의 컴플라이언스를 준수할 수 있도록 강제하는 예시를 들었습니다. 프로비저닝시 precondition 체크 항목들을 variable을 조건을 만족하도록 변경시키면 다음과 같이 Plan과 Cost Estimation이 잘 동작하는 것을 확인할 수 있습니다.

 

(중간과정을 남겼으면 좋았을 텐데, 작성하는 시점에서 캡쳐본들이 날아가 버렸네요.. 조건을 만족하지 않으면, 아래의 실습들과 비슷한 형태로 프로비저닝 상태 표시에서 오류가 발생하게 됩니다.)

 

---

 

실습 - Postcondition 추가

2단계인 Postcondition에서는 다음과 같이 Postcondition 절이 main.tf에 추가됩니다.

추가된 내용은 self.root_block_device[0].encrypted 가 true로 설정되어 있어야 한다는 것입니다.

### 기존 코드 생략 ###

resource "aws_instance" "ec2_postcondition" {
  ami                         = data.aws_ami.ubuntu_22.id
  instance_type               = var.instance_type
  associate_public_ip_address = true

  root_block_device {
    encrypted = false
  }

  lifecycle {
    precondition {
      condition     = contains(["t3.micro", "t3.large", "m6i.midium", "m6i.large"], var.instance_type)
      error_message = "허용된 instance_type 은 t3.micro, t3.large, m6i.midium, m6i.large 입니다."
    }
    precondition {
      condition     = data.aws_ami.ubuntu_22.architecture == "x86_64"
      error_message = "AMI 이미지는 aws_instance_type이 x86_64이므로 x86_64 아키텍쳐여야 합니다."
    }
    postcondition {
      condition     = self.root_block_device[0].encrypted == true
      error_message = "root block device는 암호화 설정이 되어있어야 합니다."
    }
  }
  tags = {
    Name = "Ubuntu_22.04_PostCondition"
  }
}

 

실습을 진행하게 되면 self.root_block_device[0].encrypted 가 true로 설정되어 있지 않아 Plan 단계에서 에러가 발생합니다.

 

 

하지만 EC2 인스턴스는 프로비저닝을 수행한 것으로 보입니다.

 

 

블록 디바이스를 확인해 보면 암호화되어 있지 않은 것을 확인할 수 있습니다.

 

이 상황을 해결하기 위해 [postcondition-encrypted] 브렌치로 변경하여 root_block_device 블록의 encrypted를 true로 설정합니다.

### 기존 코드 생략 ###

resource "aws_instance" "ec2_postcondition" {
  ami                         = data.aws_ami.ubuntu_22.id
  instance_type               = var.instance_type
  associate_public_ip_address = true

  root_block_device {
    encrypted = true
  }

  lifecycle {
   ...
  }
  tags = {
    Name = "Ubuntu_22.04_PostCondition"
  }
}

 

적용한 후 다시 [New run] - [Start]를 수행하면 다음과 같이 프로비저닝이 정상적으로 수행된 것을 확인할 수 있고, 

 

 

 

암호화도 정상적으로 적용된 것을 확인할 수 있습니다.

 

 

 

---

 

실습 - 네트워크 트래픽 제어 #1

다음은 네트워크 트래픽 허용을 제한하는 보안적인 컴플라이언스를 준수하도록 강제하는 방법에 대해 실습을 진행했습니다. security groups의 규칙은 최소 권한 액세스 원칙을 따라야 하고,  허용되지 않은 포트를 통해 트래픽이 들어오는 경우에도 액세스를 제한한다는 내용이었습니다.

 

아키텍처는 다음과 같습니다.

두 번째 실습단계로 넘어가서 New run을 실행합니다.

 

terraform plan은 정상적으로 수행됩니다. 하지만 실행계획을 검토해 보면 Security Group의 ingress cidr이 0.0.0.0/0으로 모든 IP에 대해 개방되어 있습니다.

 

 

그래서 시스템을 통한 강제는 아니지만, 관리자가 Apply를 거절하는 형태로 간단히 예시를 실습했습니다.

 

 

---

 

실습 - Security groups 정책 작성 #2

앞의 실습과 마찬가지로 precondition 기능을 통해 Terraform 작성코드 수준에서 Security Group에 대한 정책을 정의하고, 방어할 수 있습니다. 프로비저닝을 취소한 과정에서 Download Sentinel Mock 버튼을 클릭하여 테라폼이 작성한 실행계획을 다운로드하고, https://play.sentinelproject.io 에서 정책을 작성해 봅니다.

 

 

정책은 개별 Policy와 이를 그룹핑하고 적용하는 Policy Set으로 나뉩니다. 먼저 2_sentinel-sg 워크스페이스에 적용할 Policy Set을 생성합니다.

 

 

Security Group의 Ingress에 대한 보안 제약사항으로 0.0.0.0/0 정책을 허용하지 않도록 Policy를 생성하였습니다. 이렇게 되면 이전과 같이 New run을 수행 시 제약 사항으로 인해 프로비저닝이 제한됩니다.

 

Variable을 변경하여 cidr_blocks를 새로 디자인합니다.

 

이번에는 조건을 만족하여 정상적으로 Apply 되는 것을 확인할 수 있었습니다.

 

 

---

 

실습 - ACL이 비활성화된 S3만 프로비저닝

S3 버킷 수준에서 퍼블릭 액세스를 차단하여 오브젝트 퍼블릭 액세스 권한을 갖지 않도록 제어하는 실습을 진행했습니다.

 

아키텍처 오버뷰는 다음과 같습니다.

 

 

 

acl_disabled를 true로 변경하여 ACL을 비활성화하도록 변경하면 정상적으로 apply가 수행되는 것을 확인할 수 있었습니다.

 

 

 

---

 

실습 - Newwork 구성 변경

사용자가 임의로 Security Group의 설정을 변경하였을 때 이를 감지하고 복구하는 방법에 대해 실습했습니다.

 

아키텍처 환경은 다음과 같습니다.

워크숍에 제시된 전체적인 워크플로우는 관리자가 TFC(Terraform Cloud)에 접속하여 리소스를 생성했을 때, 제삼자가 리소스를 변경하여 상태를 임의로 변경하는 것입니다. 그렇게 되면 TFC에서 리소스 변경을 감지하여 관리자에게 이메일을 통해 알림을 전달합니다. 관리자는 TFC를 통해 간단히 리소스 롤백요청을 하게 되고 정상적으로 리소스가 복원되도록 합니다.

 

(가시다님께서 slack alert을 보내는 방법에 대해서도 언급해 주셨는데 해보지 못해 아쉬웠습니다. 작년 스터디 자료에 TFC X Slack 관련 자료가 있었던 걸로 기억해서, 실제 적용은 이러한 구조로 해보려고 합니다.) 

 

 

TFC에서 제공하는 Notifications를 통해 이메일을 수신할 대상을 설정합니다.

 

 

 

이렇게 되면 Terraform에서 plan, apply 또는 이상상황 발생 시 이메일 알림을 받을 수 있도록 설정됩니다.

 

 

다음으로는 기존에 80 포트를 오픈하였던 인바운드 규칙을 삭제하고 81번 포트로 강제 변경을 수행하여 시나리오에서의 3번 과정을 재현해 보았습니다.

 

 

변경된 상태는 TFC에서 감지되어 다음과 같이 Drift가 생성되게 됩니다.

 

 

여기서 복구(new run)을 통해 원래 상태의 Security Group으로 변경이 되는 것을 확인할 수 있었습니다.

 

실습 - 로그파일 무결성 검증 활성화

CloudTrail의 로그 파일 무결성 검증 설정을 고의적으로 변경했을 때 Drift detection을 통해 이를 감지하고 복구하는 과정에 대해서 실습했습니다. 

 

로그파일 활성화를 고의적으로 비활성화합니다.

 

다음과 같이 앞의 실습처럼 차이에 대한 Drift가 생성되고, New run을 통해 복구를 수행할 수 있습니다.

 

 

 

 

---

실습 - Continuous Validation

해당 실습에서는 Web Server가 비정상 동작하는 상황을 Terraform continuous validation 기능을 통해상황을 탐지하는 것을 확인했습니다.

 

전체적인 아키텍처는 다음과 같습니다.

 

 

new run을 통해 apply를 수행하고, TFC의 Continues Validation의 Start health assessment를 설정합니다.

 

다음과 같이 정상적으로 Nginx가 프로비저닝 된 인스턴스에서 정상 실행되는 것을 확인할 수 있습니다.

 

이번에는 실습 가이드에 따라 실행 중인 Nginx를 정지시킵니다.

 

 

TFC의 Health에서 nginx가 정지된 상태를 파악하고 알려줍니다.

 

 

Nginx를 다시 실행시키면 다음과 같이 정상적으로  상태가 통과되는 것을 확인할 수 있습니다. TFC의 Drift Detection 기능을 활용하여 AWS 리소스의 구성 정보에 대한 거버넌스 그리고 Continuous Validation은 OS, 서비스, 애플리케이션에 대해서 지속적인 거버넌스를 가질 수 있습니다.

 

 

---

 

마치며

이번 시간에는  "Well-Architected 방식으로 워크로드를 안전하게 마이그레이션 및 현대화하기 Workshop"을 통해 여러 가지 거버넌스를 준수하는 형태로 인프라를 관리하는 HCP의 기술들을 실습을 통해 체험해 보았습니다.

처음 참가해 본 AWS Workshop Event 툴은 엄청 신기했어요.. 요즘 이렇게 워크숍이 많이 열리나 보군요!

 

테라폼을 사용한 지도 2년이 다 되어가네요, Hashi Corp사에서 저희 회사에 교육차 방문하기도 했었고, 지난 스터디를 이끌어주신 형욱 님 목소리도 많이 들을 수 있어서 반갑고 즐겁고 알찬 3합 스터디였습니다.

 

 

그럼 다음 스터디에서 뵙겠습니다.

감사합니다.