chnh.dev

AWS 인스턴스 메타데이터와 IMDS

chnh — Thu, 7 Sep 2023 17:09:45 +0900

들어가며

2019년 미국의 대형 금융지주회사 캐피탈 원이 해킹을 당해 1억명이 넘는 고객의 정보가 유출된 사례가 있습니다. 캐피탈원은 AWS를 사용중이었고, 공격자는 서버측 요청 위조 공격(SSRF) 취약점)을 이용해 AWS EC2의 인스턴스 메타 데이터 서비스(IMDS)에 액세스하여 AWS Access Key에 접근할 수 있었습니다.

애플리케이션 보안을 위한 WAF가 설정되어 있었으나 공격을 차단할 수 있는 적절한 설정이 되어있지 않았고, 자격 증명을 사용해 고객 정보가 저장된 S3 버킷에 액세스 할 수 있었습니다. (참고: Case Study: AWS and Capital One, https://sarangcho.co.kr/142 )

IMDS가 무엇이길래 액세스 정보까지 알아낼 수 있었던걸까요?

인스턴스 메타데이터와 IMDS

인스턴스 메타데이터는 말 그대로 인스턴스에 대한 데이터입니다. 이 데이터를 사용해서 인스턴스를 구성하거나 관리 할 수 있고 사용자 데이터(user data)에도 액세스 할 수 있습니다.

인스턴스를 시작하는 데 사용되는 AMI ID, 인스턴스와 연결된 IAM 역할의 정보, 인스턴스와 연결된 IAM 역할이 있는 경우 역할의 이름과 역할과 연결된 임시 보안 자격 증명도 메타데이터에 포함됩니다.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials

위와 같은 인스턴스 메타데이터를 조회하는 서비스를 인스턴스 메타데이터 서비스, IMDS(Instance Metadata Service)라고 합니다.

예를 들어 A 인스턴스가 있다면, A 인스턴스 내에서만 인스턴스 메타데이터와 사용자 데이터에 접근할 수 있습니다. 다른 인스턴스에서는 A인스턴스 메타데이터에 접근할 수 없지만, A인스턴스에 직접 액세스 할 수만 있다면 그게 사용자이든, 인스턴스에서 실행중인 소프트웨어든 관계없이 메타데이터를 볼 수 있습니다.

이말인 즉슨 ❗️공격자가 인스턴스 메타데이터에 접근할 수 있다면 임시 보안 자격 증명에 액세스할 수 있다는 뜻입니다.

인스턴스 메타데이터에서 IAM 자격증명을 탈취하는 방법 (출처: https://securitylabs.datadoghq.com/articles/misconfiguration-spotlight-imds)

실습 준비

위 내용을 인지한 상태로 실습을 진행해보겠습니다. 제공해주신 CloudFormation을 사용해 실습 환경을 구성했습니다.

가지고 있는 SSH Keypair를 선택하고, 마지막 단계에서 IAM 리소스 생성 승인을 체크하고 실행합니다.

스택 실행이 완료되면 WebServer, Attacker 2개의 EC2가 생성됩니다. 두 인스턴스 모두 80,22 번 포트에 대해 모든 IP를 허용하도록 설정되어 있습니다.

여기서는 WebServer EC2의 메타데이터 서비스를 사용해 임시 자격 증명을 발급받고, Attacker인스턴스에서 WebServer의 임시 자격 증명을 사용해 S3에 접근하는 실습을 진행합니다.

WebServer EC2에는 IAM 역할이 연결되어 있으나 Attacker 인스턴스는 그렇지 않습니다.

IAM 자격증명 설정 되어 있는 PC에서 AWS CLI를 사용해 각각의 EC2 정보를 확인해보겠습니다.

# 생성된 EC2의 IP 출력
aws cloudformation describe-stacks --stack-name iamlab --query 'Stacks[*].Outputs[*].OutputValue' |jq

출력한 IP를 사용해 EC2에 접속합니다.

ssh -i <ssh-keyname>.pem ec2-user@<위 출력 IP>

1. 인스턴스 메타데이터 조회

[WebServer]

1. IMDS의 IP주소인 169.254.169.254를 사용해 실행중인 인스턴스의 메타데이터에는 어떤 것들이 있는지 확인해보겠습니다.

ami-id, iam 등 조회할 수 있는 인스턴스 메타데이터 범주들이 표시됩니다.

curl -s http://169.254.169.254/latest/meta-data/

2. 여기서 iam 정보를 호출하면 인스턴스에 연결된 IAM 역할 이름을 반환합니다.

curl -s http://169.254.169.254/latest/meta-data/iam/info

3. 2에서 획득한 IAM 역할 이름을 사용하여 임시 자격 증명을 발급해보겠습니다. Accesskey, Secretkey와 Token 정보가 모두 출력됩니다.

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/IAMLabInstanceRole | jq

2. 메타데이터를 통해 얻은 임시 자격 증명 사용

[Attacker]

1. Attacker EC2에 접속해 S3 버킷 목록을 나열해보겠습니다.

aws s3 ls

자격증명이 없기 때문에 aws configure을 사용해 자격증명을 구성하라는 안내가 출력됩니다.

2. WebServer 인스턴스에서 탈취(?)한 임시 자격증명을 설정하고, S3 버킷 목록을 나열해보겠습니다.

# 위에서 출력된 AccessKeyId , SecretAccessKey , SessionToken 으로 임시자격증명 적용
export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
export AWS_SESSION_TOKEN=${AWS_SESSION_TOKEN}

# s3 버킷 조회
aws s3 ls

버킷 목록이 정상적으로 출력됩니다.

3. EC2에 연결된 IAM 역할은 없지만 WebServer 인스턴스의 임시 자격증명을 사용해 S3 버킷 목록 나열이 가능했다는 것을 알 수 있습니다.

# 어떤 인스턴스의 ID와 역할인가?
aws sts get-caller-identity | jq

3. CloudTrail 로그 활성화

AWS상에서 일어나는 모든 동작들은 API성으로 이루어져 CloudTrail에 기록됩니다. CloudTrail 콘솔에서 AssumeRole API 호출에 대한 기록을 살펴보겠습니다.

AssumeRole 이벤트란?
사용자 또는 AWS 서비스가 IAM 역할을 맡을 때 생성되는 이벤트로, 역할이 수임되면 API 요청에 사용할 수 있는 임시 보안 자격 증명이 발급됩니다.

언제 어디서 어떤 주체에 의해 이벤트가 발생했는지 상세하게 기록된 것을 확인할 수 있습니다. 작업 주체, 발급된 자격증명 정보 등의 내용이 포함됩니다. 특정 동작을 필터링해서 알람을 받도록 설정하는 것도 자격 증명이 남용되는 것을 방지하는 하나의 방법이 될 수 있을 것 같습니다.

4. IMDS 취약점 해결 방안

1. 인스턴스 메타데이터를 요청할 때 IMDSv2를 사용해야 하도록 설정

인스턴스 메타데이터에 접근할 때 IMDSv1과 v2 모두 사용할 수 있지만 OWASP에서는 보안상 IMDSv2를 사용하는 것을 권장하고 있습니다.

인스턴스 메타데이터 서비스 버전 1(IMDSv1) - 요청/응답 방법
- EC2인스턴스에서 IMDS에 요청하면 요청 결과에 대해 응답을 보냅니다.

인스턴스 메타데이터 서비스 버전 2(IMDSv2) – 세션 지향 방법
1. 소프트웨어는 IMDSv2에 대한 HTTP PUT 요청으로 세션을 시작
2. IMDSv2는 EC2 인스턴스에서 실행되는 소프트웨어에 비밀 토큰을 반환
3. 소프트웨어는 해당 토큰을 암호로 사용하여 IMDSv2에 메타데이터 및 자격 증명을 요청
4. 토큰을 사용하는 프로세스가 종료되면 세션과 해당 토큰 삭제

콘솔에서 [인스턴스 설정] > [인스턴스 메타데이터 옵션 수정] > [인스턴스 메타데이터 서비스] 에서 IMDSv2 를 필수로 설정합니다.

# IMDSv1
curl http://169.254.169.254/latest/meta-data/

# IMDSv2
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/

IMDSv1의 명령어로 호출하자 401-Unauthorized 에러가 발생합니다.

IMDSv2 명령어로 호출하자 정상적으로 메타데이터 범주가 출력됩니다.

IMDSv2 명령어를 사용해 ami-id를 확인해보겠습니다.

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id

ami id가 정상적으로 출력됩니다.

모든 인스턴스에 콘솔 클릭클릭 노가다를 하는 것은 상당히 비효율적이기에 IAM 정책 또는 SCP에서 IAM 조건 키를 사용하여 IMDSv2를 사용해야 하도록 구성된 경우에만 인스턴스를 시작할 수 있도록 설정하는 방법도 있습니다.

{
    "Version": "2012-10-17",
    "Statement": [
               {
            "Sid": "RequireImdsV2",
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringNotEquals": {
                    "ec2:MetadataHttpTokens": "required"
                }
            }
        }
    ]
}

2. IMDS 비활성화

콘솔에서 [인스턴스 설정] > [인스턴스 메타데이터 옵션 수정] > [인스턴스 메타데이터 서비스] 항목을 비활성화하여 인스턴스에서 IMDS를 사용하지 못하도록 설정할 수 있습니다.

[Webserver] 인스턴스에서 메타데이터 서비스를 비활성화하고 다시 메타데이터를 조회해봤습니다. 전과 달리 403 - Forbidden 에러가 발생합니다.

3. IMDS 액세스 제한

로컬 방화벽 규칙을 사용해 IMDS의 IP주소인 169.254.169.254 자체에 접근하지 못하도록 설정할 수 있습니다. (참고: IMDS 액세스 제한)

마치며

부끄럽지만 인스턴스 메타데이터 옵션에 이렇게 다양한 정보가 존재하는지, 해킹의 포인트가 될 수 있다는 사실을 모르고 살았습니다. 공격자의 입장에서 생각해보는게 보안을 강화하는 첫걸음이라는 생각이 들었습니다. 스터디 2주차밖에 되지 않았지만 생각의 지평이 크게 확장되고 있다는 느낌이 듭니다.

더불어 정답이 없다는 생각도 들어요. 그래서 더 어려운 것 같습니다.

제가 있는 회사에서는 SSM(Session Manager)를 사용한 인스턴스 접속이 액세스 키를 관리할 필요가 없기 때문에 보안상 우수하다고 여기는데, 분리되지 않은 단말기에서 인스턴스에 접근 가능하기 때문에 SSM 사용을 제한해야한다는 의견도 있더라구요. 다들 어떻게 사용하고 계시는지 궁금합니다. !

+) 스크린샷에 있는 EC2와 기타 정보들은 모두 삭제된 리소스입니다.

CloudNet@팀의 AHSS(AWS Hacking & Security 스터디) 학습 내용과 제가 공부한 내용을 정리한 글입니다.
더 좋은 방법이나 틀린 내용이 있으면 말씀해주세요 :)

AWS S3 취약점 및 보안

chnh — Sat, 2 Sep 2023 18:31:43 +0900

들어가며

S3(Simple Storage Service)는 AWS의 무제한 객체 기반 스토리지 서비스입니다. 데이터 레이크, 웹 사이트, 모바일 애플리케이션, 백업 및 복원, 빅 데이터 분석 등 다양한 용도로 사용이 가능한 AWS의 대표 서비스 중 하나인데요, 널리 사용되는 만큼 S3 데이터 유출 사고 역시 빈번하게 발생합니다.

S3는 다양한 방법의 접근 제어 및 관리 기능을 제공하고 있어 세분화된 제어가 가능합니다. 다소 복잡할 수 있기 때문에 상황에 적절한 방법을 택해 사용할 수 있어야합니다.

1주차에서는 S3 접근을 통제하는 방법을 알아보고 통제 방법에 따라 다양한 조건에서 실습을 진행했습니다.

실습 준비

AWS 자격 증명이 구성되어 있는 로컬PC와 AWS 자격 증명이 구성되지 않은 EC2가 필요합니다.

(AWS 환경 구성은 스터디장인 가시다님이 제공해주신 CloudFormation 스택을 사용해 배포했습니다.)

S3의 접근 통제

기본적으로 버킷, 객체 등 모든 S3 리소스는 프라이빗으로 생성되며, 이를 생성한 계정인 리소스 소유자만 해당 리소스에 접근할 수 있습니다.

S3의 접근 통제 옵션은 크게 리소스 기반 정책과 사용자 기반 정책(IAM)으로 나눠 볼 수 있습니다. ACL이나 버킷 정책은 리소스 기반 정책으로, IAM 정책은 사용자 기반 정책으로 생각할 수 있습니다. 이 두 옵션을 조합해서 사용할 수도 있습니다.

리소스 기반 정책 - 버킷 정책과 ACL(액세스 제어 목록)

사용자 정책 - IAM으로 S3 리소스에 대한 액세스 관리

객체&버킷 ACL(권장하지 않음): 액세스 제어 목록(ACL)을 사용하여 개별 객체 or 버킷에 대한 액세스를 제어
버킷 정책: 단일 S3 버킷 내 모든 객체에 대한 권한 구성, (특정 작업, 요청 IP 등 다양한 조건을 기반으로 제어 가능)
IAM 정책: 사용자의 S3 액세스 관리

✔️ 만약 리소스 기반 정책과 사용자 기반 정책이 상충한다면 어떻게 될까요 ?

동일 계정 내인지, Cross Account 상황인지에 따라 결과가 달라집니다.
내가 접근하려는 리소스가 내 계정안에 있는 리소스라면 리소스 기반과 정책 사용자 기반 정책의 합집합이,
접근하려는 리소스가 다른 계정에 위치했다면 리소스 기반과 정책 사용자 기반 정책의 교집합이 적용됩니다.
참고: https://youtu.be/zIZ6_tYujts?si=8jgNsINzq3zSvWJU&t=905

1. S3 취약점

버킷 ACL, 객체 ACL 활성화 유무와 버킷 정책을 사용하여 테스트했습니다.

1. 버킷 생성과 '모든 퍼블릭 액세스 차단'

실습을 위해 S3 버킷을 먼저 생성해보겠습니다.

저는 IAM 자격증명이 설정 되어 있는 ️ 로컬 PC의 터미널에서 AWS CLI로 버킷을 생성했습니다.

aws s3api 명령어는 aws s3 보다 더 세분화된 내용과 작업을 가능하게 합니다.

# 버킷 생성
NICKNAME=<자신의닉네임>
aws s3 mb s3://ahss-$NICKNAME --region ap-northeast-2

버킷을 생성하면 기본적으로 퍼블릭 액세스가 차단되어있습니다.

aws s3api get-public-access-block --bucket ahss-$NICKNAME | jq

S3 콘솔 [권한] 탭에서도 확인이 가능합니다.

이제 로컬 PC에서 파일을 만들어 S3로 업로드 해보겠습니다.

# 파일 생성
echo "memo1" > memo1.txt
echo "memo2" > memo2.txt
echo "memo3" > memo3.txt

# S3로 업로드
aws s3 cp memo1.txt s3://ahss-$NICKNAME
aws s3 cp memo2.txt s3://ahss-$NICKNAME
aws s3 cp memo3.txt s3://ahss-$NICKNAME

퍼블릭 엑세스가 차단되어 있지만 IAM 자격증명이 설정되어 있는 상태이기 때문에 정상적으로 파일이 업로드 됩니다.

이제 업로드 된 객체들을 확인해 보겠습니다.

✅ 모든 퍼블릭 액세스 차단 활성화 상태

EC2 (IAM 자격증명 X)

EC2에는 자격증명이 구성되지 않은 상태

# 업로드 객체 확인 
aws s3 ls s3://ahss-$NICKNAME --human-readable

모든 퍼블릭 액세스 차단 활성화 / EC2 / 자격증명 X

# 서명 없이 업로드 객체 확인 
aws s3 ls s3://ahss-$NICKNAME --human-readable --no-sign-request

--no-sign-request 옵션은 AWS 서비스 엔드포인트에 대한 HTTP 요청 서명을 비활성화하는 부울 스위치입니다. 이렇게 하면 보안 인증이 로드되는 것을 방지할 수 있습니다. 해당 옵션값을 주자 아예 bucket을 찾지 못합니다.

모든 퍼블릭 액세스 차단 활성화 / EC2 - 자격증명 X / --no-sign-request 옵션 추가

✅ 모든 퍼블릭 액세스 차단 활성화 상태

️ PC (IAM 자격증명 O)

IAM 자격증명이 설정되어 있어 정상적으로 조회가 가능합니다.

모든 퍼블릭 액세스 차단 활성화 / PC - 자격증명 O

서명을 비활성화하자 Access가 거부되는 것을 확인할 수 있습니다.

모든 퍼블릭 액세스 차단 활성화 / PC - 자격증명 O / --no-sign-request 옵션 추가

객체 URL을 사용해 웹으로 접근하면 AccessDenied가 표시됩니다.

모든 퍼블릭 액세스 차단 활성화 / 객체 URL로 접근

2. 콘솔에서 버킷의 퍼블릭 액세스를 차단을 해제해보겠습니다.

모든 퍼블릭 액세스 차단 비활성

EC2 (IAM 자격증명 X)

버킷의 모든 퍼블릭 액세스 차단 설정을 비활성화 했으나 결과는 동일합니다.

모든 퍼블릭 액세스 차단 비활성화 / EC2 - 자격증명 X

모든 퍼블릭 액세스 차단 비활성화 / EC2 - 자격증명 X / --no-sign-request 옵션 추가

️ PC (IAM 자격증명 O), 객체 URL로 접근시에도 전과 동일한 결과가 표시됐습니다.

권한 개요가 객체를 퍼블릭으로 설정할 수 있음으로 변경되으나 객체가 자동으로 공개되지는 않았습니다.

좌) 모든 퍼블릭 액세스 차단 활성화 / 우) 모든 퍼블릭 액세스 차단 비활성화

그럼 여기서 의미하는 '퍼블릭'은 무엇인지 의문이 들었습니다.

AWS에서 정의하는 퍼블릭의 의미 는 다음과 같습니다.

ACL
- 미리 정의된 AllUsers 또는 AuthenticatedUsers 그룹의 구성원에게 권한을 부여하는 경우
버킷 정책
- 버킷 정책은 기본적으로 퍼블릭으로 평가
- 퍼블릭이 아닌 것으로 평가되려면 ?
  버킷 정책에서 AWS 보안 주체, SourceIP, SourceArn 등 하나 이상에 대한 고정 값을 부여해야 함

# 퍼블릭
{
        "Principal": "*", 
        "Resource": "*", 
        "Action": "s3:PutObject", 
        "Effect": "Allow", 
        "Condition": { "StringLike": {"aws:SourceVpc": "vpc-*"}}
    }

# 퍼블릭이 아님 
{
        "Principal": "*", 
        "Resource": "*", 
        "Action": "s3:PutObject", 
        "Effect": "Allow", 
        "Condition": {"StringEquals": {"aws:SourceVpc": "vpc-91237329"}}
    }

모든 퍼블릭 액세스 차단을 비활성화하면 객체에 공개적으로 접근 가능할 수 있다는 가능성이 생길 뿐, 객체에 대한 접근 가능 여부는 버킷 정책 등 여러 요소에 따라 달라진다는 것을 알 수 있었습니다.

이제부터 ACL과 버킷 정책에 따라 객체에 대한 접근 가능여부가 어떻게 달라지는지 확인해보겠습니다.

2. ACL 활성화

ACL은 언제쓸까요 ?

특별한 이유가 없다면 ACL을 비활성화하는 것이 좋습니다. ACL을 사용하면 IAM과 버킷 정책 외에 추가로 액세스를 제어할 수 있는 계층이 생성되는데, 이렇게 되면 관리의 복잡성과 구성 오류의 위험성이 증가하게 되기 때문입니다.
다만 A계정에서 B계정이 소유한 버킷에 객체를 업로드할 때, 특정 작업을 수행할 수 있는 권한을 Amazon CloudFront와 같은 AWS 서비스에 부여할 때 객체 ACL을 사용하게 됩니다. 자세한 내용은 Amazon S3에서 객체 ACL을 사용하는 사용 사례에는 어떤 것이 있나요?를 참고해주세요.

이번 실습에서는 ACL을 활성화하고 객체별 소유권을 제어해봤습니다.

1. AWS 콘솔에서 [권한] > 객체 소유권 편집을 선택합니다. ACL을 활성화하고 ACL 편집을 통해 모든 사람(퍼블릭 액세스)이 객체를 나열할 수 있도록 설정합니다.

ACL을 변경하자 버킷 액세스가 퍼블릭으로 표시됩니다.

모든 퍼블릭 액세스 차단 비활성 + 버킷 ACL 활성화

EC2 (IAM 자격증명 X)

ACL 활성화 이전과 결과는 동일합니다.

모든 퍼블릭 액세스 차단 비활성 + 버킷 ACL 활성화 - 모든 사람(퍼블릭 액세스) 나열 허용

EC2 (IAM 자격증명 X)

모든 사람에게 나열 작업을 허용했기 때문에 서명이 없는 상태에서도 버킷의 객체 나열이 가능합니다.

ACL 변경 후 - 모든 사람(퍼블릭 액세스) 나열 허용

하지만 객체 다운로드는 불가능합니다.

2. 객체 ACL

이번엔 객체별 권한을 변경해보겠습니다.

memo1.txt → 모든 사람(퍼블릭 액세스) 읽기 허용
memo2.txt → 인증된 사용자 그룹(AWS 계정이 있는 모든 사용자) 읽기 허용

모든 퍼블릭 액세스 차단 비활성 + 버킷 ACL 활성화 + 객체 ACL - 모든 사람(퍼블릭 액세스) 읽기 허용

EC2 (IAM 자격증명 X)

객체 수준에서 모든 사람에게 읽기를 허용하자 서명 없이도 객체 다운로드가 가능합니다.

모든 퍼블릭 액세스 차단 비활성 + 버킷 ACL 활성화 + 객체 ACL - 인증된 사용자 그룹(AWS 계정이 있는 모든 사용자) 읽기 허용

EC2 (IAM 자격증명 X)

AWS 계정에서 객체에 읽기가 가능한 정책으로 AWS 계정이 아닐 경우 읽기 작업이 거부되어야합니다.

credential이 없다고 나옵니다.

서명을 없애자 404 에러가 나타나며 파일이 존재하지 않는다고 표시됩니다.

️ PC (IAM 자격증명 O)

AWS 자격증명이 있는 로컬 PC에서는 어떨까요 ?

서명이 있는 상태에서는 AWS 계정임이 인증되기 때문에 다운로드가 이뤄집니다.

로컬 PC에서는 403에러가 발생합니다.

3. 버킷 정책 수정

객체 ACL 설정을 유지한 상태에서 버킷 정책을 수정해보겠습니다.

다음 정책은 ahss-닉네임 버킷에 있는 객체들에 대한 GetObject 작업을 허용한다는 정책입니다.

여기에서 Principal 필드는 리소스에 대한 액세스를 허용하거나 거부할 사람, 보안 주체를 지정합니다. 특정 AWS 계정, IAM 사용자, AWS 서비스 등이 주체가 될 수 있습니다. 다음 정책과 같이 Principal 필드에서 와일드카드 "*"를 사용하면 모든 보안 주체에 적용되어 익명의 사용자에게도 접근을 허용하게 됩니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ahss-닉네임/*"
        }
    ]
}

S3 접근 제어는 제어에 관여하는 정책들이 많아 다소 복잡하게 느껴질 수 있습니다. AWS에서 IAM Access Analyzer라는 액세스 분석기를 제공하고 있으니 활용해보시면 좋을 것 같습니다.

4. 실습 리소스 삭제

# 버킷에 객체 모두 삭제
aws s3 rm s3://ahss-$NICKNAME --recursive

# 실습에 사용한 S3 버킷 삭제
aws s3 rb s3://ahss-$NICKNAME

# 확인
aws s3 ls

2. S3 보안 강화

S3 보안 강화를 위한 AWS 공식 Workshop이나 자료들을 참고하여 S3 보안을 강화할 수 있습니다.

S3의 기능 중 하나인 Pre-signed URL을 사용하여 임시적으로만 객체에 접근할 수 있게 하고, Security Best Practice를 준수하도록 설정해보겠습니다.

1. Pre-Signed URL 활성화

Pre-Signed URL을 사용하면 사용자가 AWS 계정이나 권한이 없어도, 버킷 정책 수정 없이 특정 객체에 대한 액세스가 가능하도록 설정할 수 있습니다. 통지서 같은 것들이 SMS로 수신됐을 때 특정 기간동안 링크만으로도 내 정보에 접근할 수 있는 경우가 있는데요, Pre- Signed URL을 사용하면 이런 작업이 가능합니다.

최소 1분에서 최대 7일까지 유효한 URL을 생성할 수 있습니다.

️ PC (IAM 자격증명 O) 에서 다음 명령을 실행해보겠습니다.

# 버킷생성
aws s3 mb s3://ahss-$NICKNAME-presign --region ap-northeast-2

# 확인
aws s3 ls
aws s3api get-public-access-block --bucket ahss-$NICKNAME-presign | jq

# 그림파일 다운로드
curl https://www.nasa.gov/sites/default/files/thumbnails/image/main_image_star-forming_region_carina_nircam_final-5mb.jpg -o jameswebb.jpg

# S3로 업로드
aws s3 cp jameswebb.jpg s3://ahss-$NICKNAME-presign

# 파일 확인
aws s3 ls s3://ahss-$NICKNAME-presign --human-readable
aws s3api list-objects --bucket ahss-$NICKNAME-presign | jq

Pre-signed URL을 생성합니다. URL이 유효하게 지속될 시간을 --expires-in 옵션값으로 입력해줍니다. 600은 10분을 의미합니다.

aws s3 presign s3://ahss-$NICKNAME-presign/jameswebb.jpg --expires-in 600

✅ 모든 퍼블릭 액세스 차단 활성화 상태이지만생성된 URL을 브라우저에 입력했더니 다음과 같이 객체가 표시되는 것을 확인할 수 있었습니다.

2. Require HTTPS

안전한 통신을 위해 HTTPS를 사용한 연결이 아니면 버킷에 접근이 불가능하도록 하는 정책을 설정합니다.

{
	"Id": "S3-Security-Deny-unless-HTTPS",
	"Version": "2012-10-17",
	"Statement": [{
		"Action": "s3:*",
		"Effect": "Deny",
		"Principal": "*",
		"Resource": "arn:aws:s3:::ahss-닉네임-presign/*",
		"Condition": {
			"Bool": {
				"aws:SecureTransport": false
			}
		}
	}]
}

정책을 추가하고 http, https 로 객체를 호출해 보겠습니다.

# object's metadata 정보 확인 : endpoint-url 옵션 설정 >> http? https? 확인
aws s3api head-object --bucket ahss-$NICKNAME-presign --key jameswebb.jpg --endpoint-url http://s3.ap-northeast-2.amazonaws.com
aws s3api head-object --bucket ahss-$NICKNAME-presign --key jameswebb.jpg --endpoint-url https://s3.ap-northeast-2.amazonaws.com

✅ 모든 퍼블릭 액세스 차단 활성화

️ PC (IAM 자격증명 O)

https로 호출 시 403에러가 발생하지만 https로 호출시에는 요청이 정상적으로 처리됩니다.

3. SSE-KMS 암호화 사용

버킷을 생성하면 기본 암호화가 SSE-S3(S3 관리 키)으로 구성되어 있습니다. SSE-KMS를 사용하도록 버킷 암호화 기본값을 업데이트하여 새 객체가 SSE-KMS(KMS 관리 키)를 사용하도록 설정합니다. 두 방식 모두 안전하지만 ~~AWS의 IDC가 털려서 S3 키가 유출된다면...?~~ 일반적으로 KMS 관리 키가 더 보안 수준이 높다고 간주됩니다. 서버 측 암호화(SSE-C, SSE-S3, SSE-KMS, DSSE-KMS)를 사용하여 생성된 객체 복제

KMS 키 중에서 S3 키를 선택합니다.

이렇게 설정된 상태에서 버킷에 객체를 업로드하면 ServerSideEncryption이 기본적으로 Kms로 설정됩니다.

✅ 모든 퍼블릭 액세스 차단 활성화

️ PC (IAM 자격증명 O)

# 객체 업로드 
echo "123456789abcdefg" > textfile
aws s3api put-object --key text02 --body textfile --bucket ahss-$NICKNAME-presign

# object's metadata 정보 확인 : ServerSideEncryption 확인
aws s3api head-object --bucket ahss-$NICKNAME-presign --key text02 | jq

이를 응용해서 ServerSideEncryption": "aws:kms" 이 아닌 객체는 업로드 금지하도록 버킷 정책을 설정할 수도 있습니다.

{
	"Id": "S3-Security-Deny-unless-SSE-KMS",
	"Version": "2012-10-17",
	"Statement": [{
		"Effect": "Deny",
		"Principal": "*",
		"Action": "s3:PutObject",
		"Resource": "arn:aws:s3:::ahss-$NICKNAME-presign/*",
		"Condition": {
			"StringNotEquals": {
				"s3:x-amz-server-side-encryption": "aws:kms"
			}
		}
	}]
}

4. AWS Config 규칙을 사용하여 퍼블릭 버킷 감지

AWS Config는 리소스의 구성 및 관계에 대한 지속적인 진단, 감사 및 평가를 수행하는 서비스입니다.

사용자가 직접 규칙을 설정할 수도 있고, AWS에서 제공하는 관리형 규칙을 사용해 편리하게 감사 및 추적이 가능합니다. access key 관리 주기, acm 만료 일자 확인 등 리소스와 관련된 항목들을 규칙으로 설정해두고 이를 위반할 시 알림을 받도록 구성하여 리소스 관리에 대한 가시성을 높일 수 있습니다.

S3 bucket과 관련된 규칙도 제공하고 있는데요, 여기서 s3 bucket이 Public 상태가 될 경우를 추적하는 규칙을 추가해보겠습니다.

규칙을 추가해두면 위반된 리소스를 탐지하고 내용을 표시해줍니다.

Config 위반 알림이 발생 시 Slack으로 알람을 받도록 설정해두면 매번 콘솔에서 확인하지 않아도 쉽게 리소스 변경 추적이 가능하겠죠 ?

마치며

S3는 자주 사용하지만 보통 로그 저장용으로 사용하여 완전히 프라이빗하게 구성해서 사용하고 있어 세분화된 제어를 해보지는 않았었습니다. S3와 권한 문제는 알면 알수록 복잡하고, 테스트해 볼 경우의 수가 무궁무진하다고 느꼈습니다. EC2에서는 404가, PC에서는 403에러가 발생하는 이유에 대해서도 다뤄보려 합니다. 아직 부족한 부분이 많지만 첫걸음을 뗐다고 생각하면서 차근차근 공부해보겠습니다. :)

CloudNet@팀의 AHSS(AWS Hacking & Security 스터디) 학습 내용과 제가 공부한 내용을 정리한 글입니다. 더 좋은 방법이나 틀린 내용이 있으면 말씀해주세요 :)

참고 자료

Builders Online - AWS IAM과 친해지기

S3 사용 설명서: 리소스 액세스 관리

Terraform 코드 네이밍 컨벤션

chnh — Thu, 13 Jul 2023 14:20:46 +0900

들어가며

이미 잘 사용하고 있는 분들이 많겠지만, 개인적으로 한번쯤 정리해보고 싶었던 부분이라 글을 작성하게 되었다.

리소스를 생성하든, 함수를 생성하든 나에게 이름을 짓는 순간은 가장 심혈을 기울이게 되는 순간 중 하나이다. 미래의 나를 위한 가독성, 협업을 위해서, 유지 보수, 오류 감소, 문서로서의 역할 등등... 네이밍 컨벤션이 중요한 이유는 넘친다. IaC 도입의 긍정적인 효과—공동작업과 재사용성, 기술의 자산화 등—을 온전히 누리기 위해서는 네이밍 컨벤션에 대한 협의가 반드시 이루어져야한다고 생각한다.

어떻게 하면 '좋은' 인프라를 위한 네이밍을 할 수 있을지 Best Practice를 기반으로 정리하였다. 주관적인 견해와 수집한 정보들을 바탕으로 작성한 것이므로 다음 내용이 정답이 아님을 미리 밝힌다.

Terraform 코드 네이밍 컨벤션

1. 자원 이름에 `-`(dash)대신 `_`(underscore) 사용

AWS 콘솔에서 리소스를 생성할 때는 주로 -를 사용한 케밥케이스(e.g. prd-crm-web-ec2)를 사용하여 리소스를 생성했는데 ...

테라폼 공식 문서에 있는 예제들도 주로 스네이크 케이스를 사용하고 있다. 리소스 이름, 데이터 소스 이름, 변수 이름, 출력 등 모든 곳에서 _를 사용하는 것이 좋다고 한다.

-는 테라폼에서 뺄셈이나 요소 제거등에 사용될 수 있기 때문이다. -를 연산자로 사용하는 경우 자원 이름에도 -를 사용했을 때 오류가 발생할 잠재적인 위험이 있기 때문에 자원 이름에 - 사용을 지양한다고.

그리고 이건 개인적으로 느낀 장점인데, _를 쓰면 해당 어구를 더블클릭했을 때 전체 선택이 된다. private_nat 는 더블클릭하면 한번에 선택되지만 private-nat는 그렇지 않다. _를 쓰면 여러 블럭을 한번에 수정할때 편해진다.

✅ Do

resource "aws_eks_cluster" "my_cluster" {}

❌ Do Not

resource "aws_eks_cluster" "my-cluster" {}

2. 소문자 사용

가독성 향상을 위해 소문자를 사용한다.

3. 중복 최소화

리소스 유형(type)을 리소스 이름(name)에 반복하는 것을 지양한다.

중복을 방지하고 이름을 간결하게 유지해서 리소스의 용도를 명확하게 할 수 있다.

테라폼은 다음과 같은 구조로 작성되는데,

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
  <IDENTIFIER> = <EXPRESSION>
}

블록 타입이 resource라고 가정했을 때 다음과 같은 구조를 갖게 된다.

resource "<PROVIDER>_<TYPE>" "<NAME>" {
  # Block contents
  argument_1 = "value"
  argument_2 = "value"

  # Nested Block
  nested_block {
    # Block contents
  }
}

여기서 "" 부분의 이 리소스 명칭이다. AWS의 라우팅 테이블을 생성한다면 "aws_route_table"과 같이 표기한다. 이때 뒤에 오는 ""에 aws, route_table과 반복을 피하는 것을 권고한다. 대신 용도를 구분할 수 있도록 public, private 등의 명칭만 표기하는 것을 추천한다.

✅ Do

resource "aws_route_table" "public" {}
resource "aws_vpc_endpoint" "apigateway" {}

❌ Do Not

resource "aws_route_table" "public_route_table" {}
resource "aws_vpc_endpoint" "apigateway_endpoint" {}

4. 이름에는 기본적으로 단수 명사를 사용한다.

단, 여러 값을 포함하게 되는 경우—variable 블록에서 list(...) or map(...)를 사용하거나 output 블록에서 반환되는 값이 복수형인 경우 등—에는 복수형으로 표기한다.

✅ Do

output "rds_instance_endpoint" {
  description = "An instance endpoint"
  value       = aws_rds_cluster_instance.this.endpoint
}

output "rds_cluster_instance_endpoints" {
  description = "A list of all cluster instance endpoints"
  value       = aws_rds_cluster_instance.this.*.endpoint
}

❌ Do Not

output "rds_instance_endpoints" {
  description = "An instance endpoint"
  value       = aws_rds_cluster_instance.this.endpoint
}

5. tag는 마지막에

단, depends_on이나 lifecycle 인자는 tag 보다 뒤에 명시한다.

✅ Do

resource "aws_nat_gateway" "this" {
  count = 2

  allocation_id = "..."
  subnet_id     = "..."

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}

❌ Do Not

resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

  allocation_id = "..."
  subnet_id     = "..."
}

6. variable block 안에 들어가는 key 값들을 어떻게 정렬할지 미리 설정하기

e.g. description , type, default, validation

7. Output의 이름은 {name}_{type}_{attribute} 구조로

{name}은 provider 접두사가 없는 리소스 또는 데이터 소스 이름
aws_subnet → {name}은 subnet
aws_vpc → {name}은 vpc이다.
{type}은 리소스 소스의 유형
{attribute}은 출력에서 반환되는 속성

✅ Do

output "security_group_id" {
  description = "The ID of the security group"
  value       = "")
}

❌ Do Not

output "this_security_group_id" {
  description = "The ID of the security group"
  value       = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
}

참고) 네이밍 외에 스타일 컨벤션과 관련된 부분은 다음 명령어로 해결할 수 있다.

terraform fmt

마치며

막상 이렇게 정리해보니까 내가 지키지 않고 있는 규칙들도 있어서 (특히 리소스 타입과 이름을 중복하는 것) 차근차근 수정해나가야겠다. 이렇게 사용하다가 불편함이 생기면 또 업데이트 해보겠습니다 !

참고자료

Golden Image Pipeline 구성 - 2. GitHub Actions로 이미지 생성 자동화

chnh — Mon, 26 Jun 2023 16:13:42 +0900

들어가며

이 글은 Golden Image Pipeline 구성 - 1. Packer와 Ansible로 이미지 만들기의 후속이다. 이번에는 golden ami를 정의한 packer 템플릿이나 ansible playbook에 변경 후 branch에 push될 경우 ami를 생성하도록 구성하는 방법을 설명한다.

AMI ID를 콘솔에 접속하지 않고 바로 출력할 수 있도록 packer 템플릿에 manifest file을 생성하는 post-processor를 추가하고, 최신 linux ami를 가져오는 data 블럭을 새로 만들었다.

# base-linux-ami.pkr.hcl

locals {
  timestamp = regex_replace(timestamp(), "[- TZ:]", "")
}


data "amazon-ami" "amzn2-lts" {
  filters = {
    name                = "amzn2-ami-hvm-*-x86_64-gp2"
    root-device-type    = "ebs"
    virtualization-type = "hvm"
  }
  most_recent = true
  owners      = ["amazon"]
}


source "amazon-ebs" "base-linux-ami" {
  region        = "ap-northeast-2"
  ami_name      = "amzn2-base-ami-${local.timestamp}"
  source_ami    = data.amazon-ami.amzn2-lts.id
  vpc_id        = "vpc-id"
  subnet_id     = "subnet-id"
  instance_type = "t2.micro"
  ssh_username  = "ec2-user"
  tags = {
    Name          = "amzn2-base-ami-${local.timestamp}"
    Base_AMI_ID   = "{{ .SourceAMI }}"
    Base_AMI_Name = "{{ .SourceAMIName }}"
  }
}


build {
  sources = [
    "source.amazon-ebs.base-linux-ami"
  ]

  provisioner "ansible" {
    playbook_file = "playbook/playbook.yml"
    use_proxy     = "false"
    user          = "ec2-user"
  }

  post-processor "manifest" {
    output     = "manifest.json"
    strip_path = true
  }
}

1. Github Actions Secret 설정

Github Actions이 AWS와 상호 작용하기 위해 자격 증명 구성이 필요하다.

Github Actions는 CI/CD 워크플로에서 중요 데이터나 암호들을 안전하게 사용할 수 있도록 Secrets를 제공하고 있다. 여기에 액세스 키를 저장하면 Github 실행 로그에도 마스킹 처리가 되고, 정의된 컨텍스트 내에서만 사용할 수 있기 때문에 사용 범위 제한이 가능하다. AWS에서 해당 액세스 키의 주체에게 최소 권한만을 부여하고, 자주 액세스키를 교체해주는 등의 작업을 통해 보다 안전하게 사용할 수 있다.

Golden image pipeline을 구성할 리포지토리의 Settings 탭에서 Secrets 메뉴에 접근할 수 있다. 다음 두 key에 대한 값을 저장한다.

AWS_ACCESS_KEY_ID
AWS_SECRETE_ACCESS_KEY_ID

위에서 설정한 자격 증명은 이후 workflow 파일에서 AWS 자격증명을 구성하는 데에 사용된다.

2. Github Actions workflow 구성

workflow 파일 작성 문법에 대한 글은 다음 게시글을 참고 바란다.

GitHub Actions Workflow 문법 정리

다음은 내가 작성한 workflow 정의 파일이다. workflow 파일은 .github/workflows 아래에 위치해야한다.

main branch에 push 작업이 일어날 때마다 jobs 아래에 정의된 작업들이 순차적으로 실행된다.

#build-ami.yml

name: Build Golden Image

on:
  push:
    branches:
      - main
jobs:
  packer:
    runs-on: ubuntu-latest
    name: Run Packer
    steps:
      - name: Checkout Repository # 현재 리포지토리의 코드를 체크아웃
        uses: actions/checkout@v2

      - name: Configure AWS Credentials #  GitHub Secrets에서 AWS 자격 증명을 구성
        uses: aws-actions/configure-aws-credentials@v1
        with: 
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      - name: Initialize Packer Template # Packer 템플릿 초기화
        uses: hashicorp/packer-github-actions@master
        with:
          command: init

      - name: Validate Packer template # Packer 템플릿 유효성 검증 
        run: packer validate base-linux-ami.pkr.hcl

      - name: Build AMI # Packer 템플릿 build
        run: packer build base-linux-ami.pkr.hcl
        env:
          PACKER_LOG: 1 # Packer 로그 활성화

3. Github Repository로 push

workflow 정의파일을 업로드한 다음, ansible playbook 파일을 수정 후 main branch에 push해보겠다.

push 명령어 실행 후 바로 Github Actions이 실행된다. commit message와 함께 작업 내용이 표시되고, 실시간으로 작업 진행 현황을 확인할 수 있다.

작업이 정상적으로 완료되면 Github UI 상에서는 다음과 같이 표시된다.

post-processor가 생성한 manifest 파일에는 ami id와 packer run uuid 정보 등이 표시된다.

다음 스크립트를 실행하여 manifest 파일에서 최신 ami id를 불러와봤다. AMI ID가 잘 출력되는 걸 확인할 수 있다.

# get_ami_id.sh

AMI_ID=$(jq -r '.builds[-1].artifact_id' manifest.json | cut -d ":" -f2)
echo $AMI_ID

참고자료

https://developer.hashicorp.com/packer/tutorials/cloud-production/github-actions

Golden Image Pipeline 구성 - 1. Packer와 Ansible로 이미지 만들기

chnh — Mon, 26 Jun 2023 14:07:00 +0900

들어가며

이 글에서는 Immutable Infrastructure가 무엇인지 이해하고, 이를 구현하기 위한 첫 단계로 Packer와 Ansible을 사용하여 골든 이미지를 만든다. 이후 Github Actions을 사용해 변경사항이 Ansible Playbook에 푸시될 때마다 자동으로 Packer를 실행하는 Golden Image 파이프라인을 구성한 다음, Terraform을 사용하여 변경된 이미지로 인프라를 교체하도록 설정하여 자동화된 Immutable Infra를 구현하는 것을 목표로 한다.

완성하면 요런느낌 ✨

시리즈는 다음과 같이 계획되어있다.

1. Packer와 Ansible로 이미지 만들기

2. GitHub Actions로 이미지 생성 자동화

3. Terraform을 사용하여 AWS에 변경된 인프라 배포

Immutable Infrastructure와 Golden Image

AWS를 사용중인 사람이라면 인스턴스를 생성할 때 AMI(Amazon Machine Image)를 사용해봤을 것이다. AMI는 미리 구성된 운영 체제와 설치된 소프트웨어를 포함하고 있는 머신 이미지인데, 덕분에 인스턴스를 시작할 때마다 수동으로 구성하는 절차 없이 빠르게 리소스를 프로비저닝 할 수 있다. 이 AMI에 대한 일종의 마스터 템플릿을 골든 이미지라고 한다.

DevOps 관점에서 이미지, 특히 골든 이미지는 변경 불가능한 인프라(Immutable Infrastructure)를 구현하는 데 중요한 역할을 한다. 필요한 구성과 소프트웨어가 모두 포함된 완벽한 골든 이미지를 생성한 다음 해당 이미지를 사용하여 인프라를 생성한다는 아이디어로, 서버에 업데이트 또는 수정이 필요한 경우 이미 사용 중인 서버를 업데이트하는 대신 새로운 이미지를 사용하여 새 서버를 배포하는 방식을 선택한다. 즉 한번 실행된 인스턴스는 변경되지 않고, 변경이 필요한 경우에는 업데이트된 이미지를 가지고 아예 새로운 인스턴스로 교체한다. 때문에 구성 드리프트가 발생할 틈이 없다.

https://devopscube.com/immutable-infrastructure

이렇게 인프라를 관리하면 다음과 같은 이점이 있다.

일관성: 모든 인스턴스가 동일하므로 구성 드리프트로 인해 문제가 발생할 가능성이 줄어든다.
효율성: 골든 이미지에는 OS뿐만 아니라 설치 및 구성된 애플리케이션도 포함될 수 있기 때문에 빠르게 부팅할 수 있다.
신뢰성: 사전에 검증된 이미지를 사용하기때문에 구성 오류가 발생할 가능성이 크게 줄어든다.
확장성: 확장이 필요할 때 골든 이미지를 사용하여 새로운 동일한 인스턴스를 신속하게 온라인으로 가져올 수 있다.
복구 용이성: 새 버전에 문제가 있는 경우 이전 골든 이미지를 인스턴스화하여 이전 버전으로 쉽게 되돌릴 수 있고 현재 사용중인 서비스에 문제가 발생하는 경우 빠르게 복원할 수 있다.
IaC의 발전이 Immutable Infra를 구현하는 데에 큰 기여를 했다고 생각한다. 이미지, 인스턴스, 네트워크와 같은 리소스들을 코드로 쫙 작성해서 한번에 테스트하고 승격하고 배포할 수 있게 됐으니 말이다. IaC가 등장하지 않았다면 일관된 방식으로 이런 단계를 반복하는 것은 많은 시간을 들이고, 구현한다 한들 수작업 과정에서 문제가 발생했겠지. ㅎㅎ...끔찍하다... 무튼 ! 이제 이 좋은 도구들을 가지고 자동으로 일관된 환경을 유지해보자.

Packer와 Ansible

Packer를 한 마디로 정의하자면 '머신 이미지 빌더'라고 할 수 있을 것 같다. Template을 사용해 여러 플랫폼의 머신 이미지를 생성할 수 있는 Hashicorp의 오픈소스로, AWS Image builder와 유사한 기능을 한다. Packer는 이미지를 만들 때 가상 머신의 특정 시점의 상태만을 저장하는 것이 아니라 이미지가 생성되는 과정도 코드로 저장되기 때문에 유사한 이미지를 반복 생성할 때 도움이 된다.

Template 은 빌드하려는 이미지와 빌드 방법을 정의한 구성파일로, Builder와 Provisioner를 조합하여 구성한다. 초기에는 JSON 형식(.pkr.json)으로 템플릿을 작성했으나 현재는 Terraform과 같은 HCL2를 사용하도록 장려하고 있다. 이 글에서는 HCL로 템플릿을 작성한다.

https://hackmd.io/@XeusNguyen/BJtEoB_Ci

Builder
- 빌더는 머신을 생성하고 해당 머신에서 다양한 플랫폼용 이미지를 생성한다. AWS에서 사용할 AMI를 생성할지, Docker 컨테이너 이미지를 생성할지 등을 결 정한다.
- 예시를 살펴보면 좀 더 감이 오는데, 다음은 일반적으로 사용하는 빌더들이다.
  - Amazon EC2 (amazon-ebs, amazon-ebssurrogate, amazon-ebsvolume, amazon-chroot, amazon-instance)
  - Google Compute Engine(googlecompute)
  - Azure Resource Manager(azure-arm)
  - Docker (docker)
  - VMWare(vmware-iso, vmware-vmx)
- 이외에도 custom builder나 packer 커뮤니티에서 지원하는 빌더를 사용할 수 있다.

Provisioner
- 프로비저너는 built-in 또는 third-party 소프트웨어를 사용하여 부팅 후 패키지 설치, 커널 패치, 사용자 생성, 애플리케이션 코드 다운로드 등의 작업을 수행하여 이미지를 원하는 상태로 프로비저닝한다.
- 다음과 같은 프로비저너들을 사용할 수 있으며, 최신 정보는 공식 문서에서 확인할 수 있다.
  - ansible
  - ansible-local
  - chef-client
  - chef-solo
  - file
  - powershell
  - shell
  - shell-local
  - puppet-masterless
  - puppet-server
  - salt-masterless
  - windows-restart
  - windows-shell

Post-Processor
- 포스트 프로세서는 빌 드와 프로비저닝 후에 실행된다. 따라서 필수적인 옵션은 아니며, 프로비저닝 이후 생성된 artifact들에 대해 작업을 수행한다. 예를 들어 포트스 프로세서로 compress 를 사용하여 build된 이미지를 tar 파일로 압축해서 저장하거나, docker-push를 사용해 docker 레지스트리에 이미지를 푸시할 수 있다. manifest를 사용하여 artifact에 대한 정보를 json 파일로 출력하는 등의 작업 또한 가능하다.

Ansible은 원격으로 서버를 구성하고 관리할 수 있는 RedHat의 오픈소스이다. Ansible은 Python을 기반으로 개발되었으며, YAML 포

맷을 기반으로 인프라를 정의한다. Ansible을 사용하면 관리할 서버에 별도의 데몬을 설치하지 않고 원격으로 접속해서 서버를 구성할 수 있다. Packer로 이미지를 빌드할 때 Ansible을 프로비저너로 사용하면 이미지에 필요한 모든 소프트웨어를 사전에 설치할 수 있고, playbook을 작성해 여러번 재사용할 수 있어 효율적인 인프라 관리가 가능하다.

1. Packer, Ansible 설치

macOS를 사용중이라 brew로 설치했다.

# install packer 
brew tap hashicorp/tap
brew install hashicorp/tap/packer

# install ansible
brew install ansible

2. Ansible playbook 작성

provisioner로 ansible을 사용할 것이기 때문에 playbook을 미리 작성한다.

playbook은 원격 host에서 실행할 일련의 작업을 yaml로 작성한 스크립트이다. 다음 스크립트는 ec2의 timezone을 서울로 변경하고, 최신 버전으로 git을 설치하고, 특정 버전의 nginx를 설치하고, nginx를 시작한다.

# playbook.yml
- name: Start Playbook
  hosts: all
  become: yes
  tasks:
    - name: Set Asia/Seoul timezone
      timezone:
        name: Asia/Seoul

    - name: Install git
      yum:
        name: git
        state: latest

    - name: Enable extras
      command: amazon-linux-extras install -y nginx1.12
      args:
        creates: /etc/nginx/nginx.conf

    - name: Start Nginx
      ansible.builtin.systemd:
        name: nginx
        state: started
        enabled: yes

3. Packer 템플릿 생성

1. packer 템플릿을 저장할 디렉토리를 생성한다.

mkdir packer-practice
cd packer-practice

2. 작성한 Packer 템플릿은 다음과 같다.

source_ami는 AMI 카탈로그에서 참조하거나 private으로 사용하는 ami가 있다면 해당 ami를 사용해도 된다. 최신버전의 ami를 사용하고자 하는 경우 filter를 통해 조회 후 적용이 가능하다.

EC2 콘솔에서 제공하는 AMI 목록

# packer-aws-linux.pkr.hcl 

locals {
  timestamp = regex_replace(timestamp(), "[- TZ:]", "")
}

source "amazon-ebs" "packer-ami" {
  region          = "ap-northeast-2" # AMI를 생성할 리전 
  ami_name        = "packer-aws-${local.timestamp}"
  source_ami      = "ami-0a0064415cdedc552" # Amazon Linux 2 AMI (HVM)
  vpc_id          = "vpc-id" # AMI가 생성될 VPC
  subnet_id       = "subnet-id" # AMI가 생성될 Subnet
  instance_type   = "t2.micro"
  ssh_interface   = "public_ip"
  ssh_username    = "ec2-user" # Linux ssh user (ubuntu일 경우 admin)
  ami_description = "Nginx with Amazon Linux2"
  assume_role {
    role_arn = "arn:aws:iam::account-id:role/admin"
  }

  tags = { # https://developer.hashicorp.com/packer/plugins/builders/amazon/ebs#build-shared-information-variables
    Base_AMI_ID   = "{{ .SourceAMI }}"
    Base_AMI_Name = "{{ .SourceAMIName }}"
  }
}

build {
  sources = [
    "source.amazon-ebs.packer-ami"
  ]

  provisioner "ansible" {
    playbook_file = "playbook/playbook.yml"
    use_proxy     = "false"
    user          = "ec2-user"

  }
}

packer
- packer 블록은 terraform 구성 파일에서 terraform 블록과 유사한 역할을 한다. 구성을 적용하는 데 필요한 최소 요구 사항 ( required_version, required_plugins)과 같은 패커 자체의 동작에 대해 정의한다.
source
- Packer가 새 머신 이미지를 생성하기 위해 소스 이미지를 찾아야하는 위치를 정의한다. build 블록에서 해당 source 블록을 참조하여 builder를 시작할 수 있다.

build
- build를 어떻게 수행할지에 대해 정의하는 블록이다. 어떤 builder(e.g.VirtualBox, VMware, Amazon EC2)를 사용할지, 어떤 방법으로 프로비저닝 할지 등을 지정한다.
- provisioner 블록을 포함시켜 ansible 함께 구성한다거나 post-processor를 사용하여 build의 결과물(artifact)을 어떻게 처리할지 정의할 수 있다.
variables, locals, data 블록은 terraform에서와 유사한 용법으로 사용된다.

3. 구성을 Initialize 한다.

packer init .

init을 실행하면 packer는 구성 파일을 분석해서 필요한 플러그인을 식별하고 설치되어 있지 않다면 필요한 플러그인을 설치한다. 이때 빌더나 프로비저너와 관련된 항목은 관여하지 않고 오로지 플러그인만 확인한다.

4. packer 파일의 syntax에 문제가 없는지 확인하고 유효성 검사를 실시한다.

packer fmt packer-aws-linux.pkr.hcl 
packer validate packer-aws-linux.pkr.hcl

4. Packer 이미지 빌드

1. pakcer build 명령을 통해 이미지를 빌드해보겠다. build를 실행하면 Packer는 머신 이미지를 생성하고 Provisioner를 실행시킨다.

packer build packer-aws-linux.pkr.hcl

build가 성공한 화면

2. 콘솔에서 결과를 확인해보자.

build 명령 후 출력된 ami-id와 동일한 id의 이미지가 생성된 것을 확인할 수 있다. 태그도 의도했던대로 추가되었다. packer 템플릿에서 packer-aws-${local.timestamp}와 같이 AMI 이름에 생성된 시간이 찍히게 설정해두는데 정상적으로 반영되었다.

5. AMI로 EC2 생성

생성한 AMI로 EC2를 시작하여 ansible로 구성한 내역이 잘 들어갔는지 확인해봤다.

모두 정상적으로 실행된 것을 확인할 수 있었다.

마치며

packer는 처음 사용해보았는데, terraform을 사용하고 있어서 그런지 무리 없이 사용할 수 있었다. 여기서는 간단히 nginx를 설치하는 등의 작업만 진행했지만 실제로 애플리케이션을 미리 배포하고 구동하는 등의 작업을 playbook으로 실행하고 프로비저닝 해둔다면 auto scaling용 golden ami를 유지 관리하는데 큰 도움이 되겠다고 느꼈다. 꼭 프로덕션용으로 사용하지 않더라도 사내 표준 test base ami를 구성해두면 엔지니어나 개발자가 동일 환경에서 테스트 할 수 있다는 장점도 있을 것으로 보인다.

다음 글에서는 github action을 사용해 packer나 ansible playbook에 변경사항이 있을 때 이를 감지하고 새롭게 이미지를 build하는 방법을 설명해보려 한다.

참고자료

https://developer.hashicorp.com/packer/tutorials/aws-get-started/aws-get-started-build-image?in=packer%2Faws-get-started

https://www.44bits.io/ko/post/building-docker-image-and-using-packer

https://developer.hashicorp.com/packer/tutorials/aws-get-started/aws-get-started-build-image

GitHub Actions Workflow 문법 정리

chnh — Thu, 22 Jun 2023 17:36:50 +0900

들어가며

골든 이미지 파이프라인을 구성하면서 Github repo에 특정 이벤트가 발생했을 때 작업을 트리거하는 설정이 필요했다. 이 과정에서 Github Actions을 사용하게 되었고, 작업을 실행하는 workflow를 구성해야 했다. workflow는 리포지토리에 체크인된 YAML 파일에 의해 정의되기 때문에 파일 작성을 위한 syntax 공부가 필요했다.

이 글에은 해당 workflow 구성 파일 작성을 위해 공식 문서를 보면서 정리한 내용이다.

Workflow syntax for GitHub Actions

설명에 사용하는 전체 예제 코드는 다음과 같다.

# https://docs.github.com/en/actions/using-workflows/about-workflows

name: learn-github-actions
run-name: ${{ github.actor }} is learning GitHub Actions
on: [push]

jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

위 코드는 Github UI에서 다음과 같이 표현된다.

name - 선택사항

workflow의 이름. 리포지토리의 Actions 탭에 표시된다.

name: learn-github-actions

run-name - 선택사항

workflow에서 생성된 workflow 실행 이름

리포지토리의 Actions 탭에 있는 workflow 실행 목록에 표시된다. 실행 이름이 작성되지 않은 경우 이벤트별 정보로 설정된다. 예를들어 push 나 pull_request에 의해 트리거된 workflow라면 커밋 메시지가 표시되는 식이다.

# 실행을 트리거한 github.actor의 이름을 표시
run-name: ${{ github.actor }} is learning GitHub Actions

on

workflow를 트리거하는 이벤트

on: [push, fork]와 같이 한 번에 여러 이벤트를 설정할 수도 있고, 시간을 지정하거나 특정 파일, 태그, 브랜치 변경이 발생한 경우에만 workflow가 실행되도록 제한할 수도 있다.

# branch에 상관없이 push가 발생할 때마다 workflow 실행
on: [push]

on.<pull_request|pull_request_target>.<branches|branches-ignore>

pull_request 및 pull_request_target 이벤트를 사용할 때 특정 브랜치를 대상으로 하는 요청에 대해서만 워크플로우를 실행하도록 구성할 수 있다. 브랜치 이름은 *, **, +,?,! 같은 문자를 사용해서 패턴으로 정의하는 것도 가능하다. 특정 브랜치를 포함하는 것뿐만 아니라 특정 브랜치만 제외하는 것도 가능하다

# main 브랜치에 pull_request가 발생했을 때 workflow 실행 
on:
  pull_request:
    branches:    
      - main

on.push.<branches|tags|branches-ignore|tags-ignore>

push 이벤트를 사용할 때 특정 브랜치 또는 태그에서 실행되도록 정의할 수도 있다.

# 다음 대상에서 push 이벤트가 발생할 때 workflow 실행 
# - 브랜치 이름이 main, mona/octocat이거나 releases/로 시작하는 경우 
# - tag 이름이 v2이거나 v1.으로 시작하는 경우 
on:
  push:
    branches:    
      - main
      - 'mona/octocat'
      - 'releases/**'
    tags:        
      - v2
      - v1.*

jobs

workflow 실행은 하나 이상의 jobs로 구성된다. 이 job들은 기본적으로 병렬로 실행되기 때문에 순차적인 작업 수행이 필요한 경우 jobs.<job_id>.needs 또는 steps 키워드를 사용해서 순차적으로 실행되도록 의존성을 추가해야한다.

 jobs:

모든 job은 string 형식의 id를 가지며, run-on으로 지정된 러너 환경에서 실행된다.

# 최신버전의 ubuntu에서 실행되는 check-bats-version이라는 작업을 정의 
  check-bats-version:
    runs-on: ubuntu-latest

jobs.<job_id>

jobs 하위에 job_id를 부여하여 각 작업을 구별할 수 있다. 다음 예시에서는 job_id가 my_first_job, my_second_job인 두 개의 job이 생성되었다. job_id의 하위 키는 해당 작업의 속성을 정의한다.

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

jobs.<job_id>.name

여기서 정의한 name은 Github UI에 표시된다.

jobs.<job_id>.needs

앞서 설명했듯 job은 기본적으로 병렬적으로 실행된다. needs 조건을 추가하면 종속성이 생성되어 특정 작업이 완료될때까지 다음 작업이 시작되지 않는다. 즉 종속성에 따라 암시적으로 순서가 정의되고, 하나라도 실패하면 해당 작업이 실행되지 않는다. 대신 종속성이 없는 작업의 경우 병렬적으로 실행된다.

# job2가 시작되기 전에 job1이 완료되어야 하고, job3을 실행하기 전에 job1,2가 성공해야한다. 
# job1, job2, job3이 순차적으로 실행되도록 하는 예시 
jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

jobs.<job_id>. runs-on

job을 실행할 머신의 타입을 정의하는 부분이다. 머신의 유형에는 Github-hosted runner와 self-hosted runner가 있다.

# linux, x64, and gpu 라벨을 가진 자체 호스팅 러너에서만 실행
runs-on: [self-hosted, linux, x64, gpu]

# GitHub-hosted runner로 최신 ubuntu 이미지 사용  
runs-on: ubuntu-latest

다음은 사용 가능한 GitHub-hosted runner 유형이다. (2023.06.22 기준)

Runner image	YAML workflow label	Notes
Windows Server 2022	windows-latest or windows-2022	The windows-latest label currently uses the Windows Server 2022 runner image.
Windows Server 2019	windows-2019	None
Ubuntu 22.04	ubuntu-latest or ubuntu-22.04	The ubuntu-latest label currently uses the Ubuntu 22.04 runner image.
Ubuntu 20.04	ubuntu-20.04	None
macOS 13 Ventura [Beta]	macos-13 or macos-13-xl	None
macOS 12 Monterey	macos-latest, macos-12, macos-latest-xl or macos-12-xl	The macos-latest and macos-latest-xl workflow labels currently uses the macOS 12 runner image.
macOS 11 Big Sur	macos-11	None

jobs.<job_id>.steps

steps를 사용하면 각 작업이 파일에 명시된 순서대로 실행된다.

jobs.<job_id>.steps[*].uses

작업 단계의 일부로 실행할 작업을 선택하는 부분으로 uses 값은 사용할 작업의 이름과 버전을 나타낸다. {owner}/{repo}@{ref}와 같은 형식으로 표시된다. actions/*는 Github에서 제공하는 공식 작업이다.

# actions 조직에서 만든 checkout 작업의 버전3을 사용
# checkout: https://github.com/actions/checkout
    steps:
      - uses: actions/checkout@v3

# Docker 컨테이너 이미지를 작업으로 사용
    steps:
      -  uses: docker://alpine:3.8

jobs.<job_id>.steps[*].with

with 값은 특정 액션에 매개변수를 전달하는 데 사용된다. with 키워드는 run 키워드가 사용되는 단계에서는 사용할 수 없다. with에서 사용할 수 있는 매개변수는 각 액션의 문서에서 확인할 수 있다. (checkout 액션에 대해 사용할 수 있는 with 값은 여기)

# node-version이 14라는 매개변수를 actions/setup-node@v3 액션에 전달
     steps:
      - uses: actions/setup-node@v3
        with:
          node-version: '14'

jobs.<job_id>.steps[*].run

각 단계별로 실행할 명령을 정의한다. 이 명령은 runner의 셸에서 실행된다.

# npm install -g bats 명령 실행 후 bats -v 명령 실행 
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

참고자료

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions

키페어 없이 AWS CLI를 사용하여 EC2 인스턴스에 SSH로 연결하기

chnh — Wed, 21 Jun 2023 22:30:22 +0900

들어가며

기존에는 ec2 인스턴스에 연결하려면 키페어가 필요했다. 아마 대부분 다음 명령어로 인스턴스에 접속했을 것이다.

ssh -i /path/key-pair-name.pem instance-user-name@instance-public-dns-name

키페어를 관리하는 게 번거롭고 신경쓰이는 부분들이 많았다. ~~만약 전임자가 퇴사하면서 키도 함께 삭제하거나 분실되면 ...~~

링크드인에서 팔로우하고있는 AWS 엔지니어의 게시글을 통해 이제 키페어 없이 instance id만 알고있다면 aws cli로 Linux 인스턴스에 연결할 수 있다는 소식을 알게됐다.

인스턴스 연결 방법과 제한 사항에 대해 간단히 정리해보려한다. 아직 한국 공식 문서에는 올라오지 않았으나 영문 문서에는 게시되어있다.

EC2 Instance Connect란?

EC2 Instance Connect는 일시적인 SSH 키를 사용해서 Linux 인스턴스에 접속하는 방법이다.

사용자가 인스턴스 연결을 요청하면 Instance Connect API가 SSH 퍼블릭 키를 인스턴스 메타데이터에 푸시하고, SSH 데몬이 인스턴스 메타데이터에서 퍼블릭 키를 확인하여 사용자를 인스턴스에 연결해 준다. 이 때 사용자는 IAM 주체이고, 이 주체에게 키를 인스턴스에 푸시할 수 있는 권한이 있어야한다.

✔️ 2023.06.21 기준 Amazon Linux 2와 Ubuntu 16.04 이상 배포 버전에 대해서만 지원하고 있다.

AWS CLI로 Linux 인스턴스에 연결하기

이 글에서는 퍼블릭 환경에 있는 인스턴스를 기준으로 설명한다. 프라이빗 환경에 있는 인스턴스에는 엔드포인트를 통해 접근할 수 있다.

1. AWS CLI 업그레이드

내가 사용중이던 2.11.27 버전에서는 ec2-instance-connect 커맨드를 인식하지 못했다. 2.12.1로 업그레이드 후 가능해졌다.

AWS CLI를 사용중이라면 업데이트를 하고, AWS CLI가 설치되어 있지 않다면 최신 버전으로 설치한다.

macOS를 사용중이라 다음 명령어로 업그레이드했다.

brew update
brew upgrade awscli

2. 인스턴스 ID 조회

(이미 인스턴스 ID를 알고 있다면 생략 가능)

콘솔에서 직접 인스턴스 ID를 확인하거나, CLI에서 접속할 인스턴스 ID를 조회한다.

aws ec2 describe-instances

3. 인스턴스 연결

Public subnet에 위치한 인스턴스

다음 명령어를 통해 인스턴스에 접속한다.

aws ec2-instance-connect ssh --instance-id [instance-id]

성공 !

마치며

Instance Connect는 콘솔에서도 사용할 수 있는 기능이었지만 CLI가 지원되면서 훨씬 간편하게 접속할 수 있게 되었다. 다만 전자금융감독규정상 Instance Connect를 사용하는 것 자체가 보안상 취약하다고 여겨지니, 상황에 따라 적절히 사용하시길 .. ! 참고

System Manager로 특정 시간에 EC2 인스턴스 시작/중지 자동화하기

chnh — Sat, 3 Jun 2023 00:53:57 +0900

들어가며

테스트용 EC2나 RDS는 퇴근 후에 사용하지 않는 경우가 대부분이다. 비용 절감을 위해 사용하지 않을 때 리소스를 정리해야하지만 퇴근 전에 인스턴스 중지하고 출근해서 다시 켜고하는 건 너무 귀찮고 비효율적이다. Event Bridge와 System Manager(이하 SSM)의 Automation Document을 사용하면 EC2 뿐만 아니라 RDS도 특정 시간에 시작하고 중지할 수 있다.

다음과 같은 요구사항이 있는 사람에게 이 글이 도움이 될 것이다.

평일 오전9시에는 켜지고 오후9시가 되면 테스트 RDS가 중지되면 좋겠어요.
밤에만 사용하는 EC2가 있어서 매일 밤 10시에 켜지고 오전 6시에 꺼지게 해주세요.

구현 원리를 간단히 그림으로 표현해봤다.

AWS에서는 미리 정의된 Runbook을 제공하기 때문에 EC2 시작/중지 같이 사용 빈도가 높은 패턴들에 대해서는 사용자가 직접 스크립트를 구성하는 수고를 덜 수 있다. 특정 시간이 되면 이벤트가 발생하고, 이 이벤트가 SSM을 트리거하여 EC2를 시작/중지한다.

1. IAM 역할 생성하기

EC2, RDS 인스턴스를 시작하거나 중지하기 위해 EventBridge와 SSM을 사용하려면 다음 두 IAM 역할이 필요하다.

EventBridge 실행 역할 (자동 생성)
SSM Automation Document 실행 역할 (수동 생성)

1.1. 사용자 지정 정책 생성

EventBridge 실행 역할은 자동으로 생성되므로 여기서는 SSM Automation Document 실행 역할을 만든다.

1. AWS Management Console에 로그인하고, IAM 콘솔로 이동한다.

2. 왼쪽의 탐색 창에서 [정책]을 선택 > [정책 생성] 버튼을 클릭한다.

3. JSON 탭을 선택하고 다음 정책들을 붙여넣는다.

SSM Automation Document 실행 역할에 필요한 IAM 정책

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ssm",
            "Effect": "Allow",
            "Action": [
                "ssm:StartAutomationExecution",
                "ssm:DescribeAutomationExecutions",
                "ssm:GetAutomationExecution"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ec2",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*"
        },
        {
            "Sid": "rds",
            "Effect": "Allow",
            "Action": [
                "rds:StartDBInstance",
                "rds:StopDBInstance"
            ],
            "Resource": "*"
        }
    ]
}

ssm:StartAutomationExecution: 이 정책은 SSM이 자동화 문서를 시작할 수 있게 한다.
ssm:DescribeAutomationExecutions: 이 정책은 SSM이 자동화 실행의 상태를 설명하도록 한다.
ssm:GetAutomationExecution: 이 정책은 SSM이 특정 자동화 실행의 세부 정보를 가져올 수 있게 한다.
ec2:StartInstances and ec2:StopInstances: 이들 정책은 SSM이 EC2 인스턴스를 시작하거나 중지할 수 있게 한다.
rds:StartDBInstance and rds:StopDBInstance: 이들 정책은 SSM이 RDS 인스턴스를 시작하거나 중지할 수 있게 한다.

4. 구분하기 쉬운 정책 이름을 입력하고 정책 생성을 선택한다.

1.2. 역할 생성

1. IAM 콘솔로 왼쪽의 탐색 창에서 [역할]을 선택 > [역할 만들기] 버튼을 클릭한다.

2. 신뢰할 수 있는 엔터티 유형에서 AWS 서비스를 선택하고 System Manager를 선택한다.

3. 권한 추가 단계에서 앞서 생성한 정책을 명을 검색한 다음 선택한다. 이때 정책 이름을 검색하고 확인이 안된다면 엔터를 눌러보시길 ..

4. 다음으로 넘어가 역할 생성 완료하면 끝 !

5. 지금 생성한 역할은 이후 규칙을 생성할 때 AutomationAssumeRole에 입력해야 하므로 역할의 ARN 주소를 복사해 둔다.

IAM 역할의 ARN, IAM 콘솔에서 확인할 수 있다.

2. Event Bridge 구성

여기서는 평일 밤 9시마다 EC2가 종료되도록 구성해보겠다.

1. EventBridge 콘솔에서 규칙 생성을 선택한다.

2. 원하는 규칙 이름(예: stop-ec2-at-9pm)을 입력하고 규칙 유형을 일정으로 선택한다.

3. cron식으로 실행 시간을 지정한다. 이 크론 식은 월-금 오후9시에 이벤트가 발생하게 한다. 0 12 ? \* MON-FRI \*

4. 대상 유형을 다음과 같이 설정한다.

대상 유형: AWS 서비스
대상 선택: System Manager 자동화
문서: AWS-StopEC2Instance (문서는 생성하려는 규칙에 따라 StartEC2Instance등으로 교체하면 된다.)

5. 규칙을 적용할 EC2 인스턴스ID를 입력한다.

6. 1.2단계에서 복사해둔 IAM 역할의 ARN을 AutomationAssumeRole에 입력한다.

7. 이 특정 리소스에 대해 새 역할 생성을 선택하고 규칙 생성을 선택한다.

3. 자동화 실행 확인

인스턴스 상태 변경 알람이나 직접 확인해보면 실행 여부를 확인할 수 있다. 실행 내역에 대해 자세히 확인하고 싶으면 SSM 콘솔에서 [변경관리] > [자동화] 메뉴에서 확인이 가능하다.

마치며

다수의 인스턴스를 한번에 종료하려면 인스턴스 ID를 하나하나 넣어줘야하는 불편함이 있다. 인스턴수 수가 수십대가 되는 경우라면 EventBridge와 함께 Lambda를 사용하는 게 더 효율적일 것 같다. 편리할수록 종속성이 높고 자유도가 떨어진다는 것을 매번 깨닫게 된다. ㅠㅠ. 다음에는 태그값을 기반으로 인스턴스를 시작/중지할 수 있도록 구성해봐야겠다.

EC2 상태 변경 알람 Slack으로 받아보기

chnh — Thu, 1 Jun 2023 11:14:06 +0900

들어가며

이 글에서는 이전 포스팅에서 설명했던 EC2 상태 변경 알람을 Slack으로 받아보는 방법에 대해 다룬다. EC2 상태 변경 알람은 이벤트 패턴이 규정되어 있어서 따로 SNS 구독이나 CloudWatch 경보를 생성할 필요가 없다. 나는 개인용으로 사용할 거라 따로 Slack 앱을 생성하지 않고 Incoming Webhook을 사용할 예정이다.

이 과정을 수행하고 나면 EC2 상태가 변경됐을 때 다음과 같은 알람을 받게된다.

가트몬 이미지는 slack webhook icon을 변경했다.

작동 방식을 간단히 그림으로 표현하면 다음과 같다.

구성 방법

1. Slack Webhook 생성

Slack App directory에서 Incoming Webhook을 검색한다. Add to channel을 선택하고 알람을 수신받을 채널을 선택한다. 나는 개인적으로 받아볼거라 내 채널을 선택했다.

채널 선택 후 Add incoming WebHooks integration 버튼을 클릭하면 다음과 같은 화면이 표시된다. 스크롤을 다운하면 Webhook URL을 복사할 수 있다. Webhook URL을 다음 단계에서 Lambda의 환경변수로 설정해준다.
여기서 이름과 아이콘도 설정이 가능하다. 여기서 설정한 아이콘은 나중에 Slack 알람의 프로필 사진이 된다.

2. Lambda 함수 Deploy

Lambda 콘솔에서 함수 생성을 선택한다.
코드 소스를 입력하는 부분에 다음 함수를 붙여넣고 Deploy를 클릭한다. 이 함수는 github에서 계속 업데이트 될 예정이다.

# Slack Webhook으로 CloudWatch Event를 전송하는 함수 

from datetime import datetime, timedelta, timezone
import os
import urllib3
import json

# KST 시간대 정의 (UTC +9)
KST = timezone(timedelta(hours=9))

# Slack에 메시지를 전송하는 함수
def send_to_slack(webhook_url, msg):
    http = urllib3.PoolManager()
    encoded_msg = json.dumps(msg).encode('utf-8')
    resp = http.request('POST', webhook_url, body=encoded_msg)
    return resp

# Lambda 함수 핸들러
def lambda_handler(event, context):
    # 환경변수'SLACK_WEBHOOK_URL'에서 Slack Webhook URL 추출
    url = os.environ['SLACK_WEBHOOK_URL']     
    username = '[CloudWatch Alarm]' 
    pretext  = f'  [Event] {event["detail-type"]}'
    account = event['account']

    # 이벤트 시간을 KST로 변환하고, 문자열로 변환
    time = datetime.fromisoformat(event['time'].replace('Z', '+00:00')).astimezone(KST)
    formatted_time = time.strftime('%Y-%m-%d %H:%M:%S KST')  # 'KST' added

    region = event['region']
    detail = event['detail']

    # 메시지 텍스트 작성
    senText  =  f'Account : {account}\nTime : {formatted_time}\nRegion : {region}\nDetail : {detail}'  # Changed {time} to {formatted_time}
    msg = {
        "username": username,
        "pretext": pretext,
        "text": senText,
        "icon_emoji": ""
    }

    # Slack에 메시지 전송    
    resp = send_to_slack(url, msg)

    # 응답 상태 및 본문 출력
    print({
        "status_code": resp.status, 
        "response": resp.data.decode('utf-8')
    })

    return {
        'statusCode': resp.status,
        'body': resp.data.decode('utf-8')
    }

3. 환경 변수에 Webhook 입력

코드에 직접 Webhook을 입력하지 않도록하기 위해 환경변수를 사용하도록 구성했다.

구성 탭 > 환경 변수 > 환경 변수 편집을 선택한다.
키를 SLACK_WEBHOOK_URL 로 입력한다.
1단계에서 복사해둔 Webhook을 값으로 입력한다.

4. Lambda 트리거 추가

함수 개요 부분에 있는 +트리거 추가 를 선택한다.
트리거 구성에서 EventBridge를 선택하고 다음과 같이 설정한다.
규칙 유형: 이벤트 패턴
EC2 / EC2 인스턴스 상태 변경 알림
저장하면 함수 개요 탭에서 트리거가 생성된 것을 확인할 수 있다.
이후 EC2를 시작하거나 중지해보면 Slack 알람이 수신된다.

마치며

SNS 구독 설정 단계를 추가하면 State change 외에 다양한 CloudWatch 경보를 받아볼 수 있다. Lambda 함수를 변형해서 Slack으로 도착하는 메시지 내용과 형태를 변경할 수 있고, Slack에서 제공하는 API를 사용하여 대화형으로도 구성할 수 있다.

꼭 전파해야하는 이슈가 발생했을 때 공통 채널에 바로 게시할 수 있도록 설정해두면 의사소통 비용이 많이 줄어들 것으로 보인다. 다음에는 깃헙관련 내용으로 정리해봐야지.

AWS User Notifications로 AWS EC2 상태 변경 알람 받기

chnh — Thu, 25 May 2023 19:24:59 +0900

들어가며

AWS 계정을 해킹당해서 다량의 gpu 인스턴스가 생성되어 채굴에 사용되는 경우가 있다. 애초에 해킹 당하지 않도록 보안에 주의해야겠지만, 만약 예상하지 않은 리소스 시작이 발생한다면 빠르게 알아차리고 대응할 수 있는 것도 중요하다.

조직 단위로 비용알람을 걸어놓은 경우에도 해커가 조직을 탈퇴시킨 뒤에 인스턴스를 띄워서 인지가 늦어지는 경우가 있었다. 따라서 EC2시작 중지가 발생할 경우 즉시 인지하고 대응할 수 있도록 대비해야한다. 이를 위해 EC2 상태가 변경되면 Slack으로 알람을 받도록 Event Brigde + Lambda를 사용해서 구성하여 사용하고있다.

그런데 최근 AWS User Notification이라는 기능이 새로 출시되어 간편하게 EC2 Status 변경 알람을 설정할 수 있게 됐다. EC2외에 다른 서비스에 대한 알람 서비스도 제공한다. EventBridge를 사용하지 않고 여러 알람을 중앙 집중화해서 관리할 수 있으니 개인 계정을 관리할 때 가볍게 사용하기 좋겠다는 생각이 든다.

이 글에서는 콘솔을 사용해서 알람을 구성하고, 실제 Slack webhook을 사용해 구성한 알람과 어떤 차이가 있는지 살펴본다.

AWS User Notifications 구성 및 테스트

AWS User Notifications 서비스 콘솔로 들어간다.
[알림 구성] > [알림 구성 생성]을 선택한다. AWS 서비스와 특정한 이벤트 패턴을 선택할 수 있다. EC2외에도 여러 서비스들을 지원하고 있다.
고급 필터 기능을 통해 특정 태그가 있는 인스턴스만 알람을 받도록 설정할 수 있다.
집계 후 알람을 수신할 지 이벤트 발생 즉시 받을 지도 선택 가능하다.
이후 알람을 받을 엔트포인트를 설정하고, 실제로 EC2를 시작시켜봤다. (테스트 전에 Email Verification 과정이 필요하다.) Slack은 버튼을 누르자마자 변경 알림이 오고, Email은 Slack알람 도착 후 바로 뒤에 도착했다. 실제 시간차이는 1초도 안날듯(?)
1. AWS User Notifications에서 발송된 Email
2. EventBridge에서 Slack으로 발송된 알람, 내용은 커스텀 가능하다.

마치며

AWS에 사용자 편의를 고려한 서비스들이 점점 늘어나고 있는 것 같다. 기존에 여러 서비스를 결합해서 구성해야했던 것들을 하나의 서비스로 해결할 수 있게 하다니,, 어디까지 발전하려나 (?)

AWS User Notification은 다음과 같은 사람들에게 추천하고 싶다.

알람을 받고싶긴 한데 어떻게 해야 하는지 잘 모르겠다.
State change와 같은 특정 이벤트 패턴에 대해서만 알람이 필요하고, 발송되는 내용을 딱히 커스텀할 필요가 없다.
알람을 받는 채널이 Email, Chatbot, AWS App push로 충분하다.
메일로 수신할 때 텍스트만 있는게 아니라 포맷이 보기 좋게 되어있으면 한다.

참고자료

https://aws.amazon.com/ko/blogs/korea/new-set-up-your-aws-notifications-in-one-place/

chnh.dev

AWS 인스턴스 메타데이터와 IMDS

들어가며

인스턴스 메타데이터와 IMDS

실습 준비

1. 인스턴스 메타데이터 조회

2. 메타데이터를 통해 얻은 임시 자격 증명 사용

3. CloudTrail 로그 활성화

4. IMDS 취약점 해결 방안

1. 인스턴스 메타데이터를 요청할 때 IMDSv2를 사용해야 하도록 설정

2. IMDS 비활성화

3. IMDS 액세스 제한

마치며

AWS S3 취약점 및 보안

들어가며

실습 준비

S3의 접근 통제

1. S3 취약점

1. 버킷 생성과 '모든 퍼블릭 액세스 차단'

2. ACL 활성화

3. 버킷 정책 수정

4. 실습 리소스 삭제

2. S3 보안 강화

1. Pre-Signed URL 활성화

2. Require HTTPS

3. SSE-KMS 암호화 사용

4. AWS Config 규칙을 사용하여 퍼블릭 버킷 감지

마치며

참고 자료

Terraform 코드 네이밍 컨벤션

들어가며

Terraform 코드 네이밍 컨벤션

1. 자원 이름에 -(dash)대신 _(underscore) 사용

2. 소문자 사용

3. 중복 최소화

4. 이름에는 기본적으로 단수 명사를 사용한다.

5. tag는 마지막에

6. variable block 안에 들어가는 key 값들을 어떻게 정렬할지 미리 설정하기

7. Output의 이름은 {name}_{type}_{attribute} 구조로

마치며

참고자료

Golden Image Pipeline 구성 - 2. GitHub Actions로 이미지 생성 자동화

들어가며

1. Github Actions Secret 설정

2. Github Actions workflow 구성

3. Github Repository로 push

참고자료

Golden Image Pipeline 구성 - 1. Packer와 Ansible로 이미지 만들기

들어가며

Immutable Infrastructure와 Golden Image

Packer와 Ansible

1. Packer, Ansible 설치

2. Ansible playbook 작성

3. Packer 템플릿 생성

4. Packer 이미지 빌드

5. AMI로 EC2 생성

마치며

GitHub Actions Workflow 문법 정리

들어가며

Workflow syntax for GitHub Actions

name - 선택사항

run-name - 선택사항

on

jobs

참고자료

키페어 없이 AWS CLI를 사용하여 EC2 인스턴스에 SSH로 연결하기

들어가며

EC2 Instance Connect란?

AWS CLI로 Linux 인스턴스에 연결하기

1. AWS CLI 업그레이드

2. 인스턴스 ID 조회

3. 인스턴스 연결

마치며

System Manager로 특정 시간에 EC2 인스턴스 시작/중지 자동화하기

들어가며

1. IAM 역할 생성하기

1.1. 사용자 지정 정책 생성

1.2. 역할 생성

2. Event Bridge 구성

3. 자동화 실행 확인

1. 자원 이름에 `-`(dash)대신 `_`(underscore) 사용