Cloud Computing On Demand

여기까지 잘 따라오셨나요? Subscription filter도 설정했으니 이제 끝이야!! 라고 하기에는 아직 할 일이 조금 남아 있습니다. 필요한 준비는 대충 되었지만 실제로 Elasticsearch에 접근하기 위한 계정 매핑 작업이 남아 있습니다. 사실 어떤 계정으로 ES Cluster가 제공하는 Kibana를 쓸 것이냐는 선택이 폭이 무척 넓고 구현 방법도 다양합니다.

특히 보안관점에서 탄탄해지려면 이 포스팅 시리즈의 내용만으로는 부족합니다. 다만 우리의 목적은 빠르게 로그를 적재해 보는 것이기 때문에 앞선 포스팅들에서도 간단하게 IP를 통해 접근을 제어하고 별도로 만든 특정 Master Account로 로그인하도록 했었습니다.

여기에 더하여 AWS가 ES Cluster에 데이터를 적재할 수 있도록 하기 위해서 Lambda를 위해 생성한 IAM Role을 ES Cluster의 권한에 매핑하도록 하겠습니다.

IAM Role을 Kibana에 매핑하기

먼저 Kibana에 생성했던 Master Account로 로그인을 합니다. 좌측 메뉴의 `Open Distro for Elasticsearch > Security` 메뉴에 진입하면 7개의 서브 메뉴가 나옵니다. 그 중 `Roles`를 선택하고 쓰기 권한이 있는 특정한 Role을 찾거나 만들도록 하겠습니다.

간단한 시험을 위해 여기서는 `all_access` Role을 사용하도록 하겠습니다. 네, 보안적으로 좋은 프랙티스는 아닙니다!

ES Cluster의 all_access Role에 Lambda에 부여한 AWS IAM Role의 ARN을 매핑해 줘야 합니다. 잠시 AWS의 IAM 관리 화면으로 넘어가서 Role화면으로 이동하겠습니다.

ES Cluster의 Role인지 IAM의 Role인지 헷갈리지 않도록 유의하시기 바랍니다! IAM 관리 화면에서 앞서 생성한 Lambda용 Role을 찾아 해당 Role의 ARN을 복사하겠습니다.

복사한 ARN을 ES Cluster의 Kibana 화면에서 선택한 쓰기 권한이 있는 Role에 추가해 줍니다. Mapped Users 탭의 Manage mapping 버튼을 누르고 Backend Roles 에 ARN을 추가한다음 Map 버튼을 누릅니다. 에러가 발생하지 않았다면 문제가 없는 것입니다.

이제 거의 끝났습니다. 쓰기 권한이 있는 ES Cluster Role에 IAM Lambda Role이 연결되었기 때문에 로그가 클러스터에 적재되기 시작했을 겁니다. 만약 이렇게 했는데도 로그가 쌓이지 않는다면 권한 부여하는 과정에 잘못된 ARN을 복사해 왔을 가능성이 있습니다. 차근히 화면을 보면서 다시 설정하시면 문제 없을 것이라 생각합니다.

이제 `Index Management`로 이동하여 로그가 들어오는지 확인해 보겠습니다. CloudWatch Logs에서 보내는 로그의 기본 인덱스명은 cwl로 시작합니다. 아래와 같이 cwl로 시작하는 로그들이 들어오는게 보이는지 확인하겠습니다.

이제 좌측 메뉴의 `Kibana` 섹션에서 Discover 메뉴를 선택하고 인덱스 패턴을 만들어 보겠습니다. 여기부터는 ES 혹은 Kibana의 영역이기 때문에 더 자세한 설명은 생략하도록 하겠습니다. 인덱스 패턴까지 만들고 저장했다면 이제 로그를 쿼리할 수 있게 됩니다.

 

 

생성한 인덱스에 우리가 앞서 Subcription filter 생성시 지정했던 것처럼 Field 이름들이 잘 들어오고 있는지도 확인할 수 있습니다. 대략 보니 크게 문제 없어 보입니다. 눈치 채셨겠지만 filter 설정시 사용한 컬럼 이름들이 Kibana의 Field로 사용되기 때문에 적절한 키워드를 사용해 주시면 되겠습니다.

Kibana의 Discover 화면에서 최근 15분간의 데이터를 조회해 봤습니다. 네~ 무척 잘 들어오고 있습니다. 모자이크 처리를 해두긴 했지만 지정한 컬럼별로 데이터가 잘 꽂히고 있는 것을 확인할 수 있었습니다.

아직 실트래픽이 실리고 있지 않아 쿼리 규모가 아주 작습니다만 실제 사용자 트래픽을 수용할 때는 적절히 클러스터의 규모를 조정해 줄 필요가 있습니다.

 

Elasticsearch 에 데이터가 적재되지 않을때 트러블 슈팅

 

이렇게 고생해서 셋업을 했는데 ES 클러스터에 데이터가 적재되지 않는 경우 무척 난감하실겁니다. 리소스들을 다시 정리하는 것도 일이고... 어디서 잘못된 것인지 찾는것도 스트레스입니다.

대부분의 경우 AWS CloudWatch Logs 기술 문서와 ElasticSearch 기술 문서에 내용이 나와 있긴 하지만 그래도 잘 안되는 경우 아래의 문서를 참고하실 수 있습니다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/es-troubleshoot-cloudwatch-logs/

 

Amazon ES로 스트리밍할 CloudWatch Logs 문제 해결

기본적으로 Amazon CloudWatch는 각 Amazon ES 도메인마다 하나의 AWS Lambda 함수만 생성합니다. 여러 로그 그룹을 설정하여 하나의 Amazon ES 도메인으로 데이터를 인덱싱하는 경우, 여러 로그 그룹이 모두

aws.amazon.com

 

---

지금까지 4개의 포스팅을 통해 Route53의 DNS 쿼리 로그를 CloudWatch Logs와 Elasticsearch를 활용하여 적재하고 분석하는 환경을 만들어 봤습니다.

DNS 쿼리는 상용 서비스 단계에서 무척 많은 로그를 남기게 됩니다. 때문에 많은 기업들이 on-premise에서 활용하는 서비스용 Authoritative NS에 대해서는 평상시에 로그를 특별히 남기지 않는 경우도 많습니다.

AWS를 통해 Route53을 쓰는 것은 일종의 Managed DNS 또는 Managed GSLB를 쓰는 것ㅇ기 때문에 서버의 로그를 바로 획득하기 어렵습니다.

하지만 (돈을 조금 낸다면.. 속닥속닥..) 로그를 쉽게 적재하고 분석할 수 있는 방법이 제공되고 있으니 필요할 때 유용히 활용할 수 있으면 좋겠습니다. 시리즈 글은 아래의 링크들을 참고하시기 바랍니다!

 

[NEW] Ultimate AWS Certified Cloud Practitioner - 2021

Pass the Amazon Web Services Certified Cloud Practitioner CLF-C01 exam, Practice Exams included with explanations!

www.udemy.com

 

 

(#1/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라 단가가 매겨지고 (=TTL조정으로 어느정도 비용 통제도 할..

ondemand.tistory.com

 

(#2/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 체계 만들기 #1/4 AWS Route53은 Authoritative DNS로도 사용될 수 있고 Dynamic DNS 혹은 GSLB(Global Server Load Balancer)로도 사용될 수 있습니다. 쿼리 수량에 따라..

ondemand.tistory.com

 

(#3/4) AWS Route53 DNS 요청 실시간 모니터링 체계 만들기

AWS Route53 DNS 요청 실시간 모니터링 시스템 만들기의 세번째 포스팅입니다. 네번째까지 구성되어 있는 컨텐츠이지만 내용들은 짧막 짧막하니 아는 부분은 팍팍~ 넘어가시고 막히는 부분들을 확

ondemand.tistory.com

 

본 블로그의 글들은 제휴 마케팅을 통해 소정의 수수료를 지급받을 수 있습니다.

AWS 를 사용하면서 만나는 Global 서비스들이 여럿 있습니다. CDN 제품인 CloudFront 가 가장 대표적인 Global 서비스이고 CF 에서 사용할 수 있는 WAF (Web Application Firewall) 역시 Global 서비스 입니다. 이런 제품들의 특징은 사용자에게 가까운 곳에서 동작해야 효과가 좋다(?)는 점이죠.

최근 WAF 는 Version 2 를 출시하면서 기존의 WAF 는 WAF Classic 으로 부르기 시작했습니다. 몇 가지 변화들이 있지만 그 이야기를 하려는 것은 아니구요, 새로운 버전이 출시되면서 IAM Policy 에도 WAF v2 에 대응하는 부분이 추가되었고 Console 접근을 하려다 보니 생겼던 에피소드를 IAM Policy 를 살펴보면서 간단히 이야기 해볼까 합니다. 

---

IAM 에서 미리 정의하여 제공되는 Policy 중 WAF 와 관련된 것은 두가지가 있습니다. 하나는 AWSWAFFullAccess 이고 다른 하나는 AWSWAFConsoleFullAccess 입니다. 이들 Policy 를 사용하여 권한을 부여해 두었다면 Action 항목에 "wafv2:*" 가 자동으로 추가, 적용이 되었고 WAFv2 의 사용에 문제가 없어야 합니다. 개별 정책을 JSON 으로 정의했다면 명시적으로 "wafv2" 를 넣어줘야 합니다. 

# Policy : AWSWAFFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "waf:*",
        "waf-regional:*",
        "wafv2:*",
        "elasticloadbalancing:SetWebACL",
        "apigateway:SetWebACL"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

문제는 기존 WAF Classic 은 화면 진입은 잘 되면서 에러 메세지가 눈에 안 띄는 곳에 나오면서 콘솔 진입시 위 정책이 충분치 않다는 것을 인지하기가 조금 어려웠습니다. 그런데 WAF v2 에서는 Unauthorized 메세지가 대박 크게 나오면서 마치 wafv2 정책이 제대로 들어가지 않은 것처럼 보이는 제보가 들어왔던 것이지요. 결론을 먼저 말하면 위 정책으로는 WAF Classic 이든 WAFv2 든 제대로 동작하지 않는게 정상입니다. 

# Policy : AWSWAFConsoleFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "apigateway:GET",
        "apigateway:SetWebACL",
        "cloudfront:ListDistributions",
        "cloudfront:ListDistributionsByWebACLId",
        "cloudfront:UpdateDistribution",
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:DescribeRegions",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:SetWebACL",
        "waf-regional:*",
        "waf:*",
        "wafv2:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

AWSWAFConsoleFullAccess 정책을 살펴보면 AWSWAFFullAccess 에 있는 정책들이 모두 들어가 있습니다. 추가로 WAF 적용의 주된 대상이 되는 API Gateway, CloudFront, ELB 관련한 항목들이 추가된 것이 보이는데요, 이들 정책이 있어야 AWS Console 화면 구성에 필요한 정보들을 가져올 수 있고 화면 접근시 Authorization 에러가 발생하지 않게 되는 것으로 생각됩니다. 한참을 헤메다 요 정책을 그룹에 추가해 주고나서 문제를 해소할 수 있었습니다. 

---

AWS 를 쓰다보면 IAM 에서 적절하고 충분한 권한을 주는 문제에 종종 부딪히게 됩니다. 적용된 정책을 확인하는 페이지도 제공하고 있긴 하지만 실제로 사용자들이 API 호출이나 Console 액세스시에 겪게 되는 문제와 연결고리를 찾기 힘든 경우도 종종 생깁니다. 결국은 경험치가 있어야 하는 것인가 하는 고민에 빠지게 되는 5월의 어느날입니다. 

 

[ AWS 자격증을 준비하신다면 - 3만명이 수강한 강의 추천드립니다! ]

 

Ultimate AWS Certified Solutions Architect Associate (SAA)

Pass the AWS Certified Solutions Architect Certification SAA-C02. Complete AWS Certified Solutions Architect Associate!

www.udemy.com

[ WAF Classic 과 WAF v2 의 비교는 아래 블로그가 깔끔합니다! ]

 

 

AWS WAF Version 2 소개(개선 사항)

오늘은 새롭게 출시된 AWS WAF Version 2 에서 제공하는 새로운 기능들과 기존 AWS WAF(Classic) 대비 개선된 사항들에 대해 살펴보도록 하겠습니다.

medium.com

 

본 포스팅은 소정의 수수료를 받을 수 있습니다.

마이크로소프트는 오래전부터 빵빵한 개발자 지원 프로그램과 튼실한 개발자 리소스 제공을 통해 개발 커뮤니티와 개발자들이 쉽게 플랫폼에 진입할 수 있는 길을 만들어 두었습니다. 애져(Azure) 역시 마찬가지입니다. 애져를 위한 여러가지 문서들이 준비가 되어 있고 MSDN (Microsoft Developer Network) 에도 늘 그렇듯 많은 자료들이 있습니다. 

그런데 MSDN 등의 자료도 참 좋지만 처음 접하는 플랫폼에 익숙해 지는데는 짧은 비디오 클립 같은 것이 훨씬 좋습니다. 애져는 공식 웹사이트에서 여러가지 비디오 클립을 제공하고 있어 애져에 익숙해지고 싶은 사람들에게 많은 도움이 되고 있습니다. 그 중, 처음 보기에 딱 좋은 동영상 시리즈가 애져 프라이데이(Azure Friday) 동영상 들입니다

 
이 곳에 등록된 동영상들은 전반적으로 5~10분 정도의 짧은 길이를 가지고 있습니다. 영어로 진행되지만 자막까지 제공되기 때문에 영어가 조금 어려운 분들도 쉽게 이해할 수 있습니다. 대부분의 동영상들이 핸즈온(Hand-On) 형태로 제공되기 때문에 화면만 유심히 잘 봐두었다가 애져 웹 사이트, 애져 포털에서 따라하시기도 어렵지 않습니다. 

애져를 이용한 서비스 인프라 구성을 준비하시는 분들이나 애져를 공부하는 분들이라면 바로 애져 프라이데이 동영상으로 애져의 세계에 뛰어들어 보세요. 뭐든지 생각났을 때 바로 실천하는게 중요합니다. 하루정도 날잡고 전체를 다 훑어 보시는 것도 나쁘지 않을 것 같네요. - NoPD -