ไม่ว่าเราจะใช้เวลาและความพยายามมากเพียงใดในการรักษาความปลอดภัยแอปพลิเคชัน มันก็จะน้อยลงเสมอ แต่ขั้นตอนการทำงานง่ายๆ สำหรับสิ่งต่างๆ เช่น การจัดการความลับ การหมุนเวียนคีย์ และการหมดอายุของรหัสผ่าน ช่วยให้แอปพลิเคชันและโครงสร้างพื้นฐานของเรามีความยืดหยุ่นต่อการโจมตีที่เห็นได้ชัด
หากคุณเคยใช้ AWS Elastic Container Service (ECS) / Fargate คุณจะสะดุดกับปัญหาการส่งความลับไปยังคอนเทนเนอร์ที่ทำงานอยู่อย่างแน่นอน โพสต์นี้อธิบาย 3 วิธีในการส่งความลับเป็นตัวแปรสภาพแวดล้อมไปยังแอปพลิเคชันที่ทำงานเป็นงาน AWS ECS
วิธีที่ 1 — ส่งความลับเป็นตัวแปรสภาพแวดล้อมในคำจำกัดความงาน ECS
- ดี: จำเป็นต้องมีโครงสร้างพื้นฐานขั้นต่ำ
- แย่: คำจำกัดความงาน ECS ควบคู่ไปกับความลับอย่างแน่นหนา จำเป็นต้องปรับใช้ใหม่หากคุณเปลี่ยนค่าของข้อมูลลับ
- แย่: ข้อมูลลับที่เปิดเผยแก่ทุกคนที่มีสิทธิ์เข้าถึงคำจำกัดความของงาน ECS
วิธีที่ 2 — ดึงข้อมูลลับล่าสุดโดยใช้สคริปต์จุดแรกเข้า
เมื่อใช้สคริปต์จุดเข้าใช้งานนักเทียบท่า คุณสามารถดึงข้อมูลลับได้จากทุกที่ที่คุณต้องการก่อนที่แอปพลิเคชันจะบู๊ต
- ดี: ข้อมูลลับที่แอปพลิเคชันมองเห็นได้เฉพาะตอนรันไทม์เท่านั้น และจะไม่ปรากฏก่อนหน้านั้น หมายความว่าไม่ได้เป็นส่วนหนึ่งของคำจำกัดความงานของ ECS
- แย่: ตรรกะในการดึงข้อมูลความลับถูกฝังซ้ำๆ กันในแอปพลิเคชันต่างๆ ดังนั้น แม้ว่า (หวังว่าจะ) เก็บรักษาความลับไว้ในการกำหนดค่าโครงสร้างพื้นฐานของคุณ แต่แต่ละแอปพลิเคชันจำเป็นต้องรู้ว่าจะดึงข้อมูลจากที่ไหนและอย่างไร สิ่งนี้ฝ่าฝืนหลักการ "DRY" และ "ความรับผิดชอบเดี่ยว"
ที่เก็บข้อมูลจำนวนมากบน Github ใช้แนวทางนี้ ตัวอย่างการดึงข้อมูลความลับในลักษณะนี้จาก AWS S3 มีอธิบายไว้ "ที่นี่" เช่นกัน
วิธีที่ 3 — ใช้แอตทริบิวต์ 'valueFrom' สำหรับคำจำกัดความงาน ECS
วิธีการนี้ทำให้ภาระในการรับความลับสำหรับคุณบน AWS และแอปพลิเคชันคอนเทนเนอร์สามารถคาดหวังได้ว่าตัวแปรสภาพแวดล้อมจะมีอยู่ก่อนที่แอปพลิเคชันจะทำงาน
- ดี: แอปพลิเคชันไม่สนใจวิธีการดึงข้อมูลความลับ — คาดว่าแอปพลิเคชันจะพร้อมใช้งานเป็นตัวแปรสภาพแวดล้อมในระหว่างรันไทม์
- ดี: รองรับทั้ง AWS SSM parameter Store และ AWS Systems Manager (ปัจจุบัน)
คำแนะนำของฉัน
วิธีที่ฉันอยากจะแนะนำคือใช้แอตทริบิวต์ 'valueFrom' เพื่อแทรกพารามิเตอร์ AWS SSM ที่เข้ารหัส KMS ลงในงานที่กำลังทำงานอยู่โดยตรง วิธีนี้จะทำให้ความลับ ไม่มีใครมองเห็นได้เมื่อเข้าสู่ระบบ AWS Console และไม่ได้รับการบันทึกเป็นข้อความธรรมดาทุกที่
การกำหนดเส้นทางที่คุณใช้สำหรับพารามิเตอร์ที่คุณเพิ่มลงใน AWS SSM parameter Store ให้เป็นมาตรฐานเป็นแนวคิดที่ดี เนื่องจากจะช่วยให้คุณจำกัดขอบเขตการเข้าถึงข้อมูลลับเหล่านี้ได้ วิธีที่คุณออกแบบโครงสร้างพื้นฐานจะเป็นตัวกำหนดรูปแบบเส้นทางที่คุณสามารถใช้ได้อย่างแน่นอน ไม่สำคัญว่าคุณจะตัดสินใจเลือกรูปแบบใด สิ่งสำคัญคือเพียงสร้างมาตรฐาน 'บางรูปแบบ' แทนที่จะอนุญาตให้แต่ละบริการระบุรูปแบบเส้นทางของตนเอง โดยรวมแล้ว นี่คือ 3 ขั้นตอนที่ฉันแนะนำ:
ขั้นตอนที่ 1: ตัดสินใจรูปแบบเส้นทางของร้านค้าพารามิเตอร์ AWS SSM ของคุณ ตัวอย่างได้แก่:
- /{สภาพแวดล้อม}/{บริการ}/DATABASE_PASSWORD
- /{บริการ}/{สภาพแวดล้อม}.DATABASE_PASSWORD
ขั้นตอนที่ 2: เพิ่มคู่ค่าคีย์ของคุณไปยัง AWS SSM parameter Store และใช้คีย์ KMS เพื่อเข้ารหัส
ขั้นตอนที่ 3: ใช้แอตทริบิวต์ 'secrets/valueFrom' เพื่อแทรกพารามิเตอร์ AWS SSM ลงในงานที่กำลังทำงานอยู่โดยตรง
และนี่คือการกำหนดค่า Terraform ที่จะทำสิ่งนี้ ไฟล์เหล่านี้มีเพียงส่วนคำสั่งที่จำเป็นสำหรับความลับ คุณยังคงต้องกรอกรายละเอียดที่เหลือเพื่อสร้างงาน ECS จริงๆ
ไฟล์เทมเพลต:
หมายเหตุ: หากคุณใช้ 'ความลับ/ค่าจาก' ในคำจำกัดความงาน ECS ของคุณ คุณต้องให้ 'serviceRoleArn' ด้วย ซึ่งมีสิทธิ์ในการอ่านพารามิเตอร์ SSM ที่จำเป็นสำหรับขอบเขตนั้น
การอ่านเพิ่มเติม
- เอกสาร AWS Amazon ECS » คู่มือนักพัฒนา » คำจำกัดความของงาน Amazon ECS » การระบุข้อมูลที่ละเอียดอ่อน»
- เอกสาร AWS Amazon ECS » คู่มือนักพัฒนา » คำจำกัดความงาน Amazon ECS » พารามิเตอร์คำจำกัดความงาน»
- การจัดการความลับสำหรับแอปพลิเคชัน Amazon ECS โดยใช้ที่เก็บพารามิเตอร์และบทบาท IAM สำหรับงาน
- วิธีจัดการความลับสำหรับแอปพลิเคชันที่ใช้บริการ Amazon EC2 Container โดยใช้ Amazon S3 และ Docker
- การจัดการความลับภายใน AWS ECS
- ความลับของ ECS ถูกต้อง
ติดตามเราบน Twitter🐦และ Facebook👥และเข้าร่วม กลุ่ม Facebook ของเราnar.
หากต้องการเข้าร่วมชุมชน Slack ของเรา🙋️ และอ่านหัวข้อ Faun รายสัปดาห์ของเรา🗞️คลิกที่นี่⬇
