Cloud Computing On Demand

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만명이 수강한 강의 추천드립니다! ]

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

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

어떤 언어를 사용하던 문자열 포맷팅은 꽤 짜증스러운 부분입니다. 화면에 출력을 하던 파일에 내용을 쓰던 다양한 문자열 포맷팅을 사용해야만 합니다. 문자열 포맷팅이 데이터베이스와 같이 민감한 요소를 액세스 하는데 사용된다면 (가령 쿼리 문장 같은...) 포맷팅 이전에 SQL Injection 과 같은 악의적인 공격도 감안해야 하기 때문에 더 신경을 써야만 합니다. 

자바스크립트를 오랫동안 사용하면서 유레카를 외쳤던 때가 있었습니다. 물론 자바스크립트도 계속 진화하고 있기 때문에 Wow 한 순간들이 여러번 있었지만, 그 중에서도 가장 기억에 남는 것은 ES6 에서 도입된 템플릿 문자열이었습니다. 일반적으로 변수를 선언하거나 문자열을 만드는 과정에 백틱(`)을 이용해 변수나 메서드를 변수에 직접 바인딩 할 수 있게 해주는 방법이었습니다. 

// Javascript ES6 에 도입된 템플릿 문자열
console.log(`Default ENV value is ${process.env.MY_VALUE}`);

파이썬으로 코드를 만들면서도 <당연히> 문자열을 핸들링 해야 하는 상황이 계속 발생했습니다. 디버깅 로그에서부터 사용자 콘솔 화면에 뿌려줄 응답 결과, 데이터베이스 쿼리문에 까지 당연한 일이었습니다. 오래전 방식으로 문자열을 + 로 연결하는 작업을 하다보니  `ES6 에서의 템플릿 문자열 같은게 없을까?`하는 궁금증이 생겼습니다. 네, 이 글을 적고 있으니 당연히 방법을 찾았겠지요?

자바스크립트에서 ES6 이상에서만 템플릿 문자열을 쓸 수 있는 것처럼 파이썬 역시 Python 3.6 이후 버전에서 비슷한 역할을 하는 f-Strings 가 추가되었습니다. f-Strings 라고 이름 붙인 연유는 찾아보지 않았지만 문자열을 묶어주는 따옴표 앞에 f 를 붙여야만 이 기능을 쓸 수 있기 때문에 그냥 그렇게 이름을 지었구나... 참 엔지니어스럽다 라는 생각을 하고 넘어갔습니다. 

# Print 문에서 f-Strings 사용하기
print(f"- Start update : {_domain}/{_property}")

# 문자열에서 f-Strings 사용하기
log += f"- Start update : {_domain}/{_property}\n"

# f-Strings 로 LIST 바인딩하기
log += f"- No metadata found ({result['title']})\n"

 대표적으로 f-Strings 를 사용한 예시들입니다. 문자열이 필요한 모든 곳에 사용할 수 있습니다. 자바스크립트 ES6 에서는 ${} 였다면 파이썬 에서는 {} 입니다. 브레이스 안쪽에는 직접 변수명이 들어가거나 내부 함수, 메서드 등이 모두 활용될 수 있습니다. 이런 형태의 문자열 조립이 좋은 이유는 정확하게 출력되는 결과를 인지할 수 있다는 점이겠지요? 아래와 같은 형태에서는 가독성도 떨어지고 무슨일이 일어날지 짐작하기가 어려우니까요.

print("- Start update : " + _domain + "/" + {_property})
log += "- No metadata found (" + result['title'] + ")\n"

[ 윤작가님의 베스트셀러 파이썬 서적으로 고고씽! ]

JSON 으로 데이터를 표현하는 것은 굉장히 일반화 되어 있습니다. 많은 API 의 응답이 JSON 형태를 가지고 있을 뿐만 아니라 서버의 설정이나 개발된 코드의 환경 정보도 JSON 으로 쓰는 경우가 많습니다. 하지만 JSON 이 정말 편안한 형태인가? 에 대해서는 쉽게 고개를 끄덕이긴 어렵습니다. 파싱(Parsing) 하는 과정이 은근 까다로울때가 많고, 특히 JSON 이 중첩되어 있을 경우에는 더욱 그렇습니다. 

파이썬에서 requests 모듈을 이용하여 JSON 으로 응답하는 API 를 호출하기 위하여 아래와 같이 간단한 코드를 만들었습니다. 응답 결과가 JSON 이기 때문에 응답에 대하여 JSON 으로 쉽게 읽을 수 있겠지? 하는 마음에 json() 메서드를 호출해서 변수에 담았습니다. 

import requests
import json

_target = "https://www.example.com/api"
s = requests.Session()
result = s.get(_target).json()

데이터는 JSON 의 모습이지만 이 자료가 어떤 형태인지는 type 으로 찍어보거나 requests 모듈의 문서를 찾아서 json() 메서드의 자료형을 살펴봐야 합니다. 간단히 코드를 만들어서 확인해보니 문자열 형태가 아닌 Dictionary 형태의 자료였습니다. print 문 등으로 출력을 해보면 마치 JSON 처럼 생긴 결과가 나오지만 JSON 의 규격과 맞지 않아 JSON Validator 를 이용해보면 파싱이 제대로 되지 않습니다.

여기서 또 한가지의 문제는 이 응답 결과를 for 문으로 이용하는 코드를 만들었을 때 생깁니다. Dictionary 형태의 데이터였지만 특정 Key 의 값을 꺼내어 확인해보면 Dictionary 가 아닌 List 형으로 변경된 것을 알 수 있습니다. 자료형이 어떻게 바뀌어 가는지를 제대로 가늠하지 못하고 코드를 만들다 보니 한참을 헤메일 수 밖에 없었습니다. 결과에서 특정한 값이 필요할 때는 Dictionary 가 편하지만 Javascript 등에서 JSON 을 필요로 할 때는 문자열 형태로 전달해서 JSON 으로 파싱할 수 있도록 해주는 것이 좋습니다. 

result = s.get(_target).json()
print(type(result))             # DICT
result_json = json.dumps(result)
print(type(result_json))        # JSON
result_dict_again = json.loads(result_json)
print(type(result_dict_again))  # DICT

json 모듈이 제공하는 json.dumps() 메서드는 자료형을 JSON 형태로 (단순 문자열입니다!) 바꿔주는 역할을 하고, json.loads() 메서드는 문자열 자료를 파싱하여 Dictionary 의 Key, Value 형태로 변경해줍니다. 파이썬 내에서 자료를 핸들링 할때는 Dictionary 를 이용하고 외부로 전달할 때는 JSON 형태로 쉽게 바꿀 수 있게 되었습니다. 오늘도 파이썬 초보는 이렇게 한가지를 또 배워갑니다. 

사놓고 보지 않는 혼공파... 틈틈히 읽어야겠습니다 ㅜㅜ (반성..반성..)

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