การส่งผ่านความลับไปยังคอนเทนเนอร์นักเทียบท่า


26

ฉันมีภาพนักเทียบท่าฐานซึ่งใช้เรียกใช้ซอฟต์แวร์วิเคราะห์ภาพ สำหรับแต่ละคอนเทนเนอร์ที่สร้างจากอิมเมจมีชุดของการตั้งค่าคอนฟิเกอเรชันซึ่งบางส่วนเป็นความลับ (คีย์เข้ารหัสข้อมูลลูกค้า ฯลฯ ) ที่ซอฟต์แวร์ใช้เพื่อวิเคราะห์และแจกจ่ายอิมเมจที่ประมวลผล ฉันจะส่งต่อความลับเหล่านี้ไปยังคอนเทนเนอร์ได้อย่างไร


Hashicorp vault
030

คำตอบ:


23

คุณมี 3 วิธีในการรับความลับของแอพภายในคอนเทนเนอร์นักเทียบท่า 2 ตัวแรกเกี่ยวข้องกับการกำหนดค่านักเทียบท่า อันสุดท้ายคือให้แอพของคุณดึงความลับโดยตรงจากที่เก็บความลับ

1 - ตัวแปรสภาวะแวดล้อม

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

2 - วอลุ่มที่เมาท์

คุณอาจมีความลับของคุณทั้งหมดที่อยู่ในแฟ้มการกำหนดค่า / ความลับโดยเฉพาะอย่างยิ่งจากนั้นกำหนดว่าอินสแตนซ์ของคุณเป็นที่ติดตั้งไดรฟ์

3 - ดึงข้อมูลจากที่เก็บความลับ

ดังที่ @ 030 กล่าวไว้คุณสามารถใช้ Hashicorp Vault (หรือ "Amazon Secrets Manager" หรือบริการอื่น ๆ เช่นนั้น)
แอพของคุณหรือแอป sidecar สามารถดึงความลับที่ต้องการได้โดยตรงโดยไม่ต้องจัดการกับการกำหนดค่าใด ๆ บนคอนเทนเนอร์ Docker วิธีนี้จะช่วยให้คุณใช้ความลับที่สร้างขึ้นแบบไดนามิก (เป็นคุณสมบัติที่น่าสนใจมากของระบบดังกล่าว) และไม่ต้องกังวลเกี่ยวกับความลับที่สามารถดูได้จากระบบไฟล์หรือจากการตรวจสอบตัวแปร env ของคอนเทนเนอร์นักเทียบท่า

ความเห็นส่วนตัว

ฉันเชื่อว่าตัวแปร env เป็นวิธีที่จะไป จัดการได้ง่ายกว่าและคุณยังสามารถดึงข้อมูลจากที่เก็บความลับอย่าง Hashicorp Vault ได้หากคุณมีระบบ CI build ให้คุณดึงความลับระหว่างการสร้างและตั้งค่าเมื่อคุณปรับใช้ คุณจะได้รับสิ่งที่ดีที่สุดทั้งสองโลกและประโยชน์เพิ่มเติมของนักพัฒนาของคุณโดยไม่จำเป็นต้องเขียนรหัสแอปพลิเคชันเพื่อดึงความลับ ผู้พัฒนาระบบควรมุ่งเน้นที่การใช้งานรหัสของพวกเขาและไม่เกี่ยวข้องกับงานของผู้ดูแลระบบเช่นการดึงรหัสผ่าน

รหัสแอปพลิเคชันของคุณควรเน้นไปที่ฟังก์ชั่นแอปของตัวเองและไม่เกี่ยวข้องกับงานแบ็กเอนด์เช่นการดึงรหัสผ่าน เช่นเดียวกับสถานะแอพ 12 Factor

แก้ไข:เปลี่ยนประโยคสุดท้ายเพื่อลบนัยของ Developer vs SysAdmin silo-ing งานควรแยกออกจากมุมมองโค้ด แต่ DevOps นั้นเกี่ยวกับบุคคลเดียวกันที่ทำให้ทั้งสองอยู่ในใจและไม่ถูก จำกัด

ความเห็นส่วนตัว (อัพเดต)

ความคิดเห็นที่ยอดเยี่ยมของ Per @ Dirk (การส่งความลับไปยังคอนเทนเนอร์ Docker ) มีข้อโต้แย้งที่แข็งแกร่งมากที่จะให้ความสำคัญกับการจัดเก็บความลับเหนือ vars ENV เนื่องจากไม่ต้องการรั่วไหล


2
สิ่งนี้ส่งเสริมไซโล DevOps กำลังทำสิ่งต่าง ๆ ร่วมกันแทนที่จะขว้างสิ่งของข้ามกำแพง
030

2
รหัสควรจะเป็น silo'd จากส่วนประกอบโครงสร้างพื้นฐาน ผู้ใช้จริงสามารถกำหนดรหัสได้ทั้งระบบโครงสร้างพื้นฐานอัตโนมัติและรหัสแอพพื้นฐาน แต่ควรแยกงานเอง ฉันเห็นประโยคสุดท้ายของคำตอบเดิมของฉันคือปิดเสียง devs ผู้คน นั่นคือความผิดพลาด ฉันจะแก้ไขให้ชัดเจนยิ่งขึ้น
BoomShadow

7
การใส่ความลับลงในตัวแปรสภาพแวดล้อมมีความเป็นไปได้ที่หลากหลายสำหรับการรั่วไหล ตัวอย่างเล็ก ๆ น้อย ๆ : ทุกคนที่สามารถเข้าถึง Docker daemon บนเครื่องที่รันคอนเทนเนอร์สามารถเห็นพวกเขาโดยใช้คำสั่งinspectหรือ execตัวแปรสภาพแวดล้อมมักจะถูกเทไปยังstdoutหรือเข้าสู่ logfiles เมื่อทำงานในโหมดดีบั๊ก กระบวนการลูกที่เกิดใหม่ทั้งหมดสามารถอ่านและเปิดเผยสิ่งที่อาจไม่สามารถควบคุมได้ ข้อมูลเพิ่มเติมเช่นที่นี่: diogomonica.com/2017/03/27/…
Dirk

1
ฉันยังต่อสู้กับคำถามนี้ สิ่งที่ฉันไม่เข้าใจคือแม้ว่าคุณจะใช้ข้อมูลประจำตัวห้องนิรภัยเพื่อรักษาความลับของคุณคุณยังต้องตรวจสอบสิทธิ์เพื่อเข้าใช้ห้องนิรภัยนั้นและนั่นอาจต้องใช้ความลับบางอย่าง ข้อกังวลเดียวกันนี้ใช้กับการใช้ไฟล์ KeyStore ที่ป้องกันด้วยรหัสผ่าน เรามักจะติดกับผ่านอย่างน้อย "ข้อมูลเมตา" ในสภาพแวดล้อมหรือไม่
Wheezil

1
@wheezil ข้อมูลเมตาจะปลอดภัยกว่าข้อมูลประจำตัวหลายอย่างโดยง่าย คุณสามารถหมุนข้อมูลรับรองเมตาบ่อยครั้งและอัตโนมัติ ข้อมูลรับรองเมตาสามารถไปที่ vault ที่อยู่บนโฮสต์ที่ปลอดภัยและสามารถมีสิ่งต่าง ๆ เช่นรายการที่อนุญาตพิเศษ IP เพื่อให้ยอมรับเฉพาะการเชื่อมต่อจากเครือข่ายย่อยที่ใช้งานจริงของคุณ คุณยังสามารถมั่นใจได้ว่าห้องนิรภัยใช้การเข้ารหัสที่ส่วนที่เหลือและการเข้ารหัสในการบินและ tsl ร่วมกันและการปักหมุดใบรับรองและแนวทางปฏิบัติที่ดีที่สุดอื่น ๆ ทั้งหมดที่ทำให้สิ่งต่าง ๆ ปลอดภัยยิ่งขึ้น
simbo1905

1

มีตัวเลือกอื่นโดยใช้ไปป์เท่านั้น:

docker run -d -i --name $n alpine sh -c 'read A; echo "[$A]"; exec some-server'
docker exec -i $n sh -c 'cat > /proc/1/fd/0' <<< _a_secret_

ขั้นแรกให้สร้างนักเทียบท่า daemon ด้วย-iคำสั่งread Aจะหยุดรออินพุตจาก/proc/1/fd/0นั้น จากนั้นรันคำสั่ง docker ที่สองอ่านความลับจาก stdin และเปลี่ยนเส้นทางไปยังกระบวนการแฮงค์ล่าสุด

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.