서론
이번에 한 프로젝트를 진행하게 되었고 스프링으로 만든 서버를 EC2상에 배포를 하게 되었다. 여러가지 과정을 거쳐 결국
이런 아키텍처로 구축을 하기로 결정을 하였다.
간단하게 설명을 하자면 회원가입 및 토큰 재발급등을 위해 Authorization Server와 Resource Server로 나누었고 토큰의 저장을 위해 redis를 사용했습니다. 그리고 토큰 확인을 위해 api gateway에서 lambda를 이용해 확인을 하였습니다.
AWS Console을 이용해서 하나하나 배포를 하던중 Terraform을 이용하여 Iac(Infrastructure as Code)로 만들면 좋을 것 같다는 생각이 들어 입문을 해보게 되었다.
Terraform 이란?
- Cloud Infrastructure 자동화를 지향하는 코드
- 다양한 클라우드 서비스들을 프로바이더 방식으로 제공
- 테라폼은 고Go 프로그래밍 언어로 개발
만드는 순서
- provider.tf
- iam.tf
- vpc.tf
- security.tf
- private_key.tf
- ec2.tf
- certificate.tf
- dns.tf
- rds.tf
- rds_security.tf
- s3.tf
- elasticache.tf
- elasticache_security.tf
- lambda.tf
- output.tf
- variables.tf
- gateway.tf
- swagger_gateway.tf
저는 위와 같은 순서를 거쳐서 프로젝트를 완성했습니다.
물론 생각보다 다른 블로그들에 많지가 않았고 아키텍처에 따라 코드가 달라졌기 때문에 거의 Document에 의존해서 했던 것 같습니다. 고로 틀린점이 많지만 적으면서 고치면서 공부하겠다는 신념으로 적어보겠습니다.
1. provider.tf(main.tf)
provider "aws" {
region = "ap-northeast-2"
}=> You must configure the provider with the proper credentials before you can use it.
보통 이렇게 region만 쓰는 경우도 있지만
provider "aws" {
region = "us-west-2"
access_key = "my-access-key"
secret_key = "my-secret-key"
}이렇게 access key나 secret key를 같이 등록하는 경우도 있고,
shared configuration and credentials files($HOME/.aws/config)
이런 파일들을 이용해서
provider "aws" {
shared_config_files = ["/Users/tf_user/.aws/conf"]
shared_credentials_files = ["/Users/tf_user/.aws/creds"]
profile = "customprofile"
}이런식으로 등록 해도 되고
IAM Role를 이용해서 이렇게 등록을 해도 된다고 합니다.
provider "aws" {
assume_role {
role_arn = "arn:aws:iam::123456789012:role/ROLE_NAME"
session_name = "SESSION_NAME"
external_id = "EXTERNAL_ID"
}
}하지만 저는 그냥 aws configure를 이용해서
이런 방식으로 secret과 access key를 적어놓았습니다.
자세한 내용은 (https://registry.terraform.io/providers/hashicorp/aws/latest/docs) 테라폼 document를 확인하시면 됩니다!.
2. IAM
사실 위에서 이미 콘솔을 이용해서 키를 받았어서 (먼저 다 만들어보고 그것을 테라폼으로 바꾸는 과정 이었어서..)
테라폼을 이용해서 IAM을 만들고 뭐 하는 방법도 있긴 있던데 조금더 공부를 해보고 포스팅 하도록 하겠다.
일단 IAM을 이용해서 추후에 사용할 Lambda를 위한 role을 만들어 볼 것이다.
resource "aws_iam_policy" "my_policy" {
name = "my_policy"
path = "/"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
})
}name - name of the policy. If omitted, Terraform will assign a random, unique name.
name_prefix - Creates a unique name beginning with the specified prefix. Conflicts with name.
path - (default "/") Path in which to create the policy.
policy - (Required) The policy document. This is a JSON formatted string.
Version
default: 2008-10-17, (2012-10-17 고정)
Statement:
권한 부여 규칙(Rule 혹은 Policy)의 나열
Effect
enum: Allow | Deny
허용한다는 규칙인지, 불허한다는 규칙인지 구분
Action
string | Array
하나 혹은 여러 개의 Action을 지정할 수 있습니다.
AWS 서비스에 사용되는 작업, 리소스 및 조건 키
각 서비스별로 고유의 서비스 접두사(예: DynamoDB는 dynamodb)가 있습니다.
위 설명서에서 각 서비스를 선택해서 들어가면 XX에서 정의한 작업이라는 단락에 작업 목록이 있습니다.
Action은 (서비스 접두사):(작업) 형식으로 작성합니다.
예: dynamodb:DeleteItem, s3:GetObject 등
Resource
Statement의 주제가 되는 리소스를 한정(qualify)합니다.
서비스에 따라서 이렇게 해당 서비스에 속한 하부 리소스 단위까지 한정할 수 있습니다. (DynamoDB의 테이블 수준까지 한정)
[출처: https://musma.github.io/2019/11/05/about-aws-iam-policy.html]
resource "aws_iam_role" "my_role" {
name = "my_role"
path = "/"
assume_role_policy = <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
}권한이라 하면 정책(Policy)에 부여하는 권한과 같은 것을 의미한다.
역할의 큰 특징은 IAM 사용자나 IAM 그룹에는 연결되지 않는다는 것이다
=> 누가 이 역할을 맡을 수 있는지 담당자(Principal)를 지정해야 하는 신뢰 정책(Trust Policy)이 추가되어야 해당하는 IAM 사용자나 AWS 리소스가 역할을 얻을 수 있다.
[출처: https://jonnung.dev/posts/2021-01-28-aws-iam-role/]
resource "aws_iam_role_policy_attachment" "cortex_auto_scale_role_attach" {
role = aws_iam_role.my_role.name
policy_arn = aws_iam_policy.my_policy.arn
}=> Attaches a Managed IAM Policy to an IAM role
