개요

1주차 - 테라폼으로 프로비저닝, 다양한 노드 활용해보기에서 다 끝내지 못한 내용까지 포함해서 진행..
테라폼 만진지가 이제 일주일 조금 넘어가려나, 빨리 테고수가 되고 싶다..

스터디

echo "alias k=kubectl" >> ~/.zshrc echo "alias kubectl=kubecolor" >> ~/.zshrc echo "compdef kubecolor=kubectl" >> ~/.zshrc

kubecolor 다운 받자

# Install sshpass
brew install sshpass

# Install Wireshark : 패킷 캡쳐 및 캡쳐된 파일에서 패킷 내용 확인
brew install --cask wireshark

ssm

curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
sudo dpkg -i session-manager-plugin.deb

# 삭제 시
sudo dpkg -r session-manager-plugin

실습 환경 세팅

구성도

이번 환경은 이렇게 구성한다.
기본적으로 eks 클러스터를 둔 다음, 이를 관리하는 온프렘 혹은 다른 vpc 환경이 있다고 가정하고 세팅하는 것이다.
여기에 추가적인 조건은 다음과 같다.

• vpc 구성
  • eks 클러스터 구성 이전에 이뤄진다.
  • 운영 vpc와 eks의 vpc는 vpc peering을 한다.
• 클러스터 세팅
  • 엔드포인트는 혼용 모드로 세팅하나, 기본적으로 모든 통신은 프라이빗으로 이뤄지게 하도록 한다.
  • 실습 편의를 위해 당장은 내 로컬에서도 접근 가능하기 위해 혼용으로 둔다.
    • (ec2 느려서 싫어용)
  • 네트워크 관련 리소스(로드밸런서, external dns 등)를 쓸 수 있도록 먼저 세팅이 돼야 한다.
    • 각종 정책, 롤에 대한 세팅이 돼야 하는데, 아직 이 부분 숙련도가 부족해 엄밀히 하지는 않는다.
• 데이터 플레인
  • 3개의 AZ에 퍼블릭 서브넷 영역에 하나씩 구축한다.
    • 어디까진 프라이빗을 사용하지 않는 건 폭력적인 nat gateway 때문이다..
  • 각 워커 노드는 접속이 가능할 것.
    • ssh, 혹은 Amazon Systems Manager을 통해 접근이 가능해야 한다.
• 운영 호스트
  • 운영 vpc에 위치한 호스트가 주로 실습을 진행할 때 사용하게 될 인스턴스이다.
  • 구축이 완료되면 클러스터 조작이 바로 가능하도록 세팅돼야 한다.
  • 내 로컬에서는 이 인스턴스에 ssh, ssm 연결이 가능해야 한다.
  • 여기에서는 api 서버와의 통신, 그리고 워커 노드로의 ssh 접근이 가능해야 한다.
    스터디에서 제공해주는 클라우드 포메이션, eks.yaml 파일을 보고 이것과 같은 환경이 구성될 수 있도록 하고자 한다.
    그러나 여기에 나는 추가적으로 구성을 하고자 한다.
    운영 vpc에서 클러스터 액세스 엔드포인트에 프라이빗 모드로 접근 가능하게 만드는 것.^[1]
    현재 아키텍쳐에서는 운영 호스트에서 클러스터 조작을 하려면 퍼블릭 엔드포인트를 사용해야 한다.
    (물론 피어링을 했기 때문에 직접 프라이빗 엔드포인트 주소에 대해 hosts 파일을 작성하는 식으로 활용할 수는 있다)

Amazon Route53의 프라이빗 호스팅 존에 운영 vpc를 추가하여 엔드포인트에 대한 dns 질의가 알아서 프라이빗 주소를 나타내도록 할 수 있다면 좋겠지만, 클러스터 주소에 대한 route53은 aws가 관리하고 있으며 관련한 커스텀 기능을 제공하지 않는다.
(내 생각에는 추후에는 제공할 가능성도 있다)

그래서 이런 식으로 추가적인 리소스를 들여, 프라이빗 엔드포인트로 통신을 할 수 있도록 만들어주고자 한다.
이 세팅을 하면서 겪은 트러블슈팅이나 고민지점은 아래 [[#다른 vpc에서 프라이빗 엔드포인트 사용하기]]에 담았다.
다른 vpc에서도 클러스터 엔드포인트 도메인 주소에 대해 eks owned eni의 ip가 나오도록 세팅하는 것이 주골자이다.
이를 위해 다음의 리소스를 세팅한다.

• Private NLB
  • 데이터 플레인의 vpc에 nlb를 만들어 이 nlb가 해당 eni의 ip를 타겟 그룹으로 삼도록 한다.
  • 이 NLB를 private link로 운영 vpc에 엔드포인트를 제공해준다.
• Route53
  • private link를 뚫었기에 해당 링크에 대한 도메인 주소가 새로 생기는데, 이 주소는 정상적으로 사용할 수 없다.
    • api 서버가 해당 도메인에 대한 인증서를 가지고 있지 않기 때문이다.
  • 이를 막기 위해 따로 route53 프라이빗 호스팅 존을 만들고, 해당 엔드포인트 dns를 실제 eks api 서버 도메인으로 덮어씌운다.
    • 이 과정은 alias 기능으로 이뤄지는데, CNAME 레코드와는 다르다.^[2]
• Lambda
  • eks owned eni의 ip는 지속적으로 바뀔 가능성이 존재하기에, nlb의 타겟그룹을 업데이트할 경우가 생길 수 있다.
    • 클러스터 업데이트, 장애 상황 등의 이슈로 ip가 바뀔 수 있다.
  • 그래서 eni가 새로 만들어지는 이벤트를 eventbridge로 포착하고, nlb의 타겟그룹을 업데이트하는 람다 함수를 만든다.
    • 노드가 늘어나거나 vpc cni가 노드에 붙이는 eni 관련 이벤트에 대해서 동작하면 안 된다.
  • 쓸모 없어진 ip를 타겟그룹에서 제거하는 람다 함수도 만든다.

이렇게 아키텍쳐를 만들게 되면 운영 vpc에서 어떻게 클러스터와 통신을 하게 되는가?

• 클러스터 도메인에 대해 route53으로 질의가 날아간다.
• route53은 프라이빗 링크의 주소를 반환한다.
• 이후 트래픽은 링크를 타고 이동하며, nlb를 통해 eks owned eni의 ip로 전달된다.
• 도메인도 정상이라 해피해피 통신 가능!

테라폼 구성

이 구성도를 바탕으로 테라폼을 만들어보자.

vpc 피어링 설정, 인스턴스 배포.
인스턴스보안 그룹 설정
ssm 설정

각 cni 롤 설정

eks yaml 참고

애드온에 추가 폴리시를 부착하는 것이 보인다.

여기에 추가적으로 노드 그룹 iam 필드에는 각종 애드온 관련 정책을 추가하는 것이 확인된다.
이것들을 테라폼에서는 어떻게 세팅할 수 있을까?
애드온 관련 설정을 하는 코드를 찾았다.^[3]
그런데 아직 완벽히 감이 잡히지는 않는다.

조금씩 테라폼이 익숙해지고 있지만, 아직 완벽하지는 않다.
eks 모듈에는 애드온을 넣는 칸이 있는데 자료형이 그냥 any라 나와있다.
그래서 내부 필드를 어떤 식으로 지정할 수 있는지, 직접 모듈 코드를 분석한다.

default = { "aws-load-balancer-controller" = { name = "aws-load-balancer-controller" addon_version = "v1.4.4-eksbuild.1" most_recent = true configuration_values = <<-EOF {"clusterName": "myeks"} EOF preserve = true resolve_conflicts_on_create = "OVERWRITE" resolve_conflicts_on_update = "OVERWRITE" service_account_role_arn = "arn:aws:iam::123456789012:role/AWSLoadBalancerControllerRole" before_compute = false timeouts = { create = "30m" update = "30m" delete = "30m" } tags = { "Environment" = "production" } }, "external-dns" = { name = "external-dns" addon_version = "v1.8.0-eksbuild.1" most_recent = true configuration_values = <<-EOF {"domainFilters": ["example.com"], "txtOwnerId": "myeks"} EOF preserve = true resolve_conflicts_on_create = "OVERWRITE" resolve_conflicts_on_update = "OVERWRITE" service_account_role_arn = null before_compute = false timeouts = { create = "30m" update = "30m" delete = "30m" } tags = { "Environment" = "production" } } }

아직 시행 착오 중이라, 크게 정리하지 않는다.
이건 지피티의 코드이다.
다만 이런 식으로 정리하여 사용할 수는 있을 듯하다.

완전히 감이 잡히지는 않아서 eks 관련 코드를 계속 찾던 찰나, eks 리소스 예제에서 이런 코드를 발견했다.
나는 애드온 별로 롤을 만들어 부여하는 건가 했는데, 기본적으로는 그냥 클러스터 리소스가 가질 수 있는 정책을 선언하고 이를 붙여주는 옵션으로 보인다.
이 코드대로라면, 클러스터의 롤에다가 해당 정책을 붙여주면 되는 것 같다.
하지만 위의 yaml 파일에서는 노드 그룹 롤이 정책을 부여받아야 하는 것 같은데..
보안 주차에 배울 거라지만 그래도 조금은 더 이해하고 넘어가야 할 듯하다.

분명 애드온에 대해서 정책을 지정할 수 있는 공간이 콘솔에서도 확인된다.
애드온마다, 구체적으로는 파드마다 정책을 할당할 수 있다는 것이다.
pod identity, irsa 두 방법이 있는 것이고.

이것도 aws 리소스에서 찾은 건데, 애드온에 대해서 롤 정보를 명시하지 않는다면 노드의 롤을 그대로 받는다고 한다.

eks 모듈에서 추가 폴리시만 넣는 입력값을 찾았다.
자료형이 그냥 map(string)이라 찍혀 있으니 어떻게 넣으라는 건지 구체적으로 알기가 어렵다..
근데 키는 쓰지 않고 값만 arn으로 명시해주면 되는 것이었다;;
테라폼은 분명 좋지만, 이런 부분을 명시적으로 알 수 있는 방법에 대한 개선이 필요할 것 같다.
아니 애초에 모듈로 입문을 하려 했던 내 잘못인 것 같기도 하고..?

eks 자체와 관련된 관리형 정책들의 리스트를 여기에서 확인할 수 있다.^[4]

피어링된 호스트에서 접근할 수 있게 만들기

eks 모듈을 설정할 때, 아예 보안그룹에 추가 세팅을 할 수 있다.
운영 vpc의 보안 그룹이 소스인 경우 전부 허용하도록 만들자.
새삼 느끼는 거지만, 굳이 외부 모듈을 사용할 필요를 잘 모르겠다.
테라폼을 잘 모르던 입장에서 이미 만들어진 것을 쓰면 큰 도움을 받을 수 있을 것이라 생각했는데, 생각보다는 그렇지 않았다.
그냥 템플릿 정도 만드는데에는 유용하나, 커스텀을 하기 위한 편의가 잘 제공되지 않는 것 같다.
이럴 거면 처음부터 일반 aws 리소스로 만들 걸 그랬나 싶기도 하다.

운영 vpc에서만 요청을 보내게 될 테니 클러스터에 다른 vpc의 요청을 수행할 수 있도록 보안 그룹을 뚫어주어야 한다.

그러나 내가 의도한대로 되지는 않은 것이, api 서버로의 엔드포인트에 붙은 보안 그룹에 해당 룰이 추가됐다.
나는 보안그룹을 뚫어서 클러스터 노드에 ssh까지 가능하게 하고 싶기에, 전체 클러스터 보안그룹에 해당 룰이 추가되도록 해야 한다.
콘솔로 직접 일단 보안그룹을 추가해주려고 했는데.. 가시적으로 피어링된 vpc가 보이지 않아서 애먹었다..^[5]
처음에는 내가 설정을 잘못한 줄 알았다.

eks 모듈에서 만질 수 있는 보안 그룹은 secondary 보안 그룹이고, 기본 보안 그룹은 eks에서 만들어진다.^[6]
이 보안 그룹을 커스텀할 수 있도록 output으로 제공은 해주는 게 보인다.

ami 찾기..

오퍼레이터용 호스트를 적절한 걸 쓰기가 참 어렵다.
ami 카탈로그에서 찾은 것을 넣은 건데 이렇게 나온다.

는 보니까 ami id가 리전마다 또 다르다..
내가 보던 리전은 오하이오여서 해당 id를 찾지 못했던 것으로 보인다.
내가 평소에 영어 콘솔로 해둬서 그런가, 왜 항상 다른 리전으로 옮겨져 있는 걸까..

다른 vpc에서 프라이빗 엔드포인트 사용하기

사실 실습 환경 세팅 자체는 금방 끝났다.
위에서 추가적인 세팅을 한 계기
그런데 테스트를 해보니 운영 호스트에서 엔드포인트를 퍼블릭으로 받는 것이 굉장히 눈에 거슬렸다..
실무적 환경을 가정한다고 했는데 이렇게 허술하게 퍼블릭 환경을 통한 통신을 하는 게 아쉽다고 생각하던 차에 관련한 자료를 찾을 수 있었고, 이걸 활용해서 추가적인 세팅을 곁들이기로 결정했다.^[7]

처음에는 이거 보고 직접 전부 세팅해보려고 했으나, 아직은 배우는 단계라 잘 만들어진 코드를 내 것에 맞게 살짝 커스텀하면서 이해를 하는 것도 큰 도움이 되겠다 판단했다.
그래서 최대한 예제 코드를 가져와서 이해하며 나아가는 방향으로 실습을 해보겠다.
지금은 잠시 이해하면서 바로 이해가 가지 않는 것들에 대해 중간 정리만 한다.

dns_entry 필드는 vpc 엔드포인트에 대한 dns 값을 나타내며, interface endpoint에 대해서만 생성된다.
하위 필드로 dns_name, hosted_zone_id를 가진다.
왜냐? interface endpoint는 eni가 하나 붙으면서 해당 private ip에 대한 도메인이 하나 만들어지기 때문에 관련한 추가 정보가 생기게 되는 것이다.

AWS Cloudtrail의 내용을 보고 Amazon EventBridge가 발동되는 것이 확인된다.
그런데, 내가 아무런 설정을 하지 않았는데도 관련 로그가 남도록 기본값이 설정돼있는 것인가?
콘솔에서 obverability 부분에 api 서버 감사 로그가 남는 것은 확인했는데, 이런 것도 미리 세팅되는 거라면 비용이 상당하게 나갈 것 같다.

terraform init -reconfigure
terraform apply -target=module.nlb -target=module.eventbridge --auto-approve
terraform apply -target=module.eks_vpc -target=module.operator_vpc --auto-approve
terraform apply --auto-approve

이제부터는 명시적으로 먼저 만들어야 하는 모듈이 존재한다.
eks 모듈을 만들 때 보안 그룹 규칙을 추가해야 하는데, 룰은 먼저 만들어진 로드밸런서의 값을 받아야 하기 때문이다.
내 생각에는 depends_on을 사용할 수도 있을 것 같은데, 아직 확신이 없으므로 시도하지 않는다.
그리고 depends_on을 사용해도 plan 단계에서 발생하는 에러는 해결할 수 없을 것 같다.

이벤트 브릿지가 잘 만들어졌다.

람다 역시 잘 형성된 것이 보인다.
람다는 타겟으로 명시하지 않았으나, 타겟의 의존성에 의해 같이 프로비저닝이 진행된 것.

이벤트 브릿지 쪽에서 어떤 타겟이 트리거되는지도 잘 나오고 있다.

순서대로 적용했다고 생각했는데, 리소스가 만들어지는 순서에서 문제가 발생한 듯하다.
vpc_enpoint가 허용되려면 nlb의 타겟그룹이 먼저 만들어져서 헬스체크가 돼야 하고, 그러려면 eks가 먼저 만들어지면서 eni를 만들어 람다를 발동시켜야 한다.
이 부분에 대해서는 module.eks를 depends_on하도록 하여 순서를 강제했다.

이 이벤트에 대해서 eventbridge가 발동하면 성공이다.

흠.. 이벤트 브릿지에 대해 모니터링 설정을 하지 않아서 그런가 그쪽 콘솔에서는 제대로 보이지 않고, 다만 cloudtrail에서 확인해본다.

콘솔에서 엔드포인트가 잘 만들어진 것이 확인된다.

dig 820333056541505C5D8481F049F33EBD.sk1.ap-northeast-2.eks.amazonaws.com +short
172.20.0.196

dns도 실제로 잘 이루어지고 있다.

내 예상과는 다르게, 타겟 그룹에는 아무 값도 없다..

일단 수동으로 값을 넣어서 확인해보자.

그러자 통신이 원활하게 이뤄지는 것이 확인된다.
람다 발동이 제대로 안 된 것 같은데, 왜 그랬을까?
이벤트 브릿지 부분에서 문제가 발생했을 가능성을 보고 있다.
내가 참고한 자료는 제작년 자료이고, 막상 내가 직접 클라우드 트레일을 봤을 때는 이벤트의 모양새가 조금씩 다른 것처럼 보였다.

람다 친구 관련한 이벤트를 자세히 보니, 접근이 거부됐다는 로그였다.

User: arn:aws:sts::134555352826:assumed-role/terraform-eks-add-eni-ips/terraform-eks-add-eni-ips is not authorized to perform: kms:RetireGrant on resource: arn:aws:kms:ap-northeast-2:134555352826:key/f1c9ad43-39fe-4861-aa0b-ea7b484eee62 because no identity-based policy allows the kms:RetireGrant actio

이게 뭘까. 아직은 잘 모르겠다.

15분마다 실행이 잘 되고 있는 delete쪽 람다는 로그가 분명하게 잘 남고 있다.
이 친구도 분명 RetireGrant 관련 이벤트가 발생했는데 말이지..
무엇보다 이 친구는 확실하게 이벤트브릿지가 발동하는 것이 모니터링으로 확인되는데, create쪽 브릿지는 한번도 발동되지 않는 모양이다.
그렇다면 이벤트 트리거 조건에 문제가 있다고 생각해야 할 것 같다.

{
  "detail": {
    "eventName": ["CreateNetworkInterface"],
    "eventSource": ["ec2.amazonaws.com"],
    "responseElements": {
      "networkInterface": {
        "description": ["Amazon EKS terraform-eks"]
      }
    },
    "sourceIPAddress": ["eks.amazonaws.com"]
  },
  "detail-type": ["AWS API Call via CloudTrail"],
  "source": ["aws.ec2"]
}

cloudtrail에서 detail 필드는 명확하게 일치하는 것을 확인했으나, top-level 필드에 대해서는 확신이 없다.
그래서 이 부분을 지우고 다시금 도전해보려고 한다.

별개로 조금 더 알게 된 것 중 하나인데, 클러스터가 만들어지는 과정에서 인터페이스가 만들어지는 타이밍에 간격이 존재한다.
pritvate link 자체가 만들어지는데 상당한 시간이 걸리던데 그것때문일까?

이번에도 발동이 제대로 되지 않은 관계로, 직접 이벤트 브릿지를 만들어보며 문제점을 파악해보자.
룰을 만들 때 샘플 이벤트에 api call via cloudtrail을 통해 기본적인 스키마를 얻을 수 있었다.
여기에 detail부분에 실제 이벤트 내용을 넣어주면 되는 것이다.

이렇게 하면 분명히 매칭이 된다고 나오는데..

혹시 이벤트 버스의 문제는 아닐까 해서 봤는데, 가능성이 있어 보인다.
default라서 무조건 cloudtraili의 이벤트가 들어올 거라 생각했던 게 오산이었나.
조언을 구해보니 mutating event만 브릿지가 트리거한다고 한다.
그리고 더 알아보니 이것은 readOnly 필드가 false인 것들을 말하는 건데, 그럼 현재 이벤트는 잡혔어야 했다.
eks가 만들어지는 시점에 콘솔로 트레일을 보기가 힘든데, 이때 과도한 트래픽이 발생하여 이벤트 버스로 제대로 이벤트가 가지 않을 가능성도 있을까?

{
  "version": "0",
  "id": "ea9b6332-7572-7563-c1a0-76ae374cb2c5",
  "detail-type": "AWS API Call via CloudTrail",
  "source": "ec2.amazonaws.com",
  "account": "134555352826",
  "time": "2025-02-12T01:56:58Z",
  "region": "ap-northeast-2",
  "resources": [],
  "detail": {
    "eventVersion": "1.10",
    "userIdentity": {
      "type": "AssumedRole",
      "principalId": "AROAR6VA7X35AJ53LX5GL:AmazonEKS",
      "arn": "arn:aws:sts::134555352826:assumed-role/AWSServiceRoleForAmazonEKS/AmazonEKS",
      "accountId": "134555352826",
      "sessionContext": {
        "sessionIssuer": {
          "type": "Role",
          "principalId": "AROAR6VA7X35AJ53LX5GL",
          "arn": "arn:aws:iam::134555352826:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
          "accountId": "134555352826",
          "userName": "AWSServiceRoleForAmazonEKS"
        },
        "attributes": {
          "creationDate": "2025-02-12T01:35:05Z",
          "mfaAuthenticated": "false"
        }
      },
      "invokedBy": "eks.amazonaws.com"
    },
    "eventTime": "2025-02-12T01:35:05Z",
    "eventSource": "ec2.amazonaws.com",
    "eventName": "CreateNetworkInterface",
    "awsRegion": "ap-northeast-2",
    "sourceIPAddress": "eks.amazonaws.com",
    "userAgent": "eks.amazonaws.com",
    "requestParameters": {
      "subnetId": "subnet-0c3b4a2f89f5ee62b",
      "description": "Amazon EKS terraform-eks",
      "groupSet": {
        "items": [{
          "groupId": "sg-03abd7f83d230427d"
        }, {
          "groupId": "sg-05d425dc6525559af"
        }]
      },
      "privateIpAddressesSet": {},
      "ipv6AddressCount": 0,
      "clientToken": "4c5a00dd-da92-42bb-86bc-ae8a80faebf8"
    },
    "responseElements": {
      "requestId": "4780920a-d468-4c14-b881-28787ef4838c",
      "networkInterface": {
        "networkInterfaceId": "eni-01b52aff360fbf57f",
        "subnetId": "subnet-0c3b4a2f89f5ee62b",
        "vpcId": "vpc-035fb2aa3fa4eecb1",
        "availabilityZone": "ap-northeast-2c",
        "description": "Amazon EKS terraform-eks",
        "ownerId": "134555352826",
        "requesterId": "143882698129",
        "requesterManaged": true,
        "operator": {
          "managed": false
        },
        "status": "pending",
        "macAddress": "0a:d4:1e:97:cf:3f",
        "privateIpAddress": "192.168.2.157",
        "privateDnsName": "ip-192-168-2-157.ap-northeast-2.compute.internal",
        "sourceDestCheck": true,
        "interfaceType": "interface",
        "groupSet": {
          "items": [{
            "groupId": "sg-03abd7f83d230427d",
            "groupName": "terraform-eks-cluster-20250212013053188300000003"
          }, {
            "groupId": "sg-05d425dc6525559af",
            "groupName": "eks-cluster-sg-terraform-eks-2098807316"
          }]
        },
        "privateIpAddressesSet": {
          "item": [{
            "privateIpAddress": "192.168.2.157",
            "privateDnsName": "ip-192-168-2-157.ap-northeast-2.compute.internal",
            "primary": true
          }]
        },
        "ipv6AddressesSet": {},
        "tagSet": {}
      }
    },
    "requestID": "4780920a-d468-4c14-b881-28787ef4838c",
    "eventID": "56ad0cd1-f729-452e-8139-3e121bd98dc7",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "134555352826",
    "eventCategory": "Management"
  }
}

아예 해당 이벤트를 직접 내가 이벤트 버스에 쏴보자.

이벤트 버스를 보니 직접 이벤트를 보내보는 기능도 있어서 이를 활용하는 것이다.

그래서 이벤트를 직접 적어서 보내봤는데 이러니까 제대로 람다가 발동하여 ip가 등록되는 것이 확인됐다.
이렇게 보냈더니 람다에서 분명하게 기록이 남는다.
조금 시간이 지나 확인해보니 이벤트 브릿지 룰에도 호출된 기록이 남았다.
내가 직접 이렇게 이벤트를 보냈는데 람다가 발동한 걸 보면, 최소한 확실한 것은 현재 eks에서 eni를 만드는 이벤트가 제대로 event bus로 이동되지 않는다는 것이다.

이벤트 브릿지로 전송되는 이벤트들에 대한 정보가 담긴 문서를 찾았다.^[8]
네트워크 인터페이스가 붙는 이벤트의 소스는 ec2인 것을 확인했으니, 이쪽을 봐야 할 것 같다.^[9]
여기에는 최소한 서비스 이벤트로 만들어지는 네트워크 인터페이스 관련 정보는 존재하지 않는다.

지피티 왈, eks 같이 aws에서 내부적으로 동작하는 일부 이벤트는 클라우드 트레일에 표기를 하더라도 실제로 이벤트 브릿지로 전송하지 않을 수도 있다고 한다.
그래서 이를 보완하려면 내 클라우드 트레일 자체를 추적하고 여기에서 람다로 이벤트 브릿지를 작동시키는 파이프라인을 만들라고 한다..
음.. 뭐 못할 건 뭐냐.

        "detail" : {
          "eventName" : ["CreateNetworkInterface"],
        }

를 하기 전에 최후의 방법으로, 일단 eni 만드는 옵션이면 다 받아버리기!
이렇게 하면 VPC CNI가 동작하여 만들어지는 이벤트도 전부다 받게 되긴 하겠지만.. 그 놈들을 받고 컨트롤 플레인 eni 이벤트를 못 받는 것을 확인할 수 있다면 그것만으로도 수확이라 생각했다.
그러나.. 이렇게 바꿔도 이벤트를 제대로 받지 못한다.
gpt의 말이 정말 맞는 걸까?
오히려 현재의 결과는 내게 있어서는 다른 가능성을 생각하게 만든다.
처음에는 eks에서 일어나는 이벤트가 실행 주체가 내게 종속되지 않기에 제대로 버스로 전달되지 않을 수도 있겠다 생각했다.
그러나, 최소한 vpc cni가 네트워크 인터페이스를 추가하는 이벤트는 내 노드에서 발생하는 과정이므로 명확하게 잡혔어야 하는 것이 아닌가?
내가 아직 제대로 이해하지 못한 이유로 이벤트가 버스로 전달되지 않는 것 같다.

어차피 vpc에 private link로 api 서버의 엔드포인트가 전달돼 priavte access가 가능한 거라면, 해당 private link를 다른 vpc에는 뚫을 수 없는가?^[10]
마침 private link를 지원하는 업데이트가 2022년에 있기는 했다.^[11]
조금 더 읽어보니, 이건 eks api에 대한 경로를 뚫어주는 거고 api 서버에 대한 지원이 아니다.

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-log-api-call.html
이벤트 브릿지에서 자동으로 보내는 게 아닌가..?
여태 지피티 농간에 또 놀아난 거야..?

단서를 찾은 것 같기도 하다.
그냥 내 임의의 트레일을 하나 만들어봤다.
그랬더니 뒤늦게 이벤트 버스가 요청을 받고 있는 것으로 보인다.

다른 단서도 하나 더 나왔다.
이벤트브릿지 룰을 만들 때 이벤트 타입들을 보면 cloudtrail에서 오는 api 호출에 대한 이벤트들이 각 리소스의 항목에 들어가있다.
물론 여태 내가 뻘짓한 것은 아니라는 듯이 eks, ec2에 대한 것은 없다.
아무튼, api call을 명시적으로 가져올 수 있는 리소스가 한정돼있을 가능성도 있는가.

오레곤에서 만들어본 예제가 동작했다.
어째서?
이게 두번째로 만들어보는 것인데, 처음에는 아무런 동작을 하지 않아서 나는 예제가 잘못된 것이 확실하다고 결론을 내렸었다.
그런데 이번에는 되는 것이다.

실제로 동작도 제대로 되고 있다.

이번에 테스트를 하기 위해 내가 미리 세팅한 것들을 정리해보자.

• 임의의 클라우드 트레일을 하나 만듬
  • 결국 s3를 하나 만들어야했다.
  • 클라우드 워치 로그도 활성화함
• 임의의 람다 하나 만듬
  • source가 aws.cloudtrail1일 때 동작하게 했다.
  • 이 친구는 초반에만 동작하고 이후로 동작하지 않았다.

이벤트 소스는 other로 세팅돼있다.

여태까지 나는 클라우드 트레일을 만드는 작업을 하지 않았다.
event history로 기본적인 이벤트들이 남는 것을 확인했으며, 이것들을 저장하지 않더라도 이벤트 버스를 호출하는데에는 이슈가 없다고 알고 있었기 때문이다.
몇 가지 가능성을 생각해보자.

• 트레일을 만들었기 때문에?
  • 가능성이 있다고 본다.
• 클라우드 트레일에 워치 로그를 활성화해서?
  • 클라우드 워치는 이미 만들어진 s3에 저장된 데이터를 쉽게 모니터링할 수 있도록 도와주는 도구라고 알고 있다.
  • 직접 s3에 들어가 트레일의 데이터를 보면 압축이 돼있고, kms로 인한 암호화로 직접 보기 힘드니까.
  • 이걸 활성화했다고 이벤트가 날아갔다는 것은 잘 납득이 되지 않는다.
• 기본 람다를 만들어서?
  • 말이 되니?

클라우드 트레일을 만들었기 때문에라고 보는 게 가장 합당하다고 보고, 다시금 내 리전으로 돌아와서 테스트를 해보려고 한다.
그렇다면 클라우드 트레일 자체만 만들면 해결될 가능성이 있다.
테라폼으로 만드려면 조금 어려울 순 있다.
s3에 로그를 저장하기 위한 세팅을 해야 하기 때문이다.

무구한 세월이 지나 드디어 성공입니다.
내 싸제 클라우드 트레일을 하나 만들어야 하는 거였다..

resource "aws_cloudtrail" "cloudtrail" {
  name = "eks_eni_trail"
  s3_bucket_name = aws_s3_bucket.cloudtrail.id

  include_global_service_events = true
  is_multi_region_trail = true
  enable_logging = true

  advanced_event_selector {
    name = "eni_creation_selector"
    field_selector {
      field = "eventCategory"
      equals = ["Management"]
    }
    field_selector {
      field = "readOnly"
      equals = ["false"]
    }
  }
  depends_on = [
    # aws_s3_bucket.cloudtrail,
    aws_s3_bucket_policy.cloudtrail
  ]
}

테라폼을 클라우드 트레일을 만드는 게 생각보다는 까다로웠는데, 계속 버켓 정책에 이슈가 있다고 하더라.
나는 내가 정책을 잘못 적은 줄 알았는데, 클라우드트레일이 버켓 정책 이후에 만들어지게 해야 하는 이슈였다.
당연히 s3를 만들면 같이 버켓 정책도 같이 만들어질 것이라 생각했던 착각이 또 시간을 소모하게 만들었다.

해보고 싶은 것.
vpc lattice, gateway api
external dns 정리
cillium 설치 후 속도 비교
다시금 loxilb..
loadbalancer traffic policy

관련 문서

참고