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 이 제거된다고 하니 액세스 관리 제어의 사용은 필수...

웹 공격, 특히 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 ACL(제어목록) : 특정 규칙집합을 만들고 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

11월 7일 우연히 '오블완 챌린지' 를 보고, 심심한데 1등이나 노려볼까? 하는 생각으로 열심히 비공개를 풀었는데, 정신 차려보니 11월 15일이네 ㅋㅋ 욕심 좀 부려서 1등 상품인 아이폰16 Pro 한번 노려 보려고 했는데...

비공개한게 8개월 정도는 됐으려나... 양질은 아니지만서도 조금이나마 광고비 좀 받아볼까 했더니만, 뭔 자동클릭을 감지했다나 말 같지도 않은 태클들로 짜증나게 해서 커스텀 다 빼버리고 적당한 블로그로 다시 갈아타보려고 했는데 참 쓸만한 블로그 찾기 힘들었었지. 얘는 이게 아쉽고, 쟤는 저게 아쉽고, 그래서 그냥 답답한 마음에 닫았었던가... 근데 다시 그대로 열었네ㅋ 내가 왜 그랬을까.. 이런 말도 안되는 이벤트로 다시 일상을 쓰게 됐다는게 좀 어이없긴 한데...

요즘 내 일과이자 내 삶. 매일 야근에 집에 도착하자마자 출근 준비 해놓고 잠자기 바쁘고, 술만 안먹으면 아침 운동가서 온 에너지 불태우고, 회사에서는 또 정신없이 하루가 다 지나가고. 이 세상이 어떻게 돌아가는지 화장실에서나 자기 직전에 헤드라인 한번 훑어보고. 가끔씩 술 땡길 때 일찍 퇴근해서 술이나 한잔 때리고. 이렇게 사는게 맞는 거겠지? 돈을 주니까 일은 하겠는데, 언제 짤릴지 모르니 짤릴 때까지는 죽은 듯 붙어 있는게 맞는 거겠지? 괜히 이 나이에 뛰쳐나갔는데 다른 데서 안써주면 허무하니 일이 많은걸 다행이라 생각하고 열심히 일하는게 맞는 거겠지? 이제 놀러다녀보고 싶은데도 딱히 없고, 이래저래 돌아다녀봤자 기름값만 나오니 그냥 들어와 있는 물에서 열심히 노 젓는게 맞는 거겠지? 집에 있으면 몸뚱이만 굳으니까 휴일에도 알바나 하면서 한 푼이라도 더 버는게 맞는 거겠지? 요즘은 그저 집이나 하나 장만하겠다는 마음에 술값 빼고 다 아끼고 살고 있는데, 집값이 월급보다 더 빨리 올라서 이대로는 영원히 올라탈 수 없을 것 같은데, 대출도 다 줄었지만 운 좋게 영끌해서 집 한채 장만한다고 한들, 이자만 갚다가 죽게 되겠지. 그래도 열심히 일하고 벌어서 집을 장만 하는게 맞는 거겠지? 그렇겠지? 확실하냐??

가끔은 전 직원 퇴근하고 홀로 사무실에 앉아 있으면 이런 생각이 든다. 내가 일을 못하는 건지. 나만 열심히 일을 하는 건지. 내가 제일 늙어서 안 짤릴라고 열심히 하는 건지. 어렸을 때부터 아이큐가 좋다고 생각해 본 적 없고, 난 단지 '노력파' 란 생각으로 나름 성실히 살아 왔고, 그러다 보니 뭔가를 효율적으로 하는 방법은 모르는 거 같고, 융통성도 별로 없는 거 같고, 쓸데없이 완벽을 추구하려고 하고, 그러면서 완벽하게는 못하고. 그렇다고 아이큐가 낮은 사람이 무언가를 연구해서 아이큐를 높여 보겠다는 것은 아니고, 그냥 나를 파악했으니 그냥 그런 줄 알고 그냥 이렇게 살겠다는 얘기이다. 바뀔 수 있는 문제도 아니고, 아무리 그래도 중간은 하겠지... 라는 영혼없는 마인드로...

이제 뭔가를 한다는게, 딱히 하고 싶지도 않고, 흥미로운 것도 없고, 술과 안주에 대한 마음도 예전 같지 않지만 그래도 그나마 아드레날린 뿜을 수 있는건 술 뿐이지! 짠하다고 생각할 테지만 그래도 지금은 그냥 사무실에 앉아서 컴퓨터나 두드리는게 제일 편안하다. 더울 때 시원하고, 추울 때 따듯하고, 밥주고, 재워주는 사람은 없어도 맘만 먹으면 잘 수도 있고. 왜 따로 월세를 내고 살고 있는거지... 그래도 흥미(?)로운 무언가가 언젠간 생길지 모르니, 몸이나 녹슬지 않게 기름칠 잘 해놔야지. 언젠가 다시 아드레날린이 솟구칠 날을 기다리며...

간만에 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

<좌: 2022년 9월 / 우: 2024년 1월>

한번도 아프지 않고 잘 자라고 있는 드라세나 콤팩타.

완벽한 음지에서 1년 반을 있었고, 방문 사이로 들어오는 오전 햇빛 때문에 살짝 문쪽으로 아주 살짝 휘고 있다 ㅋ 크기와 음지를 감안하고, 젓가락 꼽아서 거의 말랐다 싶으면 물을 듬뿍 줬다. 대충 30일~40일 정도. 화분 길이가 길쭉해서 젓가락이 얼마 안들어가니 얼추 맞는 것 같다. 지금껏 잎 3장 정도가 끝부분이 새까맣게 탄 것들을 발견했는데, 아마도 과습일 때 그런 현상이 나타나지 않나 싶다. (사실 잘 모름.) 1년 반 동안 1도 안 큰줄 알았는데, 사진으로 이렇게 비교해보니 키가 좀 크긴 했네. 잎이 시작되는 부분을 보면 목대가 얇아진게 보이는데, 유튜브에서 보니 저 부분을 야곰야곰 뜯어주면 키가 잘 자란다고... 예전 사진이 훨씬 풍성해 보이긴 하네ㅎㅎ; 이론상으로 보면 그럴 듯 하다. 잎을 잘라내면 그만큼 영양분은 확보될 것이고, 그 영양분이 키와 잎으로 갈 수 있다는 생각이 든다. 하지만 1년 반을 키워보니, 키는 그냥 햇빛과 물이 충분하면 잘 자랄 것 같다. 잎을 잘라내는 것은 그저 디자인의 목적이 더 크지 않을까... 연꽃같은 분위기를 내느냐, 먼지털이(?) 같은 기다란 분위기를 내느냐. 나는 이제는 잎을 잘라내지 않을 예정이다. 공기정화 목적으로 들인 식물들이니 잎이 많은 것이 더 합리적. 유튜브 영상에서는 너무너무 잘 자라서 천장에 닿을 듯 하던데, 그 정도면 너무 피곤할 것 같음. 목대도 이리저리 휘어있어서 보기에도 그닥. 4계절을 잘 지냈으니 앞으로도 별 일 없을 것 같고... 넌 그저 음지에서 조금씩만 건강히 자라거라~~