Forem: Pakawat (Tle) Teerawattanasuk

การมอบอำนาจการจัดการ SubDomain ไปยัง Hostzone ใหม่ข้าม Account ผ่าน Route53

Pakawat (Tle) Teerawattanasuk — Mon, 28 Mar 2022 08:24:56 +0000

Public Domain Name ถือเป็นส่วนหนึ่งของ Brand Identify ที่สำคัญมาก ในการทำ Website หรือ Application ต่าง ๆ ซึ่งมีผลต่อการที่จะทำให้ผู้ใช้งานรับทราบได้ว่า Website นั้น ๆ เป็นของทีมของเราหรือไม่ รวมถึงเป็นหนึ่งในจุดตรวจสอบว่า Link ที่กดเป็น Phishing หรือไม่

สำหรับทีมที่มีขนาดใหญ่ขึ้น มีระบบต่าง ๆ เพิ่มขึ้นมา จำเป็นต้องใช้ public domain name แยกย่อยออกไปจำนวนมาก ไม่ว่าจะเป็นของผลิตภัณฑ์หรือของทีมต่าง ๆ ภายในการจะจัดการ DNS ที่จุดเดียว อาจจะต้องมีขั้นตอนการขออนุญาตหรือรอเพื่อให้ฝ่ายที่ดูแลเป็นคนจัดการให้ เพื่อความปลอดภัยหรือความเหมาะสมของการใช้งานชื่อที่เป็น identity ขององค์กร ซึ่งส่งผลให้การคิดหรือทำสิ่งใหม่ ๆ ทำได้ยากขึ้นไปด้วย ดังนั้นบทความนี้จะเสนอทางเลือกง่าย ๆ ของการจัดการ Domain Name ภายในองค์กร

หมายเหตุ การจัดการ Domain ที่กล่าวถึงในทบความนี้จะยกเว้นเรื่องของ Policy ของแต่ละองค์กร โดยคำนึงถึงเรื่องความสะดวกในการพัฒนาเป็นหลัก

เมื่อองค์กรมีขนาดใหญ่ขึ้น มีการแยกทีมย่อยออกไป สำหรับองค์กรที่ใช้ AWS มักจะมีการสร้าง Organization และสร้าง Account แยกจากกันออกไปตามทีมต่าง ๆ ซึ่งในสถานการณ์ที่มีองค์กรมี public domain เดียว การที่จะจัดการโดยส่วนมากจะมีวิธีดังต่อไปนี้

Domain อยู่ภายใต้การควบคุมของ Account หลักที่เดียว ซึ่งการจัดการจะมีรูปแบบที่นิยมกันดังนี้
- มีคนหรือทีมที่จัดการดูแล DNS แยกออกมาเพื่อให้ทีมอื่นขอให้จัดการให้
- สร้าง Assume Role เพื่อให้แต่ละทีมเข้ามาจัดการ DNS โดยตรง
Subdomain delegation เป็นการมอบอำนาจการควบคุม subdomain ตั้งแต่ level 3 เป็นต้นไปให้กับ DNS อื่น เพื่อให้สามารถควบคุม subdomain ย่อยลงไปได้อีก

ซึ่งวิธีที่บทความนี้กล่าวถึงคือ Subdomain delegation ด้วย Route53 ระหว่าง 2 AWS Accounts ซึ่งวิธีการดังกล่าวเป็นมาตรฐานของ DNS สามารถทำได้กับ DNS อื่นด้วยเช่นกัน

การเตรียมพร้อม

2 AWS Accounts คือ Domain Account และ Subdomain Account
Domain name ที่ใช้บริการ DNS บน hosted zone ของ Route53 บน Domain Account ซึ่งตัวอย่างนี้จะใช้ lawlity.com
หน้า HTML เพื่อใช้ทดสอบบน Subdomain Account โดยสร้าง S3 static website ชื่อ bucket dns.sub.lawlity.com ไว้เพื่อทดสอบ ใช้อันนี้ก็ได้ ในการสร้าง S3 Static Website เพื่อเชื่อมกับ DNS record ด้วย Alias จะต้องสร้าง bucket name ให้ตรงกับ dns record ที่ต้องการ เช่น กรณีตัวอย่างจะสร้าง S3 bucket ชื่อ dns.sub.lawlity.com

ค่าใช้จ่ายเพิ่มเติม

ค่า Hosted zone บน Subdomain Account 0.50 USD ต่อเดือน
ค่า Query 0.40 USD ต่อ 1 ล้าน Queries ต่อเดือน

ขั้นตอนการสร้าง Subdomain Delegation

ในตัวอย่างจะเป็นการสร้างมอบการควบคุม sub.lawlity.com จาก Domain Account ไปให้ Subdomain Account และสร้าง A record alias เพื่อแสดง Static Website ที่สร้างไว้

สร้าง Public hosted zone บน Route53 ใน Subdomain Account
เมื่อสร้างเสร็จแล้วจะมี NS และ SOA record โดยค่า NS Record คือค่าที่เราจะนำไปใช้ต่อ บน Domain Account ในขั้นตอนที่ 3
เปลี่ยนไป Route53 ของ Domain Account และสร้าง Record ใหม่ประเภท NS โดยใส่ค่าเป็น NS ของ public hosted zone ที่สร้างไว้ในขั้นตอนที่ 2
เปลี่ยนกลับมา Route53 ของ Subdomain Account เพื่อทำการสร้าง Alias Record เพื่อชี้ไปยัง S3 Static Website เตรียมไว้
ทำการทดสอบเข้า lv4 domain dns.sub.lawlity.com ที่สร้างไว้ในขั้นตอนที่ 4 (ในกรณีที่ยังเข้าไม่ได้ต้องรอซักพักเพื่อให้ DNS ทำการอัพเดทก่อน)

สรุปประโยชน์ของการทำ Subdomain Delegation

ด้วยวิธีการง่าย ๆ ข้างต้นโดยใช้ความสามารถพื้นฐานของ DNS ที่หลาย ๆ คนยังไม่เคยใช้งานอย่างการทำ Subdomain Delegation จะช่วยให้สามารถกระจายการจัดการ Subdomain ให้กับทีม หรือ App ต่าง ๆ ในองค์กร ทำให้การติดตั้งระบบ การปรับเปลียนแก้ไขหรือการพัฒนาระบบใหม่ ๆ สามารถทำได้รวดเร็วขึ้น โดยที่การควบคุม Domain หลักที่เป็น identity ขององค์กร ยังอยู่ภายใต้ Account หลักตามเดิมได้

เล่นกับ AWS X-Ray เบื้องต้น

Pakawat (Tle) Teerawattanasuk — Thu, 21 Oct 2021 07:54:55 +0000

Level: Overview - Basic

งานสำคัญอย่างนึงในการพัฒนาระบบคือการตรวจสอบและติดตามหา Root cause ของ error หรือ bug ในโปรแกรม ซึ่งโดยปกติจะมีการนั่งดู log ของ service ต่างๆที่เกี่ยวข้อง แต่สำหรับกรณีที่เราใช้ Serverless หรือ Service ใน AWS นอกจากที่จะเข้าไปตรวจสอบ Log ใน Cloudwatch หรือจุดอื่นๆแล้ว AWS มี Service อีกตัวที่หลายๆคนอาจจะไม่เคยได้ลองเล่น คือ AWS X-Ray ที่ช่วยให้เราสามารถติดตามการทำงานของระบบได้สะดวกมาก และมีประโยชน์ในการวิเคราะห์ว่าการทำงานมีส่วนไปนที่ทำงานผิดพลาดหรือมีคอขวดตรงไหนหรือไม่

โดยในตัวอย่างที่ยกมาจะลองเล่นกับ AWS X-Ray เบื้องต้นซึ่งจะมี Service ต่างๆที่เกี่ยวข้องดังนี้

API Gateway
Lambda Function
S3
DynamoDB

Architecture

นอกจากการทดสอบระหว่าง API Gateway กับ Lambda แล้ว ในตัวอย่างจะเพิ่มการเชื่อมต่อกับ DynamoDB และ S3 รวมไปถึงการสร้าง DynamoDB Stream และ S3 Event Notification เพื่อเรียก Lambda เพื่อทดสอบดูว่า Trace ไปได้ถึงไหน ในเบื้องต้น

Setup

สร้าง DynamoDB Table ชื่อ xray-demo โดยมี partition key ชื่อ id
สร้าง S3 Bucket ชื่อ xray-demo-20211020 (ถ้าไปทำตามเปลี่ยนชื่อและเปลี่ยนชื่อใน code function xray-demo-s3 ด้วยนะครับ)
สร้าง AWS Lambda Function xray-demo-dynamo ทำการเขียนข้อมูลลงบน dynamoDB (อย่าลืมเพิ่ม DynamoDB Policy ให้ LambdaExecution Role)

import json
import boto3
import uuid

def lambda_handler(event, context):
    client = boto3.resource('dynamodb')
    table = client.Table('xray-demo')
    table.put_item(
        Item={ 
            'id': str(uuid.uuid4()), 
            'data': event
        }
    )

    return {
        'statusCode': 200,
        'body': 'Wrote to DynamoDB'
    }

สร้าง AWS Lambda Function xray-demo-s3 ทำการเขียนข้อมูลลงบน s3 (อย่าลืมเพิ่ม S3 Policy ให้ LambdaExecution Role)

import json
import boto3
import uuid

def lambda_handler(event, context):
    filename = str(uuid.uuid4())
    s3 = boto3.resource('s3')
    s3.Object('xray-demo-20211020', 
        f'{filename}.json').put(
            Body=bytes(json.dumps(event).encode('UTF-8'))
            )
    return {
        'statusCode': 200,
        'body': 'Wrote to S3'
    }

สร้าง AWS Lambda Function xray-demo-logging ทำการเขียน Log บน CloudWatch

import json

def lambda_handler(event, context):
    print(event)
    return {
        'Status': 'Done'
    }

สร้าง API Gateway 2 Methods แล้วทำการ Deploy เพื่อใช้ทดสอบ
- GET /dynamodb เพื่อเรียก Lambda Proxy Integrationไปยัง Function xray-demo-dynamo
- GET /s3 เพื่อเรียก Lambda Proxy Integrationไปยัง Function xray-demo-s3

เปิดใช้งาน DynamoDB Stream แล้วให้ Trigger เป็น Lambda Function xray-demo-loging

เปิดใช้งาน S3 Event Notification แล้วให้เรียก Lambda Function xray-demo-logging

การเปิดใช้ X-Ray สำหรับ AWS Lambda

สำหรับ AWS Lambda ทั้ง 3 Functions จะต้องทำการเปิดใช้ X-Ray บน AWS Lambda ก่อน โดยสามารถเปิดใช้งานได้ที่หน้า Configuration > Monitoring and operations tools โดยตัว X-Ray จะใช้ชื่อว่า Active Tracing ซึ่งปกติจะขึ้น Not enabled อยู่ และสามารถกด Edit เพื่อเข้าไปเปิดได้

โดยในการเปิด Active tracing ตัว Lambda จะเพิ่ม Permission ให้โดยอัตโนมัติ

การเปิดใช้ X-Ray สำหรับ API Gateway

สำหรับ API Gateway เมื่อทำการ Deploy API แล้วสามารถเปิดใช้งาน AWS X-Ray ได้ที่หน้า Logs/Tracing ของ Stage นั้นๆ

สำหรับ X-Ray Sampling Rule เพื่อให้ง่ายต่อการทดสอบเฉยๆจะใช้ Default ที่มีอยู่แล้ว (จริงๆคือยังไม่ได้ลอง แหะๆ) ถ้าสนใจรายละเอียดอ่านที่เอกสารของ AWS ที่นี่

ทดลองเรียกใช้งานรอบที่ 1

ลองเรียกทั้ง 2 Function ดูแล้วเข้าไปดูที่ AWS X-Ray เพื่อดูผลลัพธ์ดู โดยจะเรียกจาก Postman และดู Header ที่ตอบกลับมา

เรียก API GET /dynamodb

จากรูปข้างบนจะเห็นว่าจะมี Header X-Amzn-Trace-Id กลับมาด้วย ซึ่งตัวข้อมูลนี้คือค่าที่ X-Ray ใช้ Trace ข้อมูล Request/Response ต่างๆในระบบ ซึ่งเมื่อมีการส่งต่อเลขนี้ไปด้วย
เมื่อเข้าไปดูที่หน้าจอ X-Ray จะสามารถดูรายการ Trace ที่เกิดขึ้นในช่วงระยะเวลาที่เราเลือกได้ (ขวาบน) ซึ่งจะสังเกตได้ว่าเลขอ้างอิง หรือ ID ที่แสดงใน Trace List จะเป็นเลขเดียวกับค่าของ X-Amzn-Trace-Id โดยสามารถเข้าไปดูรายละเอียดของ Request นั้นๆและ Service Map ที่แสดงภาพรวมระยะเวลาในการทำงานของ Node ต่างๆได้ด้วย
เรียก API GET /s3
เพื่อให้เห็นตัวอย่างที่ชัดเจนขึ้นจะทำการแก้ Lambda Function ให้ทำงานผิดพลาด (Lambda Error และ Return 502 จาก API Gateway) 1 รอบ และแก้กลับให้ทำงานปกติ ซึ่งเมื่อดู Trace และ Service Map บน X-Ray จะขึ้นสี เหลือง - Errors (4XX) และ สีแดง - Faults (5XX) ตามลำดับ สำหรับรายการที่ไม่สำเร็จ

การเพิ่มรายละเอียดการ Trace ด้วย Code

จากตัวอย่างการเรียกทั้ง 2 แบบด้านบน จะเห็นว่าข้อมูลการ Trace จบที่ AWS Lambda ไม่แสดงรายละเอียดการเรียกไปยัง DynamoDB และ S3 รวมไปถึงไม่สามารถแสดงกรณีที่ S3 Event หรือ DynamoDB Stream เป็นผู้ Trigger Lambda xray-demo-logging ได้ ซึ่งการจะแสดงผลให้ละเอียดขึ้นจะต้องทำการเรียกใช้ aws-xray-sdk เพื่อให้ทำการเพิ่ม Trace ID ลงบน Header ของการเรียกใช้งาน Service อื่นๆด้วย
ในตัวอย่างจะแสดงการเรียกใช้แบบง่าย ซึ่งถ้าต้องการรายละเอียดเชิงลึกเพิ่มเติมสามารถดูได้ที่เอกสารของ AWS ที่นี่ ส่วนถ้าใช้ภาษาอื่นๆนอกเหนือจาก Python สามารถหาข้อมูลต่อได้จาก Link ข้างต้นเหมือนกัน

ในการเรียก aws-xray-sdk บน Lambda เนื่องจาก AWS ไม่ได้ include library ตัวนี้ไว้ใน default runtime ดังนั้นในเบื้องต้นจะมี 2 ทางเลือกคือ

เขียน Code บนเครื่องพร้อม install package แล้ว upload .zip ขึ้นมายัง Lambda
เพิ่ม Lambda Layer ที่ติดตั้ง aws-xray-sdk ไว้ ซึ่งในตัวอย่างจะใช้การทำงานแบบที่ 2 ซึ่งวิธีการสร้าง Lambda Layer ง่ายๆอ่านได้ ที่นี่

เมื่อทำการสร้าง Lambda Layer แล้ว ให้ทำการ Attach Layer และแก้ Lambda function สำหรับ dynamodb และ s3 โดยเพิ่ม 3 บรรทัดด้านบนดังนี้

from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all
patch_all()

ซึ่งเมื่อแก้ไขแล้วจะได้ Code ของ. Function ที่แก้ไขแล้ว

แก้ไข AWS Lambda Function xray-demo-dynamo

import json
import boto3
import uuid

from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all
patch_all()

def lambda_handler(event, context):
    client = boto3.resource('dynamodb')
    table = client.Table('xray-demo')
    table.put_item(
        Item={ 
            'id': str(uuid.uuid4()), 
            'data': event
        }
    )

    return {
        'statusCode': 200,
        'body': 'Wrote to DynamoDB'
    }

แก้ไข Function xray-demo-s3

import json
import boto3
import uuid

from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all
patch_all()

def lambda_handler(event, context):
    filename = str(uuid.uuid4())
    s3 = boto3.resource('s3')
    s3.Object('xray-demo-20211020', 
        f'{filename}.json').put(
            Body=bytes(json.dumps(event).encode('UTF-8'))
            )
    return {
        'statusCode': 200,
        'body': 'Wrote to S3'
    }

ซึ่งการทำงานของคำสั่ง patch_all() จะไปทำการเพิ่ม Trace Id ใน Header ของทุกคำสั่งที่ X-Ray รองรับ เพื่อให้สามารถ Trace การทำงานได้

ทดลองเรียกใช้งานรอบที่ 2

เรียก API GET /dynamodb
เมื่อเรียก API และเปิดดู Service Map จะเห็นว่ามี Node การทำงานของ DynamoDB Table เพิ่มขึ้นมา ซึ่งถ้าดูใน Trace จะแสดง API ที่ถูกเรียกด้วย คือ คำสั่ง PutItem แต่การแสดงข้อมูลการเรียก xray-demo-logging จะถูกแยกออกจาก Trace ของ API ที่เรียก
เรียก API GET /s3
เมื่อเรียก API และเปิดดู Service Map จะเห็นว่ามี Node การทำงานของ S3 Bucket เพิ่มขึ้นมา ซึ่งถ้าดูใน Trace จะแสดง API ที่ถูกเรียกด้วย คือ คำสั่ง PutObject และการเรียก xray-demo-logging จะแสดงเป็นการถูกเรียกโดย Lambda function xray-demo-s3 แทน โดยไม่แยกออกจากกันเหมือนกรณี DynamoDB

Limitation

อย่างไรก็ตาม จากตัวอย่างข้างบน 2 รูปแบบ จะเห็นว่าการเรียก xray-demo-logging ซึ่งถูกเรียกโดย DynamoDB Stream จะขึ้น Trace Id แยกออกจากการคำสั่งชุดแรกที่ผ่าน API แต่การเรียกผ่าน S3 Event Notification จะมีการส่งต่อ TraceID เพื่อให้เห็นว่าที่มาของการเกิด Trigger เกิดจากที่ใด
ซึ่งรูปแบบที่แตกต่างกันนี้เกิดขึ้นเนื่องจาก X-Ray ยังไม่รองรับการส่ง Trace Id ผ่าน Dynamo DB แต่สำหรับ S3 มีการรองรับการส่งต่อ Trace ID ไปยังคำสั่งต่อไปแล้ว เพียงแต่จะไม่เห็นว่าต้นทางที่เรียกมาจาก S3 Event Notification โดยรายละเอียดการรองรับการทำงานร่วมกับ X-Ray สามารถอ่านเพิ่มเติมได้ที่เอกสารของ AWS ที่นี่

Cost

AWS X-Ray เปิดให้ใช้ฟรีสำหรับการเก็บข้อมูลเดือนละ 100,000 trace และฟรีสำหรับการเรียกข้อมูลหรือสแกนข้อมูลที่บันทึกไว้ 1,000,000 trace หลังจากนั้นจึงคิดเงินเพิ่มตามรูปด้านล่าง

Conclusion

Software developers spend 35-50 percent of their time validating and debugging software. The cost of debugging, testing, and verification is estimated to account for 50-75 percent of the total budget of software development projects
Devon H. O'Dell ACMQueue

งาน Monitor & Debugging เป็นงานที่สำคัญและกินเวลาของ Developer ค่อนข้างมาก ซึ่งการเลือกเครื่องมือต่างๆมาช่วยให้สามารถตรวจสอบหรือติดตามผลการทำงานของ Software ที่พัฒนาขึ้นมาได้อย่างเหมาะสมจะช่วยลดเวลาและค่าใช้จ่ายในการพัฒนาระบบได้ด้วย ดังนั้น AWS X-Ray จึงเป็นหนึ่งในตัวเลือกที่นักพัฒนาบน AWS ควรจะศึกษาไว้เพื่อให้การทำงานง่ายขึ้น

เก็บตก AWS Gameday Security

Pakawat (Tle) Teerawattanasuk — Wed, 06 Oct 2021 11:14:35 +0000

เพิ่งเล่นจบเลยอยากมาเขียนไว้เป็นที่ระลึกนิดนึง สนุกและได้ประสบการณ์ + ความรู้หลายๆอย่างดีครับ ถ้ามีอีกแนะนำให้ ลองสมัครมาแข่งกันดู

ข้างล่างนี่ไม่ได้เฉลยอะไรนะคับ แค่ Note ไว้เผื่อจะได้ไปศึกษาเพิ่มเติม และแนะนำให้คนที่ได้มาอ่านลองมาหาประสบการณ์ในรอบหน้าดูนะคับ

Secret Manager & DB Password Rotation

ในกรณีที่มีการเชื่อมต่อกับ Database ปกติถ้าทำงานกันแบบไวๆ หลายๆคนน่าจะเคยไปใส่ Password ไว้ใน Code บ้าง ใน ENV บ้าง แต่ Practice ในกรณีนี้ที่ AWS ให้ลองเล่นคือ ใช้ Secret Manager แล้วก็ใช้ Code ไปอ่านและ decrypt/parse ค่าที่ใช้ในการเชื่อมต่อกับ DB ออกมา

ส่วนการ Rotate DB Password สามารถตั้งได้ใน Secret Manager แล้วใช้ Lambda Function เข้าไปแก้ Password database แล้วบันทึกเข้า Secret Manager อีกที

AWS Inspector + EC2 Image Builder

ส่วนตัวชอบ AWS Inspector ที่มี Managed Rule ที่ช่วยหาว่า EC2 ของเรามี Vulnerabilities อะไรบ้าง ซึ่งโดยมาก ถ้าตัวที่ใช้ Common Vulnerabilities and Exposures-1.1 นี่ส่วนมากจะแก้ได้ด้วยการ update OS

ซึ่งจากข้างบนถ้าเราน่าจะมี 2 ทางเลือกคือ เข้าไป update OS เรื่อยๆ (แล้วพัง 555) หรือสร้าง EC2 Image ที่ Update ไว้เรียบร้อยแล้ว ลงโปรแกรมพร้อม เสร็จด้วย EC2 Image Builder แล้วเอา Image นั้นมาใช้งาน

จริงๆ ข้อนี้น่าจะสนุกขึ้นถ้าต้องตั้งให้เปลี่ยน Instance ใหม่ด้วยแบบอัตโนมัติด้วย แต่กรณีนี้น่าจะไม่ใช่เรื่อง Security เลยตัดทิ้งไป (ทำไงหว่า 555)

Secure Database (RDS Encryption + AWS Config)

เสียคะแนนไปตรงนี้นิสนึง >_< หลักๆเป็นเรื่องของการ Encryption at rest ของฐานข้อมูลที่รันอยู่แล้ว โดยการ Copy Snapshot เพิ่มการ Encrypt แล้ว Restore ขึ้นมาใหม่ ซึ่งตรงนี้เพิ่งสังเกตว่า db.t2 ไม่รองรับ Encryption at rest ด้วย ต้องใช้ db.t3 แทน

ส่วน AWS Config ซึ่งจะคอย detect ให้ว่าเราตั้งค่าอะไรผิดไปรึเปล่า เป็นอีกตัวที่ชอบมากพอๆกับ inspector โดยเราไปกำหนด compliance rule ต่างๆ (เลือกจากที่ aws สร้างไว้ให้แหละ ซะส่วนใหญ่) ซึ่งส่วนมากจากตัวอย่างที่เห็นมักจะเห็นใช้กับ RDS และ EC2 ซะเยอะ ถ้ามีโอกาสน่าจะลอง explore กับ service อื่นๆดู

ในรูปข้างล่างน่าจะเอาไปรวมกับข้อแรกว่าต้องตั้ง Rotation ด้วยเพิ่มความยาก 555

สุดท้ายความรู้ใหม่จริงๆ ที่ AWS ใจดีแถม Diagram มาให้ด้วยคือการใช้ AWS Config ร่วมกับ Cloudwatch Event Rule เพื่อไป Trigger Lambda อีกที ซึ่งเคยรู้ว่าทำได้แต่ไม่เคยได้ลอง Hand-on จริงๆ

ตรงนี้สงสัยว่า การที่ snapshot จะเป็น public ได้มันต้องตั้งยังไง เพราะเหมือนวิธีแก้คือให้ลบออก แต่ Root cause จริงๆน่าจะเป็นการตั้งให้เวลาสร้าง snapshot ของ DB ตัวอย่างแล้วเป็น public อัตโนมัติ (ไปสร้างทิ้งไว้ตั้งนาน -.- จน AWS Config ขึ้นว่า Solve แล้วแล้วกลับมาใหม่เพราะไปสร้างเพิ่มเอง

IAM Access Analyzer (IAM Access Analyzer, S3 Bucket Policy)

ข้อนี้ค่อนข้างตรงไปตรงมา คือใช้ IAM Access Analyzer (ซึ่งยอมรับว่าไม่เคยใช้มาก่อน) ก็จะบอกให้รู้ว่าเรามีการตั้ง permission ตรงไหนอนุญาตให้ Account อื่นสามารถเข้ามาใช้ได้ โดยจากใน Gameday จะมี IAM Role, S3 และ KMS ซึ่งถ้าเราไม่ได้ตั้ง Security ไว้ให้ดีตั้งแต่แรก มีโอกาสที่อาจจะเจอ Developer มักง่ายตั้งค่าใช้ Account ส่วนตัว ไม่ต้อง Switch ไปมาเพื่อเข้ามาจัดการได้ (เมื่อไหร่ AWS จะให้ login multiple account ซะที -.-)

IAM Role จะมีการตั้งให้ Account อื่นสามารถ AssumeRole ได้ผ่าน Trust Relation
S3 และ KMS จะเป็น Resource Based Policy ที่อนุญาตให้ Account อื่นเข้ามาใช้หรือจัดการ Resource แต่ละตัวได้

ข้อสงสัยค้างคาใจสำหรับกรณีนี้คือ ถ้า Rule ไหนที่เรา Archived ไปแล้ว เพราะว่า ณ เวลานั้นๆเราตั้งใจอนุญาต แล้วอนาคตไม่อนุญาตแล้วเราก็จะไม่เจอ Finding นั้นๆรึเปล่า

Event-Driven Security (Amazon GuardDuty + Event Bridge + Lambda + NACL)

อันนี้น่าจะเป็นข้อที่น่าสนใจสุด เพราะเน้นการทำ Automate จริงๆจังๆมาก โดยจะคล้ายๆกับ กรณีทำ Automate ของข้อ Secure Database ข้างบน แต่ว่าใช้ Event Bridge เป็นตัวกลางแทน ซึ่งก็ไม่เคยลองทำมาก่อนเหมือนกัน

ข้อสงสัยหลักที่อยู่ตรงนี้คือ NACL เนี่ยมี Soft Limit ที่ 20 ต้องไปขอเพิ่ม แต่จากตัวอย่างใน Gameday แป๊บเดียว Lambda ก็ Error NetworkAclEntryLimitExceeded แล้ว เลยไม่รู้ว่าจริงๆแล้วในกรณีแบบนี้้้จะ Automate ในรูปแบบไหนได้บ้างนอกจากแก้ NACL เนื่องจากถ้าเจอเคสนี้จริงๆ น่าจะต้อง block เป็น CIDR หรือไม่ก็ไปแก้ที่ต้นเหตุด้วยการลบ Instance นั้นหรือ block outbound ให้หมดเพราะน่าจะมี Malware ที่คอยยิง outbound แปลกๆอยู่

จากข้างบนพอดีทาง AWS แนะนำมาว่าสามารถเพิ่ม NACL ไปที่ 40 ได้ หรือใช้การ Route Traffic ผ่าน custom NAT Instance แล้ว block ที่ NAT แทน หรือ ไม่ก็ Isolate ตัว Instance ด้วย Security Group ไปเลย

สุดท้ายนี้ขอบคุณทีม AWS Thailand สำหรับกิจกรรมที่ได้ทั้งความสนุก ความรู้ และประสบการณ์ Hand-on หลายๆอย่างด้วยนะคับ ถ้ามีอีกแล้วไม่ติดอะไร น่าจะขอเข้าไปร่วมเล่นด้วยอีก ถ้าใครผ่านมาตรงนี้มีโอกาสแนะนำให้ลองดูนะคับ น่าจะได้เรียนรู้อะไรไม่มากก็น้อย

ปล. จริงๆ สำหรับคนที่ประสบการณ์น้อย ถ้าจบการแข่งแล้วทางทีม AWS มาแนะนำวิธีทำด้วยจะดีมากครับ จะคล้ายๆกับของ JAM ที่ถ้าไม่รู้จริงๆลองกดแล้วทำตามดูด้วย

วิธีแก้ปัญหาเมื่อทำ Keypair EC2 หาย (Linux)

Pakawat (Tle) Teerawattanasuk — Sun, 03 Oct 2021 18:55:50 +0000

ในกรณีที่เราทำ Keypair ที่ใช้ Access EC2 หายสามารถแก้ปัญหาอย่างไรได้บ้าง

Setup

สร้าง Instance ที่ 1 ด้วย Keypair ชุดที่ 1 ซึ่งจะสมมุติให้เครื่องนี้เป็นเครื่องที่ Keypair หายไป และนำสร้างไฟล์ ImportantFile.txt ไว้ เพื่อเป็นตัวอย่าง
สร้าง Instance ที่ 2 ด้วย Keypair ชุดที่ 2 ซึ่งจะเป็นเครื่องที่ใช้เพื่อการแก้ปัญหาเมื่อเราไม่สามารถเข้าถึงเครื่องที่ 1 ได้ (ในในกรณีที่ 3)
Keypair ชุดใหม่สำหรับเครื่องที่ 1 โดยจะต้องนำ public key ของ keypair ไปใส่ไว้ใน ~/.ssh/authorized_keys แทนที่อันเดิม

วิธีแก้ปัญหาแบบที่ 1 ใช้ Session Manager

วิธีนี้ใช้สำหรับกรณีที่ OS ที่เราใช้มีการติดตั้ง System Manager Agent ไว้ไม่ว่าจะเป็นการติดตั้งแบบ Manual หรือเราเลือก AMI ของ OS ที่มี SSM Agent อยู่แล้ว เช่น

Amazon Linux , Amazon Linux 2
Ubuntu 16.04, 18.04 และ 20.04

โดยปกติแล้วถ้าเราไม่ได้สร้าง Instance Profile ที่มี Policy ที่เหมาะสมไว้ จะไม่สามารถใช้งาน Session Manager ได้

โดยในเบื้องต้นสามารถสร้าง Role ที่มี Policy AmazonSSMManagedInstanceCore ใน IAM

และทำการ Attach Role ให้กับเครื่อง EC2 ที่เราทำ Keypair หายไป โดยเลือก Action > Security > Modify IAM Role

หลังจาก Attach Role แล้วรอซักพัก (10 นาทีโดยประมาณ) จะสามารถกด Connect > Session Manager แล้วเชื่อมต่อเข้าไปที่เครื่องได้

เมื่อเข้าไปแล้วเราจะเป็น user ssm-user สามารถเปลี่ยนเป็น user อื่นๆด้วยคำสั่ง sudo su แล้วเข้าไปเปลี่ยน keypair ด้วย keypair ที่เตรียมไว้ได้เลย (/home//.ssh/authorized_keys)

วิธีแก้ปัญหาแบบที่ 2 ใช้ EC2 Serial Console

เมื่อช่วงต้อนปี 2021 AWS เปิดให้ EC2 Serial Console เป็น GA แล้ว (Link) ดังนั้นถ้าเครื่องที่ Keypair หายมีการตั้ง password root user ไว้ (sudo passwd root) จะสามารถที่จะเข้าเครื่อง EC2 ที่เป็น Nitro ผ่านหน้า Console ได้เลย

สำหรับใครที่ยังไม่เคยเปิดใช้งาน EC2 Serial Console สามารถเข้าไปเปิดก่อนได้ โดยจะขึ้นข้อความแจ้งไว้ตามรูป

เมื่อกด Manage Access ให้ไปเลือก Allow เพื่อเปิดใช้ EC2 Serial Console

จากเครื่องตัวอย่างที่สร้างไว้เป็น t2.micro ซึ่งไม่ใช่ Nitro จะไม่สามารถใช้งาน EC2 Serial Console ได้ ดังนั้นเราจะต้องเปลี่ยน Instance Type ก่อน

จากตัวอย่างจะเปลี่ยน Instance Type เป็น T3.Micro แทน

เมื่อเปลี่ยน Instance Type เป็น T3 จะสามารถใช้งาน Serial Console ได้

เมื่อต่อเข้ามาครั้งแรกจะเจอ จอดำๆ ไม่ขึ้นอะไรเลย ไม่ต้องตกใจ ถ้าใครเคยใช้ Linux แบบเครื่องเปล่าๆ จะรู้ว่าเครื่องกำลังถาม user อยู่ (ลองกด Enter ดูสักทีจะขึ้น Message ให้ใส่ Username ตามรูป)

เมื่อใส่ Username และ Password แล้วก็สามารถเข้าไปเปลี่ยน Keypair ที่ authorized_keys ได้ตามสะดวก

แบบที่ 3 แก้ผ่านเครื่องอื่นด้วยการ mount volume EBS

ในกรณีที่ไม่สามารถตั้งค่า SSM ได้ และไม่สามารถใช้ EC2 Serial Console ด้านบนได้ ถ้าเครื่องที่ทำ Keypair หายมี Root Volume เป็น EBS สามารถที่จะใช้วิธีการ Detach EBS Volume ของเครื่องนั้นๆ ไป Attach เข้ากับอีกเครื่อง (เครื่องที่ 2) และทำการแก้ keypair ได้ โดยมีขั้นตอนต่อไปนี้

Stop Instance ของเครื่องที่ Keypair หายไป แล้วทำการ Detach Volume
นำ Volume ที่ถูก Detached ออกมาไป Attach เป็น Volume ที่ 2 ของเครื่องใหม่ (ในตัวอย่าง เครื่องที่ 2 ไม่ได้ปิดเครื่องอยู่) *เมื่อเครื่องที่ 2 มี 2 Volume แล้วให้ทำการ SSH เข้าไปที่เครื่องที่ 2
ใช้คำสั่ง lsblk -f ดูข้อมูล Volume ซึ่งจากตัวอย่างจะมี Volume /dev/xvdf เพิ่มขึ้นมา โดยมี partition xvdf1 อยู่แล้ว แต่ถ้าสังเกตุช่อง UUID จะเห็นว่ามี UUID ซ้ำกัน เนื่องจากทั้ง 2 Volume ถูกสร้างขึ้นมาจาก AMI ตัวเดียวกัน (Amazon Linux2) ดังนั้นการ mount จะต้องใช้ option nouuid ด้วย
ทำการสร้าง Folder และ mount volume ด้วยคำสั่ง sudo mount -t xfs -o nouuid /dev/<partition_name> <mount_point> และทำการตรวจสอบด้วย lsblk -f อีกครั้ง
เข้าไปที่ //.ssh เพื่อแก้ไข authorized_keys
ทำการ Unmount ด้วยคำสั่ง `sudo umount
ทำการ Detach และ Attach กลับไปยังเครื่องที่ 1 ที่ Keypair หายไป โดยในขั้นตอนการ Attach ให้เลือก Device เป็น /dev/xvda เพื่อให้ตรงกับ Root Volume เดิม และทำการตรวจสอบใน Instance Summary > Storage
ทำการ Start Instance ของเครื่องที่ 1 กลับขึ้นมาเพื่อใช้งาน

ทดสอบ SSH ด้วย Keypair ใหม่

ไม่ว่าจะแก้ไขด้วยวิธีการใดใน 3 ขั้นตอนด้านบน เมื่อเปลี่ยน authorized_keys แล้วเราจะสามารถ SSH เข้าไปใหม่ด้วย Keypair ใหม่ได้

การตั้งค่า HTTP Response สำหรับ API Gateway ในการทำงานร่วมกับ AWS Lambda

Pakawat (Tle) Teerawattanasuk — Fri, 24 Sep 2021 10:33:11 +0000

หมายเหตุ: บทความนี้กล่าวถึง Lambda custom integration เท่านั้น โดยผลลัพธ์เมื่อเลือกเป็น Lambda proxy integration จะได้ผลลัพธ์อีกแบบ

หลายๆคนน่าจะเคยสร้าง AWS Lambda Function ขึ้นมาแล้วสร้าง REST API บน API Gateway มาเชื่อมต่อกับ Function ที่สร้างขึ้น ซึ่งขั้นตอนการสร้างดังกล่าวค่อนข้างง่ายและรวดเร็ว แต่ว่าในขั้นตอนง่ายๆนี้หลายคนอาจจะมองข้ามการตั้งค่าที่สำคัญที่อาจจะทำให้การทำงานผิดพลาดได้ โดยเฉพาะถ้า Developer คนนั้นคุ้นเคยกับการเขียนโปรแกรมบนเครื่องส่วนตัว เช่นการเขียนบน Framework หรือการใช้ Express.js ในการจัดการ Web server.

เพื่อให้เห็นภาพของความผิดพลาดนี้มากขึ้น เราจะเริ่มทดลองจากการสร้าง Function ง่ายๆขึ้นมาและทำการทดสอบเรียกด้วย Postman

exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 400,  // Change from 200 to 400
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

ตัวอย่างแรก ใน Template Nodejs ที่ AWS ให้มาเมื่อสร้าง Function แบบ "Author from scratch" บน AWS Lambda แล้วลองแก้ค่า statusCode จาก 200 เป็น 400 ซึ่งถ้าดูผ่านๆจะเข้าใจว่าเมื่อเรียก Function นี้จะได้ค่า HTTP 400 มาแทน 200 ที่ตั้งไว้เดิม แต่ว่าเมื่อลองยิงแล้วเราจะได้ HTTP 200 ตามเดิมมา แต่ในเนื้อหาจะตั้งค่า statusCode: 400 ไว้ ซึ่งตรงนี้เข้าใจได้ง่ายๆว่าเพราะเรา return content ไม่ใช่ตั้งค่า statuscode โดยตรง.

(ในกรณี Lambda proxy integration จะได้ ผลลัพธ์ HTTP 400 Bad Request ถูกต้อง)

( ถ้าไม่คุ้นเคยกับ HTTP Status อ่านที่นี่ )

เพื่อให้เห็นภาพชัดเจนขึ้น ลองเปลี่ยน Code ใหม่ให้มีการ Throw Error อยู่ใน Code ดูบ้าง

exports.handler = async (event) => {
    // TODO implement
    throw new Error('Internal Error - Intentionally throw this error');
};

เมื่อลองเรียกดูแล้วจะพบว่าผลลัพธ์ที่ได้ คือ HTTP 200 (OK) ที่มาพร้อมกับ Error message
(ในกรณี Lambda proxy integration จะได้ ผลลัพธ์ HTTP 502 Bad Gateway ถูกต้อง)

กรณีแบบนี้เหมือนกับว่า Lambda ไม่ Ok นะแต่ API Gateway บอกว่ามัน Ok

(ภาพจาก Beartai.com Seo Ye-ji สวยมว๊ากกกก ซีรีย์ดีแนะนำครับ)

ถ้าใครเคยพัฒนา NodeJS บน ExpressJS หรือใช้ Web Framework อื่นๆ น่าจะคุ้นเคยดี ว่ากับการ throw Error ใน Code แล้วได้ HTTP 500 โดยอัตโนมัติ ซึ่เหตุผลที่ได้แบบนั้นเพราะว่า Framework ทำการ Handle Error ต่างๆให้แล้วสร้าง HTTP Response ที่เหมาะสม เนื่องจากเราทำงานอยู่ใต้ Framework นั้นๆ แต่สำหรับ AWS Lambda กับ API Gateway ซึ่งเป็นคนละระบบกันโดยสิ้นเชิง แต่รองรับการเชื่อมต่อ (Integrate) ระหว่างกัน ดังนั้นสิ่งที่ตอบกลับมา HTTP200 ซึ่งเป็นค่าปกติของ API Gateway นั้นจึงมีความหมายประมาณว่า Code ของคุณถูกเรียกใช้แล้ว

ตั้งค่า Method Response บน API Gateway

อันดับแรกจะต้องกำหนด HTTP Status ต่างๆที่เป็นไปได้ที่ API Gateway จะตอบกลับไปยังผู้เรียก โดยการตั้งค่าทำได้ที่หัวข้อ Method Response บน API Gateway โดยในกรณีตัวอย่างจะมีการตอบ Error 2 แบบคือ

HTTP 500 (Internal Server Error) สำหรับกรณีที่มีการสร้าง Error ขึ้นด้วยการเรียกคำสั่ง throw Error() (ตัวอย่างกรณีที่ 2) โดยในเอกสารของ AWS จะเรียก Error ประเภทนี้ว่า Standard Lambda Error
HTTP 400 (Bad Request) สำหรับกรณีที่มีการกำหนด Response แบบมีโครงสร้างข้อมูล Error ที่เรากำหนดไว้ โดยอาจจะมีการสร้างเป็น Class หรือ Object ที่มีรูปแบบตายตัวและทำการกำหนดตัวเลข Error Code ไว้ใน Object ดังกล่าว (ตัวอย่างกรณีที่ 1) โดยในเอกสารของ AWS จะเรียก Error ประเภทนี้ว่า Custom Lambda Error

ตั้งค่า Integration Response บน API Gateway

เมื่อเรากำหนด HTTP Status ที่จะทำการตอบกลับแล้วในขั้นตอนถัดไปจะเป็นการกำหนดให้ API Gateway อ่านค่าที่ตอบกลับมาจาก AWS Lambda และแปลงข้อมูลเป็น Status ตามที่กำหนด โดยในการอ่านค่า API Gateway จะใช้ Regular Expression ในการทดสอบข้อความในส่วน errorMessage ที่ตอบกลับมา ซึ่งถ้า Regular Expression Pattern ที่กำหนดตรงกับข้อมูลที่ได้รับ API Gateway จะเลือกตอบกลับด้วย HTTP Status ตาที่กำหนดคู่กับ Pattern นั้นๆ นอกจากนี้สำหรับการตังค่า Body Content ที่ API Gateway ตอบกลับมาจะสามารถตั้งค่าได้ด้วย Mapping Template เพื่อกำหนดรูปแบบข้อมูลที่ส่งกลับได้ด้วย

กรณี Standard Lambda Error (500)

ในกรณี Error ที่เกิดจากการเรียก throw Error() ซึ่ง Lambda จะสร้าง Error Object ตอบกลับไปยัง API Gateway โดยอัตโนมัติและมี errorMessage เป็นส่วนประกอบตามรูปผลการทดสอบในกรณีที่ 2 ข้างต้น
โดยในตัวอย่าง เราจะทำการกำหนดข้อความให้ขึ้นต้นด้วยคำว่า 'Internal Error' ไว้หน้ารายละเอียดของ Error ที่ถูกสร้างขึ้น เพื่อให้ง่ายต่อการกำหนด regular expression ที่จะใช้ทดสอบ ซึ่งจะสามารถกำหนด Lambda Error Regexเป็น ^Internal Error.* เพื่อให้ Match กับข้อความ Error ได้ อย่างไรก็ตามจากการทดสอบ กรณีที่เป็น partial match หรือ เป็นการที่ regular expression pattern ตรงกับ errorMessage เพียงบางส่วน จะไม่ถือว่าเป็นกรณีที่กำหนด และ API Gateway จะตอบกลับ 200 ตามค่ามาตรฐาน

เมื่อทดสอบด้วย Postman จะได้ผลลัพธ์ถูกต้องโดย ได้รับข้อมูล HTTP 500 (Internal Server Error) พร้อมกับข้อมูล Error object ต้นฉบับ

เนื่องจากการแสดง Stack trace ส่งไปให้ผู้เรียกใช้ อาจจะไม่ค่อยเหมาะสม เราสามารถกำหนดเนื้อหาของข้อมูลที่จะส่งกลับไปยังผู้เรียกใช้ได้ โดยการตั้งค่า Mapping Template และกำหนดชนิดของข้อมูลเป็น application/json และตั้งค่าให้ตอบกลับเฉพาะ errorMessage เท่านั้น

(อย่าลืมกดปุ่ม Save สีเทาด้านล่าง เพื่อบันทึก Template แทนการกด Save สีน้ำเงินด้านบน ที่เป็นการบันทึกเมื่อแก้ Lambda Error Regex - ส่วนตัวคิดว่าการออกแบบ UX ตรงนี้แปลกๆไปหน่อย ทำให้สับสนได้ง่ายมาก และกดผิดไปหลายครั้งมาก)

เมื่อทำการ Deploy และทดสอบ จะได้ข้อมูลตอบกลับที่ถูกต้องตามที่ต้องการ โดยได้ สถานะ HTTP500 และแสดงเฉพาะข้อความ errorMessage ที่กำหนด

กรณี Custom Lambda Error (400)

ในกรณีที่มีการกำหนดโครงสร้างข้อมูลตอบกลับไว้ โดยอาจจะเป็นการกำหนด Class หรือ Response Object ตามที่ต้องการ โดยการตอบ Error Response จะใช้โครงสร้างข้อมูลแบบเดียวกับ Success Response ตามตัวอย่างกรณีที่ 1
วิธีการที่ง่ายที่สุดที่จะทำให้ API Gateway ทำการตรวจสอบข้อความที่ส่งออกไปและทำการเลือกส่ง HTTP Status ได้อย่างเหมาะสมคือการทำให้เกิดการ Error ด้วยคำสั่ง context.fail() แทนการ return ใน Code ตัวอย่างข้างต้น โดยส่งข้อมูล response ไปในรูปแบบ JSON string ไปยัง Error ที่ถูกสร้างขึ้นเมื่อเรียก context.fail() ซึ่งเมื่อทำการแก้ไขแล้วจะได้ Code ดังนี้

exports.handler = async (event, context) => {
    // TODO implement
    const response = {
        statusCode: 400,  // Change from 200 to 400
        body: JSON.stringify('Hello from Lambda!'),
    };
    context.fail(JSON.stringify(response))
};

เมื่อ Function ถูกเรียก Lambda จะสร้าง Error Object แบบเดียวกับกรณี HTTP 500 ข้างต้น โดยนำข้อมูล Response Object ที่เรากำหนดไปเป็น errorMessage เพื่อให้ API Gateway ตรวจสอบ ซึ่งเราสามารถกำหนด Regular expression pattern คือ .*"statusCode":400.* เพื่อให้ Match กับ statusCode ที่อยู่ใน Response object ได้ และแสดง สถานะตอบกลับได้อย่างถูกต้อง

เมื่อทำการทดสอบแล้วจะได้ผลลัพธ์เป็น HTTP Status 400 (Bad Request) ที่ส่งมาพร้อมกับ Lambda error object ที่ถูกสร้างขึ้น

ในขั้นตอนสุดท้ายเพื่อที่จะทำให้แสดงผล Response content เป็น JSON ตามที่กำหนดไว้ จะต้องทำการสร้าง Mapping Template เพื่อนำ errorMessage กลับมาแสดงเป็น Response Content ตามเดิม

เมื่อทดสอบอีกครั้งจะได้ Response Object ที่เรากำหนดไว้เพร้อมกับสถานะ HTTP400 ที่ถูกต้องตามที่กำหนด

บทสรุป

สำหรับคนที่เพิ่งเริ่มหัดใช้ Lambda และ API Gateway อาจจะเคยเจอปัญหานี้ ซึ่งหวังว่าจะมีประโยชน์กับคนที่ผ่านเข้ามาดูบ้างไม่มากก็น้อยนะครับ ทั้งนี้โดยส่วนตัวเองจะชอบใช้งาน Lambda proxy integration มากการเพราะสามารถควบคุมการทำงานต่างจาก code ได้โดยตรงมากกว่าการใช้งานแบบ Lambda custom integration ตามตัวอย่างในบทความนี้

สุดท้ายนี้ถ้ามีคำถาม คำแนะนำ หรือข้อเสนอแนะใดๆ ผมยินดีเป็นอย่างยิ่งที่จะได้สนทนาแลกเปลี่ยนกับทุกๆท่านที่ผ่านเข้ามาคับ ขอให้สนุกกับการพัฒนาซอฟแวร์นะครับ

เอกสารอ้างอิง

Handle Lambda errors in API Gateway

API Gateway integration response setup for AWS Lambda

Pakawat (Tle) Teerawattanasuk — Fri, 24 Sep 2021 10:33:08 +0000

Disclaimer: This article cover Lambda custom integration only, Lambda proxy integration will work differently

It's a very common strategy to create your function in AWS Lambda and create REST API on API Gateway and integrate them together, however, there's one common and simple mistake that many developer overlook when doing so, especially if you move from local development to Lambda. Let's see the example below



exports.handler = async (event) => {
    // TODO implement
    const response = {
        statusCode: 400,  // Change from 200 to 400
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

The above code blocks is a little modification from pre created code when choose "Author from scratch" when creating Lambda with NodeJS. The only change is from statusCode 200 to 400. Then create a new REST API method point to this lambda function... deploy and done. This is how simple it look like to create REST API, When looking at the code, many developer will say that this will return HTTP Status 400 right? but it's not. You will get response 200 with data statusCode: 400. This case can easily interpret that it's because we return content not HTTP Status.

(For Lambda proxy integration this function will response correctly with HTTP 400 Bad Request)

( For more information about HTTP Status Read Here )

Let's try another example which is more obvious, this time intentionally throw Error in Lambda.



exports.handler = async (event) => {
    // TODO implement
    throw new Error('Internal Error - Intentionally throw this error');
};

Try calling it and get HTTP 200 again with error message as content.

(For Lambda proxy integration this function will response correctly with HTTP 502 Bad Gateway)

Look like It's Okay to Not Be Okay

(Image from Kdramalove.com - Yes... I like Korean series.. and Seo Ye-ji is gorgeous)

If you have experience throwing error and get HTTP 500 when developing locally with express or any framework. That happen because framework handle that error for you and generate correct HTTP Status, while Lambda and API Gateway is totally different services and what API Gateway looking for, by default, is that Lambda answer something and HTTP 200 you get mean yes, your code was executed.

Setup Method Response in API Gateway

First we need to define which HTTP Status we want to send back to client. We can do this in Method Response in API Gateway. So let's add the following error

HTTP 500 (Internal Server Error) for error that has been generated when we call throw Error() (Second case above). According to AWS Documentation, this type of error call Standard Lambda Error
HTTP 400 (Bad Request) for error that we intentionally response with specific formatted string (First case above). According to AWS Documentation, this type of error call Custom Lambda Error

Setup Integration Response in API Gateway

Next, move to Integration Response to configure each case. The general idea for configuring this is to set a pattern (regular expression) that will be tested against response from Lambda function, if the pattern matched, we will get HTTP Response governing that pattern. If no patterns matched, we will get the default HTTP response. (configured to 200 by default or customize by configured with pattern .*)
Furthermore, we can setup response body using Mapping Template.

Handle Standard Lambda Error (500)

For this type of error, when we call throw Error(), Lambda will automatically generate response as shown in screenshot above. In order to test pattern against this type of error, API Gateway will test configured pattern against errorMessage field instead of whole error object.

In our case, we send our error message when generating this error by adding prefix 'Internal Error' in front of any detail. Let's setup using regular expression ^Internal Error.* which will match whole errorMessage. According to my test, if we use partial match (e.g. Internal*) it will not work and we will still get HTTP 200 instead of 500.

Testing on postman again, now we will get HTTP 500 (Internal Server Error) with the same previous content because we use Passthrough for content handling above.

Now that we got correct error, but it's strange to stack trace to client. Let's set Mapping Template for application/json type and return only errorMessage to client.

(There's a strange UX behavior here, when editing Mapping Template you have to grey Save down below text editor instead of clicking blue Save button above, which is more attractive to click.)

Deploy and test it to get the response we want!

Handle Custom Lambda Error (400)

For this case where we want to create our own response with error message and we know that this response is gonna be an error. The easiest way is to forcefully make this function failed and return and error using context.fail instead of return. Additionally, in order for API Gateway to parse error message, we need to convert JSON response to text and the code will be change to the following:-



exports.handler = async (event, context) => {
    // TODO implement
    const response = {
        statusCode: 400,  // Change from 200 to 400
        body: JSON.stringify('Hello from Lambda!'),
    };
    context.fail(JSON.stringify(response))
};

Now that we cause error to occurred, Lambda will return and error object similar to standard error in previous case and we can use regex .*"statusCode":400.* to detect which statusCode we send and return correct HTTP Response.

After testing, you will get HTTP Status 400 (Bad Request) with generated Lambda error object

Last step is to setup Mapping Template to return our intended object

Finally, we will get our same old object but with HTTP Status 400 instead of 200 as intended.

Conclusion

There's a lot more to explore and configure when working with AWS service, this one is just an example of a common mistake mostly happen when start using Lambda and API Gateway or when in need of a quick api creation. Anyway, I personally prefer using Lambda proxy integration which let me have more control. I hope this article help anyway to happen to pass through here or looking for this problem.

Lastly, I would be very appreciate for any comment, knowledge sharing and feedback. Happy coding!

References

Handle Lambda errors in API Gateway

WooCommerce Webhook and AWS Lambda

Pakawat (Tle) Teerawattanasuk — Sun, 12 Sep 2021 02:32:36 +0000

WooCommerce is very popular platform for e-commerce, while it's in PHP and usually self-hosted on self-managed servers or shared host, I got some question from my friend to extend WooCommerce functionality. It's possible to write plugin but for my use cases, using WC Webhook and AWS Lambda is more convenient. In this example, I will handle Webhook call when order is updated (order.updated).

More information about WC Webhook

Pre-requisites

Pre installed Wordpress & WooCommerce (And your host IP)
Basic knowledge of creating lambda function with NodeJS runtime
Basic knowledge about to create REST API on API Gateway

Architecture

Workflow

When receiving Webhook event, it's important to check for integrity of Webhook content to prevent malicious request. In order to do so we can calculate HMAC using Webhook content and secret which store in both side. After validated event integrity, we can proceed to process event.

Setup AWS Lambda

First, let create Lambda function that will process our webhook event.

Create lambda function with Node runtime
Set up Configuration > Environment Variables > Add WC_SECRET (this same value should be used when configure WooCommerce Webhook later)
Add The following Code to Lambda index.js file
For Testing, if you set WC_SECRET to "woocommerce", you can use the following test event in Lambda
Deploy and testing Lambda function will give you the success screen with event log (OnOrderCompleted in screenshot below)

Setup API Gateway

Next step is to create API Gateway to receive webhook. For some unknown reason, WooCommerce Webhook don't fire pre-flight request (OPTION) and always skip CORS, so I will skip detail about enabling CORS here.

Create REST API
Create Resource (order)
Create POST method point to the Lambda function created earlier. Note that we need to enable Lambda Proxy Integration in order to forward header to Lambda Function.

In order to only allow API call which initiate from our WooCommerce server. Create Resource Policy with explicit Deny on call from IP outside our own servers.

Using Resource Policy below, replace REGION, ACCOUNT_ID, API_ID and SOURCE_CIDR with your own configuration.

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Principal": "*",
        "Action": "execute-api:Invoke",
        "Resource": "arn:aws:execute-api:{{REGION}}:{{ACCOUNT_ID}}:{{API_ID}}/*/*/*"
    },
    {
        "Effect": "Deny",
        "Principal": "*",
        "Action": "execute-api:Invoke",
        "Resource": "arn:aws:execute-api:{{REGION}}:{{ACCOUNT_ID}}:{{API_ID}}/*/*/*"
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": "{{SOURCE_CIDR}}"
            }
        }
    }
]
}

Finally, Deploy API and get your Webhook target URL (don't forget to add your resource name when calling it)

Setup WooCommerce Webhook

Go to your WooCommerce (in my case i use ngrok to host it locally) and config Webhook

To config webhook go to Setting > Advanced > Webhooks and select Add Webhook
Config new webhook as we plan
- Status : Active
- Topic : Order Updated
- Delivery URL : API Gateway's Invoke URL following by /order (or any resource name, created in API Gateway)
- Secret : same value with WC_SECRET configured in AWS Lambda's Environment Variable.
Hit Save, you may likely get error 400, like the picture below, because when we setup webhook, woocommerce try to send POST request to our API but we didn't handle it above. However, our webhook will work anyway, let's go to test our webhook.

Test it!

Let's test our webhook, create an order and update it to processing or completed and let's check the logs.

WooCommerce Log at Status > Logs and select log file starting with webhook-delivery- and click view. In Response value, check http response Code and Body value to see success webhook.
Alternately, you can check CloudWatch Log groups for AWS Lambda log.

Conclusion

There're many things we can do with WooCommerce Webhook e.g. Save your information for further processing or trigger automation. I write this article aiming for those who want to start explore and expand your e-commerce business, so if you happen to come across this, I hope you found it useful and help you realize your idea in business!

Tag-based monorepo docker image build on AWS

Pakawat (Tle) Teerawattanasuk — Tue, 07 Sep 2021 09:09:22 +0000

My team adopted monorepo for our backend microservices and we need a simple solution to build docker images so we can use it for test or deploy anywhere. Because we use Amazon Elastic Container Repository (ECR) to store docker images, I decided to use git tag to trigger docker image build on AWS CodeBuild and push it to ECR.

The condition to trigger build is adding tag service-name/version-number and push it to GitHub or Bitbucket. AWS CodeBuild will receive webhook and start building new docker image using version-number provided in tag and push it to ECR. And lastly.... store build artifact in S3.

The REPO

Firstly, we need a monorepo on GitHub or Bitbucket, I prepared a sample repo with 2 projects at https://github.com/teer823/monorepo-aws-docker.

Each projects is just a simple express service with Dockerfile ready to build docker image and include buildspec.yml for AWS CodeBuild to use, however, I also added 2 buildspec file inside buildspec folder to demonstrate that it's possible to separate buildspec.yml file per project as needed.

The buildspec.yml file is an instruction for AWS CodeBuild and separated to phases. Here's what I do at each phase.

pre_build extract TAG_VERSION_NUMBER from tag and create version.txt file to store as artifact then login to ECR
build as the name say... build and tag docker image. Please note that I also add latest tag here as well, doing so prevent me from using ECR's tag immutability feature.
post_build push docker image to ECR

version: 0.2

phases:
  pre_build:
    commands:
      - echo Pre Build Phase...
      - export TAG_VERSION_NUMBER=$(echo $CODEBUILD_WEBHOOK_TRIGGER | sed 's/.*\///')
      - echo $TAG_VERSION_NUMBER
      - >
        PACKAGE_VERSION=$(cat $REPO_FOLDER/package.json | grep version | head -1 | awk -F: '{print $2}' | sed 's/[",[:space:]]//g')
      - echo $PACKAGE_VERSION > version.txt
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
  build:
    commands:
      - echo Build Phase...
      - cd $REPO_FOLDER
      - docker build -t $IMAGE_REPO_NAME:$TAG_VERSION_NUMBER -t $IMAGE_REPO_NAME:latest .
      - docker tag $IMAGE_REPO_NAME:$TAG_VERSION_NUMBER $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$TAG_VERSION_NUMBER
      - docker tag $IMAGE_REPO_NAME:latest $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:latest 
  post_build:
    commands:
      - echo Post Build Phase...
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$TAG_VERSION_NUMBER
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:latest
artifacts:
  files:
    - '$REPO_FOLDER/**/*'
    - 'version.txt'
  name: '$IMAGE_REPO_NAME-$TAG_VERSION_NUMBER'
  discard-paths: no

For more info about buildspec.yml please refer to HERE

AWS ECR

As I want to push docker image to ECR, I need to pre-create container repositories for each service beforehand. Just go and create a private repository and please don't enable Tag immutability or build will failed as latest tag cannot be overwritten. (Or just change the build spec and remove latest tag)

AWS S3

We want CodeBuild to store build artifact on AWS S3, so we need to prepare a bucket in advance. Let's create a bucket! (Leave the rest of configuration default or up to you.., i recommend turn on server-side encryption for BEST PRACTICE reason)

AWS CODEBUILD

Now we have Code Repo , Container Repo, Artifact bucket.. let's create AWS CodeBuild project.

Project configuration your choices..
Source connect to your GitHub or Bitbucket and select repository in my GitHub account and select our monorepo repository. Please note that we need to rely on webhook so public repo won't do.
Primary source webhook events Here's what important. Enable webhook by checking the box. And config build condition
- Build type - Single build
- Event type - PUSH and PULL_REQUEST_MERGED
- Condition - Start build when receiving tag, in HEAD_REF add a regular expression ^refs/tags/service-name/([\w\.-]+)$, don't forget to replace service-name accordingly.

If you want to use other method to trigger build, here's the place to try and modify build condition according to your usecases.

Environment I personally prefer Ubuntu, so it's up to you how you want to config your build machine, however what's important for me here are the following
- Privileged Enable the flag because we want to build docker images
- Service role Select your preferred name, I personally like to reuse the role in same project so I name it with project instead of service and next time I can just select it from existing service role. However, please remember the Role name because we will need it later.
- Environment Variable If you noticed in buildspec.yml earlier, I used some environment variable. you will need to set it here
  - AWS_DEFAULT_REGION - your ECR region
  - AWS_ACCOUNT_ID - your ECR account Id
  - IMAGE_REPO_NAME - name of ECR remove created above
  - REPO_FOLDER - folder name for service we're building
Buildspec when using root's buildspec.yml just select Use a buildspec file will do.

In case you want to try using individual buildspec file, add path to project-buildspec file in Buildspec name field
Artifacts Select Amazon S3 and bucket created above, use Zip packaging and use service-name as path.

Hit Create build project and we're done...then add another one for 2nd service.

PERMISSION

One last step before start tagging and building. our service role don't have permission to push docker image to ECR yet. so we need to add it in IAM. Go to your Role created above and Attach Managed Policy name AmazonEC2ContainerRegistryPowerUser to our role and Done!

TAGGING TIME!

Now it's time to add tag to monorepo and push it to origin

❯ git tag ingest-service/0.1.0
❯ git push origin ingest-service/0.1.0

Go back to CodeBuild project and see it work!

When building complete, find your new docker image in ECR!

Conclusion

That's all about it. I hope this is useful for anyone looking to make a simple build pipeline like my team :)