1 เดือนกับ Google Cloud Container Builder

Google Cloud แอบ launch Container Builder มาสักพักแล้วครับ (ยังไม่ขึ้นในหน้า product list) ก็เลยว่าจะลองเล่นสักหน่อย

Background

เดิมที TMStreamlabs อยู่บน GitLab ครับ และใช้ Docker ในการ deploy มาตั้งแต่ต้นอยู่แล้วเพราะบน Infra ใหม่ ทุกอย่างต้องเป็น Docker หมด

ของเดิมเลยผมจะใช้ GitLab CI มา build image และเก็บไว้บน GitLab Registry ซึ่งก็โอเคดียกเว้นว่า GitLab Registry pull ช้ามาก

ย้ายบ้าน

หลังๆ GitLab เริ่มไม่นิ่ง ผมก็เลยว่าได้เวลาย้ายบ้านแล้ว พอดีนึกออกว่า GitHub (Edu) ให้ private repo ไม่อั้นมาเป็นปีแล้ว ก็เลยย้ายไป GitHub พร้อมๆ กับย้าย builder มาใช้ Container Builder ซึ่งเค้าว่ามันเร็ว

สำหรับ Container Builder มีสมบัติดังนี้ครับ

  • (เค้าว่า) มันเร็ว เพราะใช้ network ของ Google
  • Builder รันบนเครื่อง n1-standard-1 ซึ่งได้ Dedicated CPU Core เลย ในขณะที่ GitLab ใช้ DigitalOcean ที่จะ share core ระหว่างผู้ใช้
  • ผมเดาว่า builder อยู่ในอเมริกา ซึ่งผมก็ส่ง feature request ไปแล้วว่าอยากให้เลือกที่อื่นได้
  • Parallel build step ได้ แต่ parallel build ทั้งหมดไม่ได้ยกเว้นข้าม project
  • ราคาไม่แพงเท่าไร และฟรีวันละ 120 นาทีซึ่งผมยังไม่เคยใช้หมด
  • โค้ดเราจะโดน mirror จาก GitHub มาใส่ Google Cloud Source Repositories

ซึ่ง build ของ TMStreamlabs ก็ไม่มีอะไรอยู่แล้วครับ ใช้ Dockerfile ได้เลย แล้วก็จะมี test step อีกทีนึง (เรารัน test หลัง build เพราะต้องการ test ด้วย container ผลลัพท์จริงๆ ซึ่งจะจับบั๊กบางประเภทได้ด้วย เช่นลืมลง shared library) วิธีการก็ไม่ยากครับ ใน cloudbuild.yaml ก็เขียนไปว่า

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', 'asia.gcr.io/$PROJECT_ID/tmstreamlabs', '.']
- name: gcr.io/cloud-builders/docker
  entrypoint: /workspace/scripts/test.sh
  env:
    - IMAGE_NAME=asia.gcr.io/$PROJECT_ID/tmstreamlabs
images:
  - asia.gcr.io/$PROJECT_ID/tmstreamlabs

Shared workspace

ความเจ๋ง (?) ของ Container Builder คือ folder ที่ build จะแชร์กันข้าม build step ครับ จะต่างกับ GitLab ตรงที่ GitLab จะต้องบอกให้มันก๊อปออกมาเอง (เพราะอาจจะรัน build step ที่เครื่องอื่น) ฉะนั้นแล้วมันทำให้เราเล่นอะไรได้สะดวกมากๆ

ตอนหลังผมเลยจัดชุดใหญ่เลยครับ ด้วยการเพิ่ม Gulp + Webpack เข้ามาใน project Django ซึ่งเดิมทีผมตั้งคำถามหลายรอบว่าจะรัน build step แบบนี้ตรงไหนดี ก็พบว่า pattern แบบนี้แหละเวิร์คที่สุดแล้ว

steps:
- name: yarnpkg/node-yarn
  args: ['./scripts/minify.sh']
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', 'asia.gcr.io/$PROJECT_ID/tmstreamlabs', '.']
- name: gcr.io/cloud-builders/docker
  entrypoint: /workspace/scripts/test.sh
  env:
    - IMAGE_NAME=asia.gcr.io/$PROJECT_ID/tmstreamlabs
images:
  - asia.gcr.io/$PROJECT_ID/tmstreamlabs

สังเกตว่าเราจะเพิ่มอีก step ไปก่อนหน้าครับ โดยจะรัน minify.sh ซึ่งข้างในก็จะรัน yarn install + gulp แล้วก็ลบ node_modules ทิ้งไป

สำหรับในฝั่ง Django จะเซตใน settings.py ดังนี้ครับ

built_static_root = os.path.join(BASE_DIR, 'static')
if os.path.isdir(built_static_root):
    STATICFILES_DIRS = [built_static_root]

ซึ่ง script Gulp ของผมนั้นจะไป scan หา /static/js/ แล้ววิ่งผ่าน uglifyjs เข้าไปเก็บที่ static/js/* ด้านนอก ทำให้ตอน dev ก็จะเรียกไฟล์ไม่ minify เวลา compile แล้วก็จะเรียกไฟล์ minify ได้เลย และวิ่งผ่าน collectstatic ได้ด้วยทำให้สามารถใช้ Manifest static file storage ได้ (สำหรับไฟล์ที่ใช้ webpack จะเก็บแยกนอก static ครับ ซึ่งเวลา dev ต้องเปิด gulp watch ค้างไว้ให้มัน build ตลอด)

Parallel Step

ตอนแรกๆ Parallel step มีบั๊กครับ คือ schema จะ validate ไม่ผ่านเลย แต่ตอนนี้เหมือนจะแก้แล้ว ทำให้เราสามารถรัน step หลายๆ อันพร้อมกันได้ เช่นแบบนี้

steps:
- name: yarnpkg/node-yarn
  args: ['./scripts/minify.sh']
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', '-r', 'gs://tmsbuildassets/', '/workspace/gs/']
  waitFor: ['-']
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', 'asia.gcr.io/$PROJECT_ID/tmstreamlabs', '.']

# prepull images in use
- name: gcr.io/cloud-builders/docker
  args: ['pull', 'mariadb:latest']
  waitFor: ['-']
- name: gcr.io/cloud-builders/docker
  args: ['pull', 'redis:alpine']
  waitFor: ['-']
- name: gcr.io/cloud-builders/docker
  args: ['pull', 'willwill/wait-for-it']
  waitFor: ['-']

- name: gcr.io/cloud-builders/docker
  entrypoint: /workspace/scripts/test.sh
  env:
    - IMAGE_NAME=asia.gcr.io/$PROJECT_ID/tmstreamlabs
images:
  - asia.gcr.io/$PROJECT_ID/tmstreamlabs

นี่คือทั้งไฟล์ที่ใช้อยู่แล้วครับ ซึ่งจะเห็นว่ามันจะ pull images ทั้งหมดมาพร้อมกันเลย และพอเราบอกว่ามันไม่ depends on อะไรเลยจะทำให้มัน pull พร้อมๆ กับรัน yarn เลย

อีกอันนึงที่จะเห็นนะครับ คือผมใช้ gsutil ใน build script ด้วย ซึ่งเจ้าเครื่อง container builder นี่จะมีสิทธิ์พิเศษใน IAM (จะเขียนว่า Google APIs service account อีเมล projectid@cloudbuild.gserviceaccount.com) ทำให้เราสามารถ grant สิทธิ์ให้เครื่อง builder โดยเฉพาะได้ ไม่ต้องเปิด public

ข้อเสีย

สำหรับตอนนี้ข้อเสียที่เจอคือ error reporting มันไม่ดีเลยครับ เพราะ build เสร็จมันจะเงียบไปเลย ในขณะที่ GitLab CI จะเมลสถานะกลับมา ตรงนี้อาจจะต้องเอา image อีกอันมา trigger service แจ้งเตือนอีกที ซึ่งก็ไม่รู้ว่ามันจะทำให้ระบบไม่หยุดทำงานตอนเจอ error ไปซะก่อนได้หรือเปล่า

Implementing libsodium Sealed Box

พอดีมี project ที่จะใช้ Sealed Box เลยได้นั่ง implement ให้กับภาษาที่ใช้งานอยู่ เลยอยากเอามาเล่าให้ฟังครับ

อะไรคือ libsodium

ถ้าเคยเขียนโปรแกรมที่ต้องใช้การเข้ารหัสข้อมูล น่าจะรู้จักกับ OpenSSL ครับ หรือถ้าใช้ PHP อาจจะเคยผ่านตากับ mcrypt ซึ่งสองตัวนี้เป็น library ที่รวบรวม algorithm เข้ารหัสไว้มากมายให้เราเลือกใช้

ปัญหาคือทางเลือกไม่ใช่เรื่องดีครับ เพราะกลายเป็นว่าโปรแกรมเมอร์จะต้องศึกษาดูก่อนว่า Algorithm ตัวไหนปลอดภัยบ้าง และแถมบางที library ก็ไม่ตรงปกซะเอง

นักวิทยาการรหัสลับ นำโดยคุณ Daniel J. Bernstein (djb) ผู้คิดค้น algorithm Ed25519/Poly1305/Salsa20 ที่กำลังมาแรงในช่วงนี้ ก็เลยคิดพัฒนาไลบรารีใหม่เข้ามาที่จะทำให้เข้ารหัสเป็นเรื่องง่าย และเร็ว มีชื่อว่า NaCl (อ่านว่า salt) ย่อมาจาก Networking and Cryptography Library (อ่านที่มาได้ใน Paper นี้ ครับ ไม่มีแมทอะไรมากอ่านสนุกดี)

นอกจากนี้เค้ายังพัฒนา TweetNaCl ซึ่งเป็นไลบรารีที่ใช้งานได้เหมือน NaCl แต่ขนาดเล็กเพียง 140 ตัว * 100 tweets เท่านั้น ทำให้สามารถอ่านโค้ดทั้งหมดเพื่อตรวจสอบได้ง่าย (ปัจจุบันมีการ port ไปหลายๆ ภาษาอีกด้วย เช่น Python, JavaScript) ทั้งนี้ความแตกต่างคือ TweetNaCl อาจจะทำงานช้ากว่า

ปัญหาคือ NaCl นั้นลงยากพอสมควร ทาง OpenDNS ก็เลยเอา NaCl ไปจัดระเบียบใหม่ให้นำไปใช้ได้ง่ายขึ้นอีก โดยเรียกไลบรารีใหม่นี้ว่า Sodium

สำหรับการใช้งานของ NaCl/Sodium นั้นจะเปลี่ยนคำถามใหม่จาก “ต้องการเข้ารหัสด้วย algorithm อะไร” เป็น “ต้องการความปลอดภัยแบบไหน” ตัวอย่างเช่น

  1. ถ้า Alice ต้องการส่งข้อความลับให้เฉพาะ Bob ก็ใช้ Box (authenticated encryption) ซึ่งเมื่อได้รับข้อความแล้ว Bob ยังสามารถยึนยันได้อีกด้วยว่า Alice เป็นผู้เขียนข้อความนี้จริง และข้อความไม่ถูกแก้ไขระหว่างทาง
  2. ถ้าต้องการส่งข้อความที่เข้ารหัสโดยใช้ password ก็ใช้ Secret box (authenticated encryption)
  3. ถ้าไม่ต้องการเข้ารหัสแต่ต้องการยึนยันว่าข้อความนี้เราเขียนจริง โดยใช้ระบบกุญแจสาธารณะ ก็ใช้ Sign (public-key signature)

จะเห็่นว่าเราไม่จำเป็นต้องทราบว่าด้านหลังมันทำงานยังไง ใช้ algorithm อะไรเลยด้วยซ้ำ อ่านรายละเอียดแต่ละ abstraction แล้วถ้าตรงกับโจทย์ก็เลือกใช้ได้ทันที

อะไรคือ Sealed Box

ทีนี้สิ่งที่ผมสนใจคือ Sealed box ครับ ซึ่งเป็นหนึ่งใน Security model ที่มีใน libsodium แต่มันพิเศษคือเป็นตัวที่ libsodium สร้างขึ้นมาเอง ไม่มีใน NaCl ปกติ

Sealed box จะเหมือนข้อ 1 ด้านบน คือใช้ส่งข้อความลับหาผู้รับที่เจาะจงและรู้ public key ของเค้า (เช่นส่งหาคุณ Bob) แต่ต่างกันคือเราไม่ต้องการยึนยันตัวผู้ส่งด้วย (ในตัวอย่างด้านบนคือ Alice ไม่ต้องการให้รู้) ซึ่งเราใช้ Box ปกติทำไม่ได้เพราะ Box จะต้องระบุ public key + secret key ของผู้รับและผู้ส่ง

ปัญหาคือพอมันเป็นสิ่งที่มีใน libsodium แล้ว ไลบรารีที่เอา NaCl ไปใช้ก็จะไม่ค่อยมี sealed box ให้ใช้ ซึ่งในหลายๆ ไลบรารีก็จะมี feature request เรื่องนี้อยู่

แกะ Sealed Box

วิธีแก้ปัญหาก็ไม่ยากครับ ไม่มีก็เขียนใช้เองซะสิ! แต่เราคงต้องแกะซอร์สซะก่อน

ซอร์ส libsodium จัดไว้ค่อนข้างง่ายครับ หาเจอไม่ยาก ไฟล์ที่เราต้องการคือ libsodium/src/libsodium/crypto_box/crypto_box_seal.c

พออ่านโค้ดใน crypto_box_seal แล้วก็จะพบว่าจริงๆ แล้ว Sealed box ก็คือ box ประเภทหนึ่งครับ ซึ่งจะสร้าง public และ private ของผู้ส่งขึ้นมาใหม่ทุกครั้ง แล้วก็ใช้ Box ปกติเข้ารหัสได้เลย จากนั้นเวลาส่งข้อมูลก็ให้ส่ง public key นำไปก่อน แล้วตามด้วย Box

ที่น่าสนใจคือ Nonce ครับ ใน docs ของ Box จะบอกว่าการส่งข้อความจะต้องมี Nonce ทุกครั้ง (ถ้าใครอ่านตำรา crypto มา อาจจะรู้จักกับ IV เจ้า Nonce นี่ก็คือ IV ล่ะครับ แต่ต่างกันคือ NaCl อนุญาตให้ใช้ string ใดๆ เป็น Nonce ได้ ขอแค่ห้ามใช้ซ้ำกัน ต่างกับ IV ตรงที่ IV จะต้องคาดเดาไม่ได้ด้วย) แต่การสร้าง Nonce ของ Sealed box น่าสนใจมากครับ คือแทนที่จะสุ่ม Nonce มา เราก็พบว่า Public key เราสุ่มใหม่ทุกรอบอยู่แล้ว ก็เลยเอา public key นั้น ต่อกับ public key ผู้รับ เข้า Hash function ก็จะได้ Nonce เลยที่ไม่ซ้ำแน่นอน และไม่จำเป็นต้องส่งไปด้วยเพราะผู้รับก็ทราบ public key ทั้งหมดอยู่แล้ว

อีกจุดนึงของ Nonce generation ที่น่าสนใจคือมันใช้ Hash function ใหม่ล่าสุดอย่าง BLAKE2 ครับ ข้อดีของเค้าคือสามารถกำหนดความยาวของแฮชเองได้ ไม่เหมือน SHA-256/512 ที่กำหนดความยาวไว้ชัดเจน แน่นอนว่าในเคสนี้เราก็กำหนดให้ยาวเท่ากับ Nonce ที่ Box ต้องการได้เลย

สุดท้ายแล้วผมก็พบว่าไม่ต้องอ่านโค้ดก็ได้ ใน docs เค้าก็เขียนไว้ชัดเจนแล้วว่ามันคือ ephemeral_pk ‖ box(m, recipient_pk, ephemeral_sk, nonce=blake2b(ephemeral_pk ‖ recipient_pk)) *facepalm* (‖ แปลว่าต่อ string)

Implement ใน JavaScript

ทีนี้ก็ได้เวลา implement ครับ ใน project ที่ผมจะทำ client side จะเข้ารหัสข้อความไปให้ server ซึ่งก็แน่นอนว่าฝั่ง client เราจะต้องใช้ JavaScript

ใน JavaScript ก็มีหลาย library ที่ใช้ libsodium ครับ แม้แต่ libsodium เองก็ยังมี official release ที่ใช้ Emscripten compile เป็น JavaScript ให้เลย แต่ปัญหาคือมันจะใหญ่มากและเปลือง memory ก็เลยตัดสินใจใช้ pure JavaScript implementation อย่าง TweetNaCl.js ซึ่งตัวนี้โดน Security audit มาแล้วด้วยซ้ำ และผลการ Audit คือ “ยอดเยี่ยม ไม่เจออะไรไม่ดีเลย” เป็นเรื่องที่หายากมากๆ

เวลาเขียนตัวนี้ก็ไม่ยากครับ JavaScript ยุคใหม่มี Fixed size array อย่าง Uint8Array แล้ว ก็ map จาก C ลงไปได้เลย แต่เขียนไปสักพักก็จะเจอปัญหาว่าไม่มี BLAKE2!

คือ NaCl ของแท้ๆ เนี่ยครับ hash function ที่เค้าเลือกใช้จะเป็น SHA-512 แต่ใน NaCl จะเปลี่ยนเป็น BLAKE2 ฉะนั้นก็ไม่มีทางเลือก เราต้องลง library ที่ทำ BLAKE2 ได้

ก็ปรากฏว่า BLAKE2 มีสองแบบครับ คือ BLAKE2s ที่มี library BLAKE2s.js และ BLAKE2b ที่มี library BLAKE.js ทำไว้ ตอนแรกก็เลือกผิดตัวไป เสียเวลาเขียนใหม่เล็กน้อย

(สำหรับความแตกต่างคือ BLAKE2s จะ optimize สำหรับ 32 bit ครับ และ BLAKE2b optimize สำหรับ 64 bit ผลลัพท์ไม่เหมือนกันใช้สลับกันไม่ได้นะครับ)

สุดท้ายก็ได้ Library ออกมาครับอย่าง tweetnacl-sealed-box ไปจิ้มจาก npm ได้เลย

Implement ใน Python

สำหรับฝั่ง server ผมใช้ Django ซึ่งสำหรับภาษา Python นั้นก็มี libsodium binding หลายตัวครับ เดิมทีผมใช้ PyNaCl อยู่ แต่อยากจะย้ายเป็นตัวอื่นที่มี wheel จะได้ build ไวๆ (มันเป็น Docker ครับ build นานเสียเวลา)

ตัวที่เลือกใช้ก็คือ libnacl ซึ่งเลือกจากว่ามันใช้ใน Salt ที่เป็น Server automation tool เจ้าดังตัวนึง (แต่เอาเข้าจริงเหมือนเค้าจะไม่ค่อย maintain libnacl เท่าไรนะ)

สำหรับ Implementation อันนี้ไม่ยากครับ เพราะ libnacl นั้นจะไปเรียก sodium.so ของแท้ๆ อยู่แล้ว เราก็แค่เขียน ctypes definition ให้มัน ก็จบ แต่ครั้นจะส่งแพทช์ไปแบบนี้เลยก็คงจะไม่ดีเท่าไร เลยต้องเขียน Abstraction ให้เค้าด้วย และ documentation ซึ่งก็ไม่รู้จะเขียนอะไรดี เลยก๊อปอีกหน้านึงมาแก้ซะเลย 555

สรุป

Sealed box เป็น design ที่น่าสนใจครับ คือเค้าพยายาม design ของใหม่ โดยใช้ของเดิมที่มีอยู่แล้ว เนื่องจากว่าของเดิมถูกพัฒนาโดยนักวิทยาการรหัสลับจึงมั่นใจได้ว่าปลอดภัย พอเป็นแบบนี้แล้วการจะ port ไปให้ภาษาอื่นๆ เลยค่อนข้างง่าย แต่ถ้า port ไป TweetNaCl ก็จะยุ่งยากนิดนึง

อ่านมาถึงตรงนี้ไม่รู้ว่าเจอศัพท์เทคนิคกันจนปิดไปหรือยัง แต่จะบอกว่า “ชนะโดยไม่ต้องรบจึงว่าเลิศ” นะครับ ถึง NaCl จะทำให้เราเข้ารหัสข้อมูลแบบปลอดภัยได้ง่ายๆ แต่ถ้าเราสามารถออกแบบโปรแกรมที่ไม่จำเป็นต้องเข้ารหัสเลยก็จะปลอดภัยกว่าแน่นอน