[Terraform] Multi-Cross-Backend X Multi-Cross-Account = 세분화된 액세스 제어

 

 

테라폼은 대표적인 IaC 도구로 AWS 와 같은 클라우드 환경을 코드로 구성할 수 있다는 장점이 있습니다.

 

그리고 보통 클라우드 환경은 Dev 과 Prod 으로 나뉘게 됩니다. 

 

한편, 테라폼을 이용해서 리소스를 생성하게 되면 backend 라는 곳에 tfstate 를 저장하게 됩니다.

tfstate 는 리소스의 구성 정보를 가지고 있는 파일이고, backend 는 이러한 tfstate 를 저장하는 보관소 입니다.

 

backend 는 로컬이 될 수도 있고, AWS S3 와 같은 오브젝트 스토리지도 될 수 있습니다.

 

한번, AWS S3 에 Demo 버킷을 Dev 환경과 Prod 환경에 같은 코드를 가지고 동일하게 생성한다고 가정해보겠습니다.

 

예제 코드는 여기서 가져왔습니다!

 

사용할 main.tf 는 아래와 같고,

resource "random_pet" "this" {
  length = 2
}

module "simple_bucket" {
  source = "terraform-aws-modules/s3-bucket/aws"
  version = "4.1.2"

  bucket = "kingbj0429-${random_pet.this.id}"

  force_destroy = true
}

 

providers.tf 는 아래와 같습니다.

terraform {
  required_version = ">=1.5.0"

  backend "s3" {
    bucket         = "backend-dev"
    key            = "tfstates/s3/demo-bucket.tfstate"
    region         = "ap-northeast-2"
    profile        = "iam-dev"
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.33.0"
    }
  }
}
provider "aws" {
  shared_config_files      = ["~/.aws/config"]
  shared_credentials_files = ["~/.aws/credentials"]

  profile = terraform.workspace == "dev" ? "s3-manager-dev-role" : "s3-manager-prod-role"
  region  = "ap-northeast-2"

  default_tags {
    tags = {
      terraform   = "true"
      environment = terraform.workspace
    }
  }
}

 

간단하게 backend 구성을 한번 살펴보면,

 

backend 는 "AWS S3" 를 사용하고, "backend-dev" 버킷에 tfstate 파일(오브젝트)을 저장합니다. 이때 저장되는 오브젝트의 키는 "tfstates/s3/demo-bucket.tfstate" 입니다. 그리고 "backend-dev" 버킷 에 대한 액세스 계정으로는 "iam-dev" 를 사용합니다.

 

이후 이제 테라폼의 workspace 기능을 이용해서 dev 와 prod 나눈 후 동일한 .tf 를 이용해서 AWS Dev 와 Prod 환경에 각각 생성해줄 것입니다.

 

init 와 workspace 를 만들어주고,

terraform init

terraform workspace new dev

terraform workspace new prod

 

Dev 환경에 S3 버킷을 생성하고,

$ terraform workspace select dev

$ terraform apply -auto-approve

 

생성된 tfstate

workspace 덕분에 env:/ 로 tfstate 가 따로 저장되는 것을 확인할 수 있습니다.

 

Prod 환경에 S3 버킷을 생성합니다.

$ terraform workspace select prod

$ terraform apply -auto-approve

 

생성된 tfstate

이번엔 env:/ 의 하위 키가 dev 가 아닌 prod 인 것을 확인할 수 있습니다. 

 

그런데, 여기서 간과한 것이 하나 있습니다. S3 가 배포되는 환경은 Dev 와 Prod 가 나뉘어졌지만, tfstate 가 저장되는 backend 는 현재 Dev 환경에 있는 "backend-dev" 버킷입니다. 

Dev 환경의 backend-dev 버킷에 모두 저장됨

 

Prod 환경에 있는 S3 버킷에 대한 tfstate 가 Dev 환경에 있는 것이 뭔가 찜찜합니다... 

 

사실 위와 같이 해도 문제될 것은 하나도 없습니다. 주어진 조건과 환경은 전부 다르기에 정답은 없습니다.

 

그래도 저는 Dev 환경에 대한 tfstate 면 Dev 버킷에, Prod 환경에 대한 tfstate 면 Prod 버킷에 있는 것이 더 깔끔?하다 생각 했고, 무엇보다 Prod 환경과 Dev 환경이 완전히 격리되어야 하는 조건이 있었기 때문에 더더욱 분리하는 것이 맞았죠.

Dev 와 Prod 가 완전히 격리됨

완전히 격리되어야 했기 때문에 AWS 교차 계정 액세스 는 사용하지 않습니다.

 

그래서 이번 글에서는 Multi-Cross-Backend 와 Multi-Cross-Account 를 사용해서 서로 다른 계정으로 서로 다른 backend 에 tfstate 를 저장하는 방법을 알아보고자 합니다.

 

여기서 말하는 Multi-Cross-Account 는 단순히 서로 다른 계정을 사용한다는 의미이지, AWS 교차 계정 액세스 를 말하는 것은 아닙니다!

 

 

렛츠두더코드~

 

Multi-Cross-Backend X Multi-Cross-Account

---

 

providers.tf 을 다시 한번 보죠.

terraform {
  required_version = ">=1.5.0"

  backend "s3" {
    bucket         = "backend-dev"
    key            = "tfstates/s3/demo-bucket.tfstate"
    region         = "ap-northeast-2"
    profile        = "iam-dev"
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.33.0"
    }
  }
}
provider "aws" {
  shared_config_files      = ["~/.aws/config"]
  shared_credentials_files = ["~/.aws/credentials"]

  profile = terraform.workspace == "dev" ? "s3-manager-dev-role" : "s3-manager-prod-role"
  region  = "ap-northeast-2"

  default_tags {
    tags = {
      terraform   = "true"
      environment = terraform.workspace
    }
  }
}

 

provider "aws" {} 스코프 안에는 terraform.workspace 와 같은 variable 이나 삼항연산자 등 을 사용할 수 있지만, terraform {} 스코프 안에는 그 어떠한 것도 사용할 수 없습니다. 

 

그저 하드 코딩만 가능합니다. 따라서 terraform.workspace 를 활용할 수 없습니다.

 

그렇다고 방법이 없는 건 아닙니다. backend "s3" {} 내용을 따로 파일로 뺄 수가 있습니다.

 

dev.hcl 와 prod.hcl

 

그리고 안에는 다음과 같은 내용이 있죠.

#-- dev.hcl
bucket         = "backend-dev"
profile        = "iam-dev"
region         = "ap-northeast-2"

#-- prod.hcl
bucket         = "backend-prod"
profile        = "iam-prod"
region         = "ap-northeast-2"

 

참고로 파일의 확장자는 .hcl 든, .txt 든, 없든 상관 없습니다. 경로 또한 상관 없습니다.

 

이후 providers.tf 는 아래와 수정할 수 있습니다.

terraform {
  required_version = ">=1.5.0"

  backend "s3" {
    key = "tfstates/s3/demo-bucket.tfstate"
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.33.0"
    }
  }
}
provider "aws" {
  shared_config_files      = ["~/.aws/config"]
  shared_credentials_files = ["~/.aws/credentials"]

  profile = terraform.workspace == "dev" ? "s3-manager-dev-role" : "s3-manager-prod-role"
  region  = "ap-northeast-2"

  default_tags {
    tags = {
      terraform   = "true"
      environment = terraform.workspace
    }
  }
}

 

dev.hcl 와 prod.hcl 에 있는 값들은 모두 제거 해준거죠.

 

그럼 아래 명령어를 통해서 backend 의 configuration 을 동적으로 처리할 수 있습니다.

-backend-config=backend-configs/dev.hcl 옵션을 통해 backend 를 backend-dev 버킷으로 설정하는 것이지요.

$ terraform init -backend-config=backend-configs/dev.hcl -reconfigure

 

-reconfigure 옵션에 대해 알고 싶다면 여기!

 

terraform init -backend-config=backend-configs/dev.hcl -reconfigure

 

꼭 terraform workspace show 명령어를 통해 현재 workspace 를 확인하시길 바랍니다!

 

terraform apply 도 마저 실행 한 후 한번 backend-dev 버킷을 확인해보겠습니다.

 

원하는 바대로 잘 생성되었습니다!

backend-dev

 

그럼 이번엔 prod.hcl 를 사용해보겠습니다.

 

workspace 를 옮긴 후에 init 명령어를 해줍니다.

$ terraform init -backend-config=backend-configs/prod.hcl -reconfigure

$ terraform workspace new prod

-reconfigure 옵션은 로컬 backend 구성을 초기화 하기 때문에 새롭게 workspace 를 만들어줘야 합니다!

 

backend-prod 버컷에 생긴 것을 확인할 수 있습니다.

backend-prod

 

이로써 backend 를 분리할 수 있습니다.

dev.tfstate 는 dev 버킷에, prod.tfstate 는 prod 버킷에

 

workspace 는 이용해도 충분히 Dev 와 Prod 환경을 분리할 수 있지만, 위에서 보인 예제처럼 Dev 환경에 있는 backend-dev 버킷에 tfstate 가 저장될 경우, backend-dev 버킷에 대한 액세스만 있으면 충분히 Prod 환경에도 영향을 끼칠 수 있다는 위험성이 존재합니다.

 

예를 들어, A 는 Prod 리소스에 대한 tfstate 를 backend-dev 버킷에 저장하게 되는데, backend-dev 버킷에 대해서는 B 도 액세스 권한이 있습니다. 이때 B 는 Prod 리소스에 접근할 수 있는 권한이 없지만, backend-dev 버킷에 있는 Prod 리소스에 대한 tfstate 은 수정할 수 있습니다. 이는 당연히 보안적으로 매우 좋지 않습니다.

 

그렇다고 완전히 분리하는 것도 좋은 점만 있는 것은 아닙니다. 관리할 것이 많아지기 때문에 복잡성이 올라 갈 수 밖에 없죠.

다시 한번 강요하지만 backend 를 구성하는 방법에는 정답이 없으면 주어진 환경에 맞게 설정하면 됩니다. 

 

그럼 오늘은 여기까지!