G리는 블로그

s3 에 업로드된 파일을 주기적으로 삭제시키려면 수명 주기를 구성해야 한다. ex) 3일뒤 삭제

AWS 콘솔을 이용하거나 AWS CLI 를 사용할 수 있다.

1. AWS 콘솔 이용

• S3 버킷 -> 관리 -> 수명 주기 규칙 생성
• 규칙의 범위를 제한한다면 접두사로 적용할 디렉토리 지정 ex) mydir/
• 객체의 현재 버전 만료 체크 -> 일자 지정 ex) 3

2. AWS CLI 이용

S3 객체를 삭제할 마음이 있을 정도의 유저라면 aws cli 준비가 되어 있다고 가정하고...

$ aws s3api put-bucket-lifecycle-configuration --profile my_profile --bucket my_bucket_name --lifecycle-configuration '{ 
  "Rules": [       
    {                    
      "ID": "Delete objects after 3 days myDir",
      "Prefix": "myDir/",
      "Status": "Enabled",
      "Expiration": {
        "Days": 3
      }
    }
  ]
}'

위 cli 를 사용하면 1번 aws 콘솔을 사용한 것과 동일한 결과를 얻을 수 있다.

이 설정 이후로, my_bucket_name 버킷의 myDir 디렉토리 안의 모든 객체는 매일 특정 시간대에 체크되며, 업로드 된지 3일이 지난 객체는 영구 삭제된다.

3. MFADelete 이슈

수명 주기 규칙을 생성하려고 할 때, MFA(Multi-Factor Authentication) 가 활성화되어 있다는 메시지를 보게 된다면...

An error occurred (InvalidBucketState) when calling the PutBucketLifecycleConfiguration operation: Cannot put lifecycle configuration on a bucket that has MFA enabled

수명 주기 설정에는 MFA 가 필요하다는 말인데, s3 에 웬 MFA 인고 하니...

버킷 속성에 보면 [MFA 삭제] 항목이 활성화 되어 있다. 객체 삭제시 MFA 인증이 필요하다는 말이다. (내가 한건 아닌거 같은데...;;)

아무튼 이 항목을 수정하려면 root 계정 profile 과 MFA 인증키가 필요하다. 다음과 같이...

$ aws s3api put-bucket-versioning --bucket my_bucket_name --versioning-configuration MFADelete=Disabled,Status=Enabled --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 743015" --profile root
$ aws s3api get-bucket-versioning --bucket my_bucket_name                                                                                                                      
{
    "Status": "Enabled",
    "MFADelete": "Disabled"
}

위 코드에서 수정.

• 버킷명 (my_bucket_name)
• MFA삭제 여부 (MFADelete) : Disabled (반대로 활성화 할 경우는 enable)
• 계정ID (111122223333)
• MFA 코드 입력 (743015)
• profile : 실제 루트 credencials

CodeCommit 의 저장소에 접근하는 방법은 3가지가 있다.

1. HTTPS : 가장 간편. IAM 사용자라면 https git 자격 증명을 발급 받아 접근 가능
2. SSH : IAM 사용자로서 SSH 키 페어 발급 및 사용 (로컬에 host, config 파일 설정)
3. HTTPS (GRC): 나머지 루트 계정, 페더레이션 액세스, 임시 보안 인증 정보 사용으로 접근 가능

GRC(git-remote-codecommit) 방식은, git-remote-codecommit 이라는 툴을 사용하여 저장소에 접근하는 방법인데, 다른 AWS 계정의 IAM 사용자에게 저장소를 공유하기 위해 사용해 보겠다.

1. 정책/역할 생성

다른 AWS 계정에게 부여할 정책을 생성한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codecommit:BatchGet*",
                "codecommit:Create*",
                "codecommit:DeleteBranch",
                "codecommit:Get*",
                "codecommit:List*",
                "codecommit:Describe*",
                "codecommit:Put*",
                "codecommit:Post*",
                "codecommit:Merge*",
                "codecommit:Test*",
                "codecommit:Update*",
                "codecommit:GitPull",
                "codecommit:GitPush"
            ],
            "Resource": [
                "arn:aws:codecommit:us-east-2:111122223333:MySharedDemoRepo"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "codecommit:ListRepositories",
            "Resource": "*"
        }
    ]
}

역할(FirstRepositoryRole)을 생성하여 위 정책을 연결하고 역할 ARN 을 복사하여, 다른 AWS 계정의 IAM 사용자에게 공유한다. 

arn:aws:iam::111122223333:role/FirstRepositoryRole

필요하다면 위 정책 대신 powerful 한 정책을 부여해도 된다. (예, AWSCodeCommitPowerUser)

2. 접근할 다른 AWS 사용자(또는 그룹)에 정책 추가

저장소에 접근할 다른 AWS 계정의 IAM 사용자 또는 그룹에 정책 추가.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::111122223333:role/FirstRepositoryRole"
  }
}

3. 프로필 설정

다른 AWS 계정의 IAM 사용자는 git-remote-codecommit 을 사용하여 CodeCommit 저장소에 접근할 수 있도록 로컬 컴퓨터에 프로필을 구성해야 한다.

$ aws configure --profile my_profile
AWS Access Key ID [None]: Your-IAM-User-Access-Key
AWS Secret Access Key ID [None]: Your-IAM-User-Secret-Access-Key
Default region name ID [None]: us-east-2
Default output format [None]: json

일반적으로 설정하는 위 방식으로 IAM 사용자 인증 정보를 등록하면 사용자 디렉토리의 .aws/credential .aws/config 파일이 생성되는데 config 파일에 FirstRepositoryRole 저장소 접근 전용으로 사용할 프로필(repo1) 을 하나 생성해서 arn 정보와 연결 프로필(source_profile) 을 삽입한다.

[profile repo1]
region = us-east-2
role_arn = arn:aws:iam::111122223333:role/FirstRepositoryRole
source_profile = my_profile

4. git-remote-codecommit 설치

pip 가 설치되어 있지 않다면, 설치.

$ curl -O https://bootstrap.pypa.io/get-pip.py
$ python3 get-pip.py --user

$ pip install git-remote-codecommit

만약 맥에서 아래와 같이 externally-managed-environment 에러가 발생했다면, 이미 Python 이 homebrew 를 통해 설치되어 시스템 전체에 영향을 미칠 수 있기 때문이다.

% python3 get-pip.py --user
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install
    xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a Python library that isn't in Homebrew,
    use a virtual environment:
    
    python3 -m venv path/to/venv
    source path/to/venv/bin/activate
    python3 -m pip install xyz
    
    If you wish to install a Python application that isn't in Homebrew,
    it may be easiest to use 'pipx install xyz', which will manage a
    virtual environment for you. You can install pipx with
    
    brew install pipx
    
    You may restore the old behavior of pip by passing
    the '--break-system-packages' flag to pip, or by adding
    'break-system-packages = true' to your pip.conf file. The latter
    will permanently disable this error.
    
    If you disable this error, we STRONGLY recommend that you additionally
    pass the '--user' flag to pip, or set 'user = true' in your pip.conf
    file. Failure to do this can result in a broken Homebrew installation.
    
    Read more about this behavior here: <https://peps.python.org/pep-0668/>

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

이 경우, 가상환경으로 세팅하는 것이 안정적이다.

$ python3 -m venv grc
$ source grc/bin/activate

$ python3 -m pip install git-remote-codecommit

5. git clone 

HTTPS(GRC) 주소를 복사한 후 저장소 이름 앞에 프로필@ 추가하여 소스 복제

예) codecommit::ap-northeast-2://MySharedDemoRepo

$ git clone codecommit::ap-northeast-2://repo1@MySharedDemoRepo

말 그대로 인스턴스를 미리 예약(구매)하는 것이다. 내가 사용할 인스턴스를 1년 이상 약정하고 그 만큼의 할인 혜택(최대75%)을 받는 것이다. 인스턴스 서비스를 제공하는 Amazon EC2, RDS, ElastiCache, OpenSearch, Redshift 등이 대상이다. 일단 인스턴스를 미리 생성해서 사용하다가, CPU/MEM 등이 적절한 인스턴스 사양을 찾아 최대한 빨리 RI 를 적용하는 것이 이득이다. 1년도 사용하지 않을 계획이라도 RI 적용이 이득일 수도 있다.

RI 설정

해당 서비스의 대시보드에 들어가면 좌측 메뉴에 예약 인스턴스(Reserved Instance), 예약 노드 등이 있는데 이곳에서 RI 를 생성하면 된다. 부수적인 옵션이 각각 있지만, 공통적으로 사용할 인스턴스 사양, 결제방법 등이 중요하다.

결제방법 (1년/3년)

• 선결제 없음 : 매달 할인 받은 금액으로 결제 (일반적으로 선택)
• 부분 선결제 : 반 선결제 하고, 매달 할인 받은 금액 결제
• 전체 선결제 : 즉시 전체 결제하고 1년/3년 사용

전체 선결제는 즉시 결제이므로 3가지 결제방법 중 할인율이 가장 크다. 선결제 없음은 초기 비용이 발생하지 않지만 3가지 결제방법 중 할인율이 가장 적다. 1년/3년을 무조건 사용할 예정이라면 전체 선결제를 선택하면 되고, 그 안에 사양 업그레이드 등 변화가 예상되는 경우는 선결제 없음을 선택하는 것이 좋다. 사용하던 하지 않던 구매하는 순간 요금은 발생되므로 주의해야... 해당 RI 가 만료되면 온디맨드 요금으로 변경되므로, 수동 재계약. (예약 구매 가능)

EC2 RI 사용 예)

예1) 1일부터 c5.xlarge 를 이용해오다, 15일에 해당 서비스의 ri 를 구매할 경우
 - 적용시간부터 ri 요금이 적용된다.

예2) 1일부터 c5.xlarge 를 이용해오다, 15일에 c5.2xlarge 로 교체할 경우 (인스턴스 크기 유연성: 같은 리전의 정규화 시간당 유닛만큼 할인)
 - 15일부터 사용하는 c5.2xlarge(16) 의 요금중, 기존 사용중인 c5.xlarge 의 정규화 시간당 유닛(8)만큼 할인 받고, 나머지 c5.xlarge(8) 의 온디맨드 요금 발생

예3) RI 구매했지만 서비스를 그만 사용할 경우
 - Marketplace 에 등록하여 남은 사양만큼을 타인에게 판매.

표준 타입이 아닌 컨버터블 타입의 RI 를 사용한다면, 다른 인스턴스 패밀리(m, x, r...), 운영 체제 또는 테넌시를 변경할 수 있는 여러가지 옵션들이 있으며 다른 RI 와 병합도 가능하다. (비싼 요금에서 싼 요금으로의 변경은 불가능하다...) 컨버터블 타입의 경우, 요구조건이 까다로워서 AWS 문서를 확인하는 편이 확실할 듯 하다. EC2 가 아닌 다른 대부분의 다른 서비스 RI 는 수정/삭제가 불가능하므로, 마찬가지로 주의해서 생성해야 한다. RDS, ElastiCache, OpenSearch, Redshift...

요금 비교

권한이 있다면(ViewBilling,ViewAccount, ...), 비용(Cost) 대시보드에서는 최근 사용해 온 서비스 들로부터 RI 권장사항도 확인할 수 있다. 또는, 본인이 사용하는 서비스의 인스턴스 사양의 온디맨드 요금과 예약 인스턴스 요금을 구글에서 검색해 본다.

예) ec2 ri 요금

RI 만료 알람

기본적으로 RI 만료 알람 기능은 제공하지 않는다. lambda 를 쓰던 해서 만들어야 하는데 깔끔하지 않다. 그냥 어딘가에 잘 적어놓고 관리하는 걸로..;; ㅜ

약 1년 정도 EKS fargate + grafana 로 모니터링과 알람을 사용했다. 이왕 설치했으니까, 나름 피곤한 세팅 해가면서, 이쁘게 커스텀 잘 해왔는데, 보안 점검때마다 EKS 와 plugin 을 최신버전으로 올리는 바람에 그 때마다 Node 날아가고 전부 새로 설치+세팅 해야 한다는 점... 한번은 그냥 기분 좋게 했었는데, 두번은 못하겠다. 이게 다 fargate 를 사용해서...? AWS 의 EKS 인 만큼, AWS 안에서 모니터링과 알람을 만드는 것이 옳다고 생각하고 방법을 찾아봤다.

CPU / MEM / Traffic 모니터링은 기본이고, 배포시(혹은 장애시) 슬랙 알림 전송이 목표이며, 유일하게 AWS CloudWatch Container Insights 를 찾았다.

Container Insights 는 ECS/EKS 의 EC2/Fargate 에서 컨테이너 어플리케이션의 지표 및 로그를 수집하고 집계할 수 있다. 일반적으로 워커노드의 kubelet 이 /metrics/cadvisor 엔드포인트에서 CPU, 메모리, 디스크, 네트워크 사용량 등의 리소스 지표를 노출하는데, EKS Fargate 네트워킹 구조상 이 kubelet 에 접근이 안되기 때문에 프록시 역할을 할 ADOT(AWS Distro for OpenTelemetry 수집기를 사용하여, 워커노드의 지표 및 로그(CPU, 메모리, 트래픽) 들을 CloudWatch 로 전달한다. 그럼에도 CloudWatch 의 [향상된 관찰 기능] 은 지원되지 않는다.

ADOT Pod 생성

1. fargate profile 생성

$ kubectl create namespace fargate-container-insights
namespace/fargate-container-insights created

2. 서비스 계정 생성

ADOT 수집기에는 성능 로그 이벤트를 CloudWatch로 보내려면 IAM 권한이 필요하다. AWS 관리형 정책 CloudWatchAgentServerPolicy 와 연결할 역할(EKS-Fargate-ADOT-ServiceAccount-Role)을 만들고, EKS 의 서비스계정(adot-collector) 을 생성하여 연결하는 스크립트이다. YOUR-EKS-CLUSTER-NAME 과 YOUR-EKS-CLUSTER-REGION 을 적절히 수정한다.

$ ##!/bin/bash
CLUSTER_NAME=YOUR-EKS-CLUSTER-NAME
REGION=YOUR-EKS-CLUSTER-REGION
SERVICE_ACCOUNT_NAMESPACE=fargate-container-insights
SERVICE_ACCOUNT_NAME=adot-collector
SERVICE_ACCOUNT_IAM_ROLE=EKS-Fargate-ADOT-ServiceAccount-Role
SERVICE_ACCOUNT_IAM_POLICY=arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

$ eksctl utils associate-iam-oidc-provider \
--cluster=$CLUSTER_NAME \
--approve

$ eksctl create iamserviceaccount \
--cluster=$CLUSTER_NAME \
--region=$REGION \
--name=$SERVICE_ACCOUNT_NAME \
--namespace=$SERVICE_ACCOUNT_NAMESPACE \
--role-name=$SERVICE_ACCOUNT_IAM_ROLE \
--attach-policy-arn=$SERVICE_ACCOUNT_IAM_POLICY \
--approve

2023-11-27 22:09:08 [ℹ]  eksctl version 0.75.0
2023-11-27 22:09:08 [ℹ]  using region ap-northeast-2
2023-11-27 22:09:09 [ℹ]  1 iamserviceaccount (fargate-container-insights/adot-collector) was included (based on the include/exclude rules)
2023-11-27 22:09:09 [!]  serviceaccounts that exist in Kubernetes will be excluded, use --override-existing-serviceaccounts to override
2023-11-27 22:09:09 [ℹ]  1 task: {
    2 sequential sub-tasks: {
        create IAM role for serviceaccount "fargate-container-insights/adot-collector",
        create serviceaccount "fargate-container-insights/adot-collector",
    } }2023-11-27 22:09:09 [ℹ]  building iamserviceaccount stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:10 [ℹ]  deploying stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:10 [ℹ]  waiting for CloudFormation stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:26 [ℹ]  waiting for CloudFormation stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:43 [ℹ]  waiting for CloudFormation stack "eksctl-test-addon-iamserviceaccount-fargate-container-insights-adot-collector"
2023-11-27 22:09:43 [ℹ]  created serviceaccount "fargate-container-insights/adot-collector"

3. ADOT StatefulSet 배포

https://github.com/aws-observability/aws-otel-collector/blob/main/deployment-template/eks/otel-fargate-container-insights.yaml

파일을 다운받아, YOUR-EKS-CLUSTER-NAME 과 region=us-east-1 을 적절히 수정하여 배포한다.

$ kubectl apply -f eks-fargate-container-insights.yaml
clusterrole.rbac.authorization.k8s.io/adotcol-admin-role created
clusterrolebinding.rbac.authorization.k8s.io/adotcol-admin-role-binding created
configmap/adot-collector-config created
service/adot-collector-service created
statefulset.apps/adot-collector created

4. CloudWatch Log Group 확인

몇 분이 지나면 CloudWatch 로그 그룹에 로그가 쌓이는 것을 확인할 수 있다.
/aws/containerinsights/CLUSTER_NAME/performance

5. CloudWatch 대시보드 생성

Metrics > ContainerInsights 지표를 활용하여 CPU, 메모리, 트래픽 정도의 대시보드를 구현할 수 있다.
(배포 알림은 ContainerInsights 가 아닌 ALB target-group 의 HealthyHostCount 로 측정하였음. PromQL 가 없으니 잇몸으로...)

간만에 ingress 하나 생성하려는데 태클이...

$ kubectl describe ingress my_ingress -n my_namespace

  Type     Reason             Age    From     Message
  ----     ------             ----   ----     -------
  Warning  FailedDeployModel  3m41s  ingress  Failed deploy model due to AccessDenied: User: arn:aws:sts::110111011101:assumed-role/myEKSLoadBalancerControllerRole/1234561234561234561 is not authorized to perform: elasticloadbalancing:AddTags on ause no identity-based policy allows the elasticloadbalancing:AddTags action

구글에서는 위 에러 메시지와 관련된 내용은 찾기 어려웠다. AWS 문서 뒤적이며 loadBalancerController 생성하는 부분을 찾아보니, iam_policy.json 파일이 v2.3.0 에서 v.2.5.4 로 업데이트 되어 있었고, 아래 정책이 추가된 것을 확인했다.

        ...
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:AddTags"
            ],
            "Resource": [
                "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*",
                "arn:aws:elasticloadbalancing:*:*:loadbalancer/net/*/*",
                "arn:aws:elasticloadbalancing:*:*:loadbalancer/app/*/*"
            ],
            "Condition": {
                "StringEquals": {
                    "elasticloadbalancing:CreateAction": [
                        "CreateTargetGroup",
                        "CreateLoadBalancer"
                    ]
                },
                "Null": {
                    "aws:RequestTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        ...

AWS 콘솔에서 myEKSLoadBalancerControllerRole 을 찾아 연결된 정책 AWSLoadBalancerControllerIAMPolicy 에 위 스니펫을 삽입하여 해결...

내용은 대충 TargetGroup / LoadBalancer 생성할 때 리소스에 태그지정하는 권한 같은데... 참 쓰잘데기 없다. 아니 매년 이렇게 미친듯이 강제로 업데이트 하는게 맞는거야? 

(참고) https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/aws-load-balancer-controller.html

웹 공격, 특히 DDoS 대응으로 방화벽을 설치하라고 한다. (난 안전불감증으로, WAF 설치의 필요성은 못느끼고 있다.)

AWS 에서는 WAF 라는 웹 어플리케이션 방화벽 서비스를 제공한다. 고급 사양으로는 DDoS 방어에 특화된 AWS Shield, 여러 계정/리소스 관리를 간소화 하는 AWS Firewall Manager 가 있지만 생략한다. (여유자금 있으면 쓰면됨)

십수 년 전 suhosin 사용했을 때도 그렇지만, 설정을 빡세게 할수록 방화벽의 기능을 십분 활용할 수 있지만, 그렇게까지 할 필요가 있나 싶다. 공격을 완벽하게 막기란 쉽지 않고, 까딱 잘못하면 정상적인 요청마저 거부할 수도 있고, 슬프지만 내가 개발한 서비스가 누군가의 타겟이 될 정도로 인기 있지도 않기 때문이다. 참고로 20년 동안 방화벽에 대한 필요성을 느낀 적이 단 한번도 없었다. 그래도 방화벽을 달아야 하는 상황이라 아주 기본적인 설정만 해보려고 한다.

WAF 는 기본적으로, AWS 리소스 일부를 보호할 수 있으며, HTTP(S) 요청에 대한 IP / 국가 / 헤더 / 요청횟수 등으로 접근 허용이나 거부를 할 수 있다. (SQL Injection / XSS 생략) 프론트 단의 CloudFront 와 백엔드의 API 서버 중 alb 에만 방화벽을 설치해 보았다. 가장 기본적인 규칙들만 몇 개 적용하고 Bot Control / Capcha 등은 사용하지 않았다.

1. 서버 접근 패턴 파악

우선은 방어 전략을 짜기 전에, 해당 서버에 로그를 수집하여 패턴을 파악해 봐야 한다. 물론 처음부터 빡세게 제한하는 것도 좋지만, 이미 운영중일 경우는 기존 서비스에 장애가 발생하지 않도록 면밀히 분석해야 한다.

다행스럽게도 서버 대부분은 해외IP 로부터 SQL Injection / XSS 접근이 전부여서 Source IP 가 해외인 접근만 차단하는 것으로 완벽 차단이 가능했다. 사실 그것보다는 DDoS 공격에 대비하는 것이 목표라, 해외IP 차단 + 국내IP 에서 초당 100개 요청시 IP 차단 하는 Rule 로 처리하기로 했다.  

2. Rule 세팅 및 리소스 적용

• Rule : 제어 규칙 생성
• Rule Group : 재사용 가능한 사용자 정의 Rule Group 을 생성할 수 있고, AWS Marketplace 에서 유/무료 관리형 규칙 그룹을 선택할 수도 있다. (규칙 수, 복잡도에 따라 요금 증가)
• Web ACLs(제어목록) : 특정 규칙집합을 만들고 AWS 리소스를 연결하여 요청 제어 수행
  ㄴ 기본동작 (Allow / Block) 설정
  ㄴ 규칙 우선순위는 화면 위에서 아래, 낮은 숫자에서 높은 숫자 순

3. 모니터링 및 알람 설정

모니터링으로 요청에 대한 규칙 및 필터링 확인을 마쳤다면, CloudWatch 에서 특정 메트릭(예: 차단된 요청 수 - BlockedRequests)이 기준치를 초과할 때 SNS 알림을 트리거하도록 설정하여 운영하도록 한다. (알람 세팅 생략...)

4. 요금

(예, 관리형 규칙X, 사용자 규칙 19)

• 웹 ACL 요금 = 5.00 USD * 1 = 5.00 USD
• 규칙 요금 = 1.00 USD * 19(규칙) = 19.00 USD
• 요청 요금 = 1백만 건당 0.60 USD * 1천만 건 = 6.00 USD
• 결합된 총 요금 = 월별 30.00 USD

저렴한 편...

EKS 버전 업그레이드 (1.28 -> 1.31) 후에 대표 관리자를 제외한 부 관리자들이 EKS 모니터링 실행에 실패하는 현상이 나타났고, 실패 로그는 아래와 같았다.

Proxy request for clusterId="11115f91f1f9e3f0c97e4c3692f41111" to url="/apis/metrics.eks.amazonaws.com/v1" has statusCode=401
Proxy request for clusterId="11115f91f1f9e3f0c97e4c3692f41111" to url="/apis/metrics.eks.amazonaws.com/v1" failed with UNAUTHORIZED

aws-auth ConfigMap 에는 기존 버전 그대로 해당 사용자들의 권한이 명시되어 있었다.

  mapUsers: |
    - groups:
      - system:masters
      userarn: arn:aws:iam::111151101111:user/honggildong

다른 모든 api 권한은 문제가 없는데, 제어 플레인 (control plane) 메트릭 가져오는 api 만 인증되지 않았다는게 당최 어디서 설정을 해야 하는건지...

그렇게 찾다보니, EKS 액세스 관리 제어에 관련된 AWS 기술 블로그를 찾았다.
https://aws.amazon.com/ko/blogs/tech/a-deep-dive-into-simplified-amazon-eks-access-management-controls/

기존의 액세스 권한 부여 방식이 복잡했기 때문에, 액세스 관리 제어 기능을 통해 AuthN(인증) / AuthZ(권한) 부분을 간소화 하였다는 내용이다.

EKS 관리 제어에 두가지 용어가 추가됐다.
- 액세스 항목(access entries) : IAM 사용자나 역할에 연결되어 EKS 클러스터를 인증 (AuthN)
- 액세스 정책(access policy) : 특정 클러스터 작업에 대한 EKS 만의 권한 부여 (AuthZ)

액세스 항목 + 액세스 정책 대신 기존의 RBAC(Role-Based Access Control: 역할 기반 액세스 제어) 의 권한 부여(ClusterRoleBinding) 와 결합하는 것도 가능하다.

특정 클러스터에의 사용자에게 권한을 주려면 액세스 항목에 IAM 사용자나 역할로 생성하고, 정책을 할당하여 특정 권한을 부여하는 프로세스 이다. (기존에는 위 예제처럼 ConfigMap 에 IAM 정보와 권한을 부여할 group 을 설정했었다.) 이 기능이 2024년 7월 경 오픈되었고 이 날 이후에 업그레이드된 클러스터에서는 인증/권한 설정에 대해 기존의 CONFIG_MAP, 새로운 API, 두가지 모두 사용 가능한 API_AND_CONFIG_MAP 모드를 선택하게 됐다. 이 문서에서는 기존 클러스터를 API_AND_CONFIG_MAP 인증 모드로 설정하고, 기존의 aws-auth configMap 에서 사용된 동일한 ID / 그룹을 지정하여 동등한 액세스 항목을 생성할 것을 권장하고 있다. access_entries / aws-auth 모두 설정되어 있을 경우, 우선순위는 액세스 항목 > ConfigMap 순이다. 또한 클러스터 뿐아닌 네임스페이스 레벨의 권한도 설정이 가능하다.

명령) 특정 클러스터에 IAM ARN 인증 및 권한 설정

$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks associate-access-policy --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
  --access-scope type=cluster

하지만 다 필요없고, EKS 대시보드에서 아주 간편하게 액세스 관리 제어를 설정할 수 있다...

EKS 액세스 항목에 부 관리자 IAM 설정하고, 정책(AmazonEKSClusterAdminPolicy) 연결해서 문제는 해결됐다. 하지만 위의 오류가 발생했던 이유는, 지금도 잘 모르겠다. 버전 업데이트 후에 액세스 관리 제어 설정이 안되어 있어서 configMap 에만 의존하고 있었을 것이고, ConfigMap 에 설정된 system:masters 권한이라면 기존과 동일하게 api 권한의 문제는 없었어야 했는데, 다른 api 는 다 되고 metric api 만 거부됐다는게...

몰라몰라~~

이제 aws-auth ConfigMap 에서 사용자 권한을 편집할 필요가 없어졌다. 추후 EKS 에서 ConfigMap 이 제거된다고 하니 액세스 관리 제어의 사용은 필수...

AWS 에서 웹 어플리케이션 배포하는 방법.

1. EC2
2. Elastic Beanstalk
3. ECS
4. EKS

이 중 그나마 간편하고, 빠르게 배포하는 방법은 1번 아니면 2번 일 것이다. 빠르게 웹 공유가 필요하여 간만에 Elastic Beanstalk 를 썼는데 완전 삽질스.

일단 2024년 10월 1일 이후로는, EC2 Auto Scaling 서비스의 시작 구성이 사라지고, 시작 템플릿으로 대체되기 때문에, EB 환경을 새로 생성한다면 시작 템플릿(launch template) 옵션을 선택해야 한다. 환경 설정 중 선택만 해주면 된다.

• RootVolumeType : gp3 (범용3 SSD)
• IMDSv1 : disable

와~ gp3 선택하지 않은 죄로 삽질 무지하게 했다.

Creating Auto Scaling launch configuration failed Reason: Resource handler returned message: "The Launch Configuration creation operation is not available in your account. Use launch templates to create configuration templates for your Auto Scaling groups. (Service: AutoScaling, Status Code: 400, Request ID: 67f0a370-3fa3-42f9-bfc1-4ebdc96b3378)" (RequestToken: e7362a93-5127-6af3-e9a5-90b793868367, HandlerErrorCode: GeneralServiceException)

CloudFormation 스택 템플릿에 보면 Launchconfiguration 이 구동되는지 Launchtemplate 이 구동되는지 확인할 수 있다. 어차피 에러나면 딱히 확인할 필요는 없지만...

간만에 EB 구동 정리나...

• 미리준비 : VPC / 서비스 역할 / EC 키페어 / EC2 인스턴스 프로파일
• 수동설정 : 루트볼륨유형 gp3 / 인스턴스 유형

EC2 인스턴스 프로파일 이란걸 썼었는지 기억도 안난다.

서비스 역할에 필요한 정책 (EC2, ELB, EC2 Auto Scaling API 호출에 필요)

• AWSElasticBeanstalkEnhancedHealth
• AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy

EC2 인스턴스 프로파일 정책

• AWSElasticBeanstalkWebTier
• AWSElasticBeanstalkWorkerTier
• AWSElasticBeanstalkMulticontainerDocker

나머지 환경 속성이나 기타 등등은 구동 확인 후 수정 가능하다.