หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด

"ความลับที่ปิดผนึก" สำหรับ Kubernetes

สถานะการสร้าง

ปัญหา: "ฉันสามารถจัดการการกำหนดค่า K8 ทั้งหมดของฉันเป็น git ได้ ยกเว้นข้อมูลลับ"

วิธีแก้ไข: เข้ารหัสความลับของคุณลงใน SealedSecret ซึ่ง จัดเก็บได้อย่างปลอดภัย แม้จะอยู่ในที่เก็บข้อมูลสาธารณะก็ตาม SealedSecret สามารถถอดรหัสได้โดยคอนโทรลเลอร์ที่ทำงานในคลัสเตอร์เป้าหมายเท่านั้น และไม่มีใครอื่น (แม้แต่ผู้เขียนดั้งเดิม) สามารถรับความลับดั้งเดิมจาก SealedSecret ได้

  • ภาพรวม

    • SealedSecrets เป็นเทมเพลตสำหรับความลับ

    • กุญแจสาธารณะ / ใบรับรอง

    • ขอบเขต

  • การติดตั้ง

    • โฮมบรูว์

    • แมคพอร์ต

    • ลินุกซ์

    • การติดตั้งจากแหล่งที่มา

    • ปรับแต่ง

    • แผนภูมิหางเสือ

    • คอนโทรลเลอร์

    • คูบีซีล

  • อัพเกรด

  • การใช้งาน

    • การจัดการความลับที่มีอยู่

    • การแก้ไขความลับที่มีอยู่

    • อัปเดตความลับที่มีอยู่

    • โหมด Raw (ทดลอง)

    • ตรวจสอบความลับที่ปิดผนึก

  • การหมุนความลับ

    • การต่ออายุกุญแจปิดผนึก

    • การหมุนเวียนความลับของผู้ใช้

    • การต่ออายุคีย์ล่วงหน้า

    • ความเข้าใจผิดที่พบบ่อยเกี่ยวกับการต่ออายุคีย์

    • การจัดการคีย์ด้วยตนเอง (ขั้นสูง)

    • การเข้ารหัสซ้ำ (ขั้นสูง)

  • รายละเอียด (ขั้นสูง)

    • การเข้ารหัสลับ

  • กำลังพัฒนา

  • คำถามที่พบบ่อย

    • คุณจะยังสามารถถอดรหัสได้หรือไม่หากคุณไม่สามารถเข้าถึงคลัสเตอร์ของคุณได้อีกต่อไป?

    • ฉันจะสำรองข้อมูล SealedSecrets ของฉันได้อย่างไร

    • ฉันสามารถถอดรหัสความลับของฉันแบบออฟไลน์ด้วยคีย์สำรองได้หรือไม่

    • kubeseal มีแฟล็กใดบ้าง

    • ฉันจะอัปเดตบางส่วนของไฟล์ JSON/YAML/TOML/.. ที่เข้ารหัสด้วยความลับที่ปิดผนึกได้อย่างไร

    • ฉันสามารถนำใบรับรองของตัวเอง (ที่สร้างไว้ล่วงหน้า) มาเองได้หรือไม่

    • จะใช้ kubeseal ได้อย่างไรหากคอนโทรลเลอร์ไม่ได้ทำงานภายในเนมสเปซ kube-system

    • จะตรวจสอบภาพได้อย่างไร?

    • วิธีใช้คอนโทรลเลอร์ตัวเดียวสำหรับชุดย่อยของเนมสเปซ

    • ฉันสามารถกำหนดค่าการลองปิดผนึกคอนโทรลเลอร์อีกครั้งได้หรือไม่

  • ชุมชน

    • โครงการที่เกี่ยวข้อง

ภาพรวม

ความลับที่ปิดผนึกประกอบด้วยสองส่วน:

  • ตัวควบคุม / ผู้ปฏิบัติงานฝั่งคลัสเตอร์

  • ยูทิลิตี้ฝั่งไคลเอ็นต์: kubeseal

ยูทิลิตี้ kubeseal ใช้การเข้ารหัสแบบอสมมาตรเพื่อเข้ารหัสความลับที่มีเพียงผู้ควบคุมเท่านั้นที่สามารถถอดรหัสได้

ข้อมูลลับที่เข้ารหัสเหล่านี้ได้รับการเข้ารหัสในทรัพยากร SealedSecret ซึ่งคุณสามารถดูเป็นสูตรสำหรับการสร้างข้อมูลลับได้ นี่คือลักษณะที่ปรากฏ:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: ชื่อ: mysecret เนมสเปซ: mynamespacespec: encryptedData: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

เมื่อเปิดผนึกแล้วจะทำให้เกิดความลับเทียบเท่ากับสิ่งนี้:

 apiVersion: v1kind: Secretmetadata: ชื่อ: mysecret เนมสเปซ: mynamespacedata: foo: YmFy # <- base64 เข้ารหัส "บาร์"

ข้อมูลลับของ kubernetes ปกตินี้จะปรากฏในคลัสเตอร์หลังจากผ่านไปไม่กี่วินาที คุณสามารถใช้งานได้ เนื่องจากคุณจะใช้ข้อมูลลับใด ๆ ที่คุณสร้างขึ้นโดยตรง (เช่น อ้างอิงจาก Pod )

ข้ามไปที่ส่วนการติดตั้งเพื่อเริ่มต้นและใช้งาน

ส่วนการใช้งานจะสำรวจรายละเอียดเพิ่มเติมว่าคุณสร้างทรัพยากร SealedSecret อย่างไร

SealedSecrets เป็นเทมเพลตสำหรับความลับ

ตัวอย่างก่อนหน้านี้มุ่งเน้นไปที่รายการลับที่เข้ารหัสเท่านั้น แต่ความสัมพันธ์ระหว่างทรัพยากรแบบกำหนดเอง SealedSecret กับ Secret ที่เปิดเผยนั้นมีความคล้ายคลึงกันในหลายๆ ด้าน (แต่ไม่ใช่ทั้งหมด) กับ Deployment vs Pod ที่คุ้นเคย

โดยเฉพาะอย่างยิ่ง คำอธิบายประกอบและเลเบลของรีซอร์ส SealedSecret จะไม่เหมือนกับคำอธิบายประกอบของ Secret ที่สร้างขึ้น

ในการจับภาพความแตกต่างนี้ ออบเจ็กต์ SealedSecret มีส่วน template ที่เข้ารหัสฟิลด์ทั้งหมดที่คุณต้องการให้คอนโทรลเลอร์ใส่ใน Secret ที่ไม่ได้ปิดผนึก

ไลบรารีฟังก์ชัน Sprig พร้อมใช้งานเพิ่มเติมจากฟังก์ชัน Go Text Template เริ่มต้น

บล็อก metadata จะถูกคัดลอกตามที่เป็นอยู่ (ฟิลด์ ownerReference จะได้รับการอัปเดตเว้นแต่จะปิดใช้งาน)

ช่องข้อมูลลับอื่นๆ จะได้รับการจัดการเป็นรายบุคคล type และฟิลด์ immutable จะถูกคัดลอก และฟิลด์ data สามารถใช้เพื่อสร้างเทมเพลตค่าที่ซับซ้อนบน Secret ได้ ฟิลด์อื่นๆ ทั้งหมดจะถูกละเว้นในขณะนี้

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: ชื่อ: mysecret namespace: mynamespace คำอธิบายประกอบ: "kubectl.kubernetes.io/last-applied-configuration": ....spec: encryptedData: .dockerconfigjson: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.... . เทมเพลต: ประเภท: kubernetes.io/dockerconfigjson ไม่เปลี่ยนรูป: true # นี่คือตัวอย่างของป้ายกำกับและคำอธิบายประกอบที่จะถูกเพิ่มลงในข้อมูลเมตาที่เป็นความลับของเอาต์พุต: ป้ายกำกับ: "jenkins.io/credentials-type": ชื่อผู้ใช้คำอธิบายประกอบรหัสผ่าน: "jenkins. io/credentials-description": ข้อมูลรับรองจาก Kubernetes

คอนโทรลเลอร์จะเปิดผนึกสิ่งนั้นเป็นสิ่งที่ชอบ:

 apiVersion: v1kind: Secretmetadata: ชื่อ: mysecret เนมสเปซ: mynamespace ป้ายกำกับ: "jenkins.io/credentials-type": ชื่อผู้ใช้คำอธิบายประกอบรหัสผ่าน: "jenkins.io/credentials-description": ข้อมูลรับรองจากเจ้าของ Kubernetes การอ้างอิง:
  - apiVersion: bitnami.com/v1alpha1 ตัวควบคุม: ชนิดจริง: ชื่อ SealedSecret: mysecret uid: 5caff6a0-c9ac-11e9-881e-42010aac003etype: kubernetes.io/dockerconfigjsonimmutable: truedata: .dockerconfigjson: ewogICJjcmVk...

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

กุญแจสาธารณะ / ใบรับรอง

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

kubeseal จะดึงใบรับรองจากตัวควบคุมขณะรันไทม์ (ต้องมีการเข้าถึงเซิร์ฟเวอร์ Kubernetes API อย่างปลอดภัย) ซึ่งสะดวกสำหรับการใช้งานเชิงโต้ตอบ แต่จะเปราะบางเมื่อผู้ใช้มีคลัสเตอร์ที่มีการกำหนดค่าพิเศษ เช่น คลัสเตอร์ GKE ส่วนตัวที่มีไฟร์วอลล์อยู่ระหว่าง ระนาบควบคุมและโหนด

ขั้นตอนการทำงานทางเลือกคือการจัดเก็บใบรับรองไว้ที่ใดที่หนึ่ง (เช่น ดิสก์ในเครื่อง) ด้วย kubeseal --fetch-cert >mycert.pem และใช้แบบออฟไลน์กับ kubeseal --cert mycert.pem ใบรับรองยังถูกพิมพ์ไปยังบันทึกของตัวควบคุมเมื่อเริ่มต้นระบบด้วย

เนื่องจากใบรับรอง v0.9.x จะได้รับการต่ออายุอัตโนมัติทุกๆ 30 วัน แนวปฏิบัติที่ดีที่คุณและทีมของคุณอัปเดตใบรับรองออฟไลน์ของคุณเป็นระยะ เพื่อช่วยคุณในเรื่องนั้น เนื่องจาก v0.9.2 kubeseal ก็ยอมรับ URL เช่นกัน คุณสามารถตั้งค่าระบบอัตโนมัติภายในเพื่อเผยแพร่ใบรับรองในที่ที่คุณเชื่อถือได้

 kubeseal --cert https://your.intranet.company.com/sealed-secrets/your-cluster.cert

นอกจากนี้ยังรู้จัก SEALED_SECRETS_CERT env var (เคล็ดลับสำหรับมือโปร: ดู direnv ด้วย)

หมายเหตุ : เรากำลังดำเนินการจัดหากลไกการจัดการคีย์ที่จะถ่ายโอนการเข้ารหัสไปยังโมดูลที่ใช้ HSM หรือโซลูชันการเข้ารหัสบนคลาวด์ที่ได้รับการจัดการ เช่น KMS

ขอบเขต

SealedSecrets มาจาก POV ของผู้ใช้ปลายทางว่าเป็นอุปกรณ์ "เขียนเท่านั้น"

แนวคิดก็คือว่า SealedSecret สามารถถอดรหัสได้โดยคอนโทรลเลอร์ที่ทำงานในคลัสเตอร์เป้าหมายเท่านั้น และไม่มีใครอื่น (แม้แต่ผู้เขียนดั้งเดิม) สามารถรับความลับดั้งเดิมจาก SealedSecret ได้

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

มีหลายวิธีในการกำหนดค่า RBAC บน k8s แต่เป็นเรื่องปกติที่จะห้ามผู้ใช้ที่มีสิทธิ์ต่ำอ่านข้อมูลลับ เป็นเรื่องปกติที่จะให้ผู้ใช้หนึ่งเนมสเปซมีสิทธิ์ที่สูงกว่า ซึ่งจะอนุญาตให้พวกเขาสร้างและอ่านความลับ (และ/หรือสร้างการใช้งานที่สามารถอ้างอิงความลับเหล่านั้นได้)

ทรัพยากร SealedSecret ที่เข้ารหัสได้รับการออกแบบมาให้ปลอดภัยในการดูโดยไม่ได้รับความรู้ใดๆ เกี่ยวกับความลับที่ปกปิดไว้ นี่หมายความว่าเราไม่สามารถอนุญาตให้ผู้ใช้อ่าน SealedSecret สำหรับเนมสเปซที่พวกเขาไม่สามารถเข้าถึงได้ และเพียงส่งสำเนาของมันในเนมสเปซที่พวกเขาสามารถอ่านความลับได้

ความลับที่ปิดผนึกจะทำงาน เหมือนกับว่า แต่ละเนมสเปซมีคีย์การเข้ารหัสอิสระของตัวเอง ดังนั้นเมื่อคุณปิดผนึกความลับสำหรับเนมสเปซแล้ว มันจะไม่สามารถย้ายไปยังเนมสเปซอื่นและถอดรหัสที่นั่นได้

ในทางเทคนิคแล้ว เราไม่ได้ใช้คีย์ส่วนตัวที่เป็นอิสระสำหรับแต่ละเนมสเปซ แต่เรา รวม ชื่อเนมสเปซในระหว่างกระบวนการเข้ารหัสแทน เพื่อให้ได้ผลลัพธ์เดียวกันอย่างมีประสิทธิภาพ

นอกจากนี้ เนมสเปซไม่ใช่ระดับเดียวที่การกำหนดค่า RBAC สามารถตัดสินใจได้ว่าใครสามารถดูข้อมูลลับใดได้บ้าง ในความเป็นจริง มีความเป็นไปได้ที่ผู้ใช้จะสามารถเข้าถึงข้อมูลลับที่เรียกว่า foo ในเนมสเปซที่กำหนด แต่จะเข้าถึงข้อมูลลับอื่นในเนมสเปซเดียวกันไม่ได้ ดังนั้นตามค่าเริ่มต้น เราไม่สามารถอนุญาตให้ผู้ใช้เปลี่ยนชื่อทรัพยากร SealedSecret ได้อย่างอิสระ มิฉะนั้นผู้ใช้ที่ประสงค์ร้ายจะสามารถถอดรหัส SealedSecret ใดๆ สำหรับเนมสเปซนั้นได้ เพียงแค่เปลี่ยนชื่อเพื่อเขียนทับผู้ใช้ที่เป็นความลับรายเดียวที่สามารถเข้าถึงได้ เราใช้กลไกเดียวกับที่ใช้ในการรวมเนมสเปซในคีย์เข้ารหัสเพื่อรวมชื่อลับด้วย

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

เหล่านี้คือขอบเขตที่เป็นไปได้:

  • strict (ค่าเริ่มต้น): ข้อมูลลับจะต้องปิดผนึกด้วย ชื่อ และ เนมสเปซ ที่เหมือนกันทุกประการ คุณลักษณะเหล่านี้กลายเป็น ส่วนหนึ่งของข้อมูลที่เข้ารหัส ดังนั้นการเปลี่ยนชื่อและ/หรือเนมสเปซจะนำไปสู่ ​​"ข้อผิดพลาดในการถอดรหัส"

  • namespace-wide : คุณสามารถ เปลี่ยนชื่อ ความลับที่ปิดผนึกภายในเนมสเปซที่กำหนดได้อย่างอิสระ

  • cluster-wide : ข้อมูลลับสามารถถูกเปิดผนึกในเนมสเปซ ใดก็ได้ และสามารถตั้งชื่อ ใดก็ได้

ตรงกันข้ามกับข้อจำกัดของ name และ namespace รายการ ลับ (เช่น คีย์อ็อบเจ็กต์ JSON เช่น spec.encryptedData.my-key ) สามารถเปลี่ยนชื่อได้ตามต้องการโดยไม่สูญเสียความสามารถในการถอดรหัสความลับที่ปิดผนึก

ขอบเขตถูกเลือกด้วยแฟล็ก --scope :

 kubeseal --scope ทั่วทั้งคลัสเตอร์ sealed-secret.json

นอกจากนี้ยังสามารถขอขอบเขตผ่านคำอธิบายประกอบในข้อมูลลับอินพุตที่คุณส่งไปที่ kubeseal :

  • sealedsecrets.bitnami.com/namespace-wide: "true" -> สำหรับ namespace-wide

  • sealedsecrets.bitnami.com/cluster-wide: "true" -> สำหรับ cluster-wide

การไม่มีคำอธิบายประกอบใดๆ ดังกล่าวหมายถึงโหมด strict หากตั้งค่าทั้งสองรายการไว้ cluster-wide จะมีความสำคัญเหนือกว่า

หมายเหตุ: รุ่นถัดไปจะรวมสิ่งนี้ไว้ในคำอธิบายประกอบปิดผนึกเดียว sealedsecrets.bitnami.com/scope .bitnami.com/scope

การติดตั้ง

ดู https://github.com/bitnami-labs/sealed-secrets/releases สำหรับรุ่นล่าสุดและคำแนะนำในการติดตั้งโดยละเอียด

หมายเหตุและคำแนะนำเฉพาะแพลตฟอร์มคลาวด์:

  • จีเคอี

คอนโทรลเลอร์

เมื่อคุณปรับใช้ไฟล์ Manifest มันจะสร้างทรัพยากร SealedSecret และติดตั้งคอนโทรลเลอร์ลงในเนมสเปซ kube-system สร้างบัญชีบริการและบทบาท RBAC ที่จำเป็น

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

ปรับแต่ง

กลไกการติดตั้งรายการคอนโทรลเลอร์อย่างเป็นทางการเป็นเพียงไฟล์ YAML

ในบางกรณี คุณอาจจำเป็นต้องใช้การปรับแต่งของคุณเอง เช่น ตั้งค่าเนมสเปซที่กำหนดเอง หรือตั้งค่าตัวแปร env บางตัว

kubectl มีการสนับสนุนแบบเนทิฟสำหรับสิ่งนั้น โปรดดูที่ kustomize

แผนภูมิหางเสือ

ขณะนี้แผนภูมิหางเสือ Sealed Secrets ได้รับการสนับสนุนอย่างเป็นทางการและโฮสต์ใน repo GitHub นี้

 helm repo เพิ่มความลับที่ปิดผนึก https://bitnami-labs.github.io/sealed-secrets

หมายเหตุ: รูปแบบการกำหนดเวอร์ชันของแผนภูมิหางเสือแตกต่างจากโครงร่างการกำหนดเวอร์ชันของโครงการความลับที่ปิดผนึกเอง

เดิมทีแผนภูมิหางเสือได้รับการดูแลโดยชุมชน และเวอร์ชันแรกใช้เวอร์ชันหลักเป็น 1 ในขณะที่โครงการปิดผนึกความลับนั้นยังคงอยู่ที่หลัก 0 ซึ่งถือว่าใช้ได้เพราะเวอร์ชันของแผนภูมิหางเสือนั้นไม่ได้หมายความว่าจะต้องเป็นเวอร์ชันเสมอไป ของตัวแอปเอง อย่างไรก็ตาม สิ่งนี้ทำให้เกิดความสับสน ดังนั้นกฎการกำหนดเวอร์ชันปัจจุบันของเราคือ:

  1. รูปแบบเวอร์ชันของคอนโทรลเลอร์ SealedSecret : 0.XY

  2. รูปแบบแผนภูมิเวอร์ชันหางเสือ: 1.XY-rZ

จึงมีการแก้ไขแผนภูมิหางเสือได้หลายครั้ง โดยมีการแก้ไขที่ใช้กับแผนภูมิหางเสือเท่านั้น โดยไม่ส่งผลกระทบต่อการแสดง YAML แบบคงที่หรืออิมเมจของตัวควบคุม

หมายเหตุ: readme แผนภูมิหางเสือยังคงมีประกาศการเลิกใช้งาน แต่ไม่ได้สะท้อนถึงความเป็นจริงอีกต่อไป และจะถูกลบออกในรุ่นถัดไป

หมายเหตุ: ตามค่าเริ่มต้น แผนภูมิหางเสือจะติดตั้งคอนโทรลเลอร์ด้วยชื่อ sealed-secrets ในขณะที่อินเทอร์เฟซบรรทัดคำสั่ง kubeseal (CLI) พยายามเข้าถึงคอนโทรลเลอร์ด้วยชื่อ sealed-secrets-controller คุณสามารถส่ง --controller-name ไปยัง CLI ได้อย่างชัดเจน:

 kubeseal -- ชื่อคอนโทรลเลอร์ปิดผนึกความลับ

หรือคุณสามารถตั้ง fullnameOverride เมื่อติดตั้งแผนภูมิเพื่อแทนที่ชื่อ โปรดทราบว่า kubeseal จะถือว่ามีการติดตั้งคอนโทรลเลอร์ภายในเนมสเปซ kube-system ตามค่าเริ่มต้น ดังนั้น หากคุณต้องการใช้ kubeseal CLI โดยไม่ต้องส่งชื่อคอนโทรลเลอร์และเนมสเปซที่ต้องการ คุณควรติดตั้ง Helm Chart ดังนี้:

 หางเสือติดตั้ง SEALED-Secrets -n kube-system --set-string fullnameOverride=sealed-secrets-controller ปิดผนึกความลับ / ความลับที่ปิดผนึก
แผนภูมิพวงมาลัยในสภาพแวดล้อมที่จำกัด

ในบางบริษัท คุณอาจได้รับสิทธิ์เข้าถึงเพียงเนมสเปซเดียว ไม่ใช่คลัสเตอร์ทั้งหมด

สภาพแวดล้อมที่เข้มงวดที่สุดประการหนึ่งที่คุณสามารถพบได้คือ:

  • มีการจัดสรร namespace ให้กับคุณด้วย service account บางส่วน

  • คุณไม่มีสิทธิ์เข้าถึงส่วนที่เหลือของคลัสเตอร์ แม้แต่ CRD ของคลัสเตอร์

  • คุณอาจไม่สามารถสร้างบัญชีบริการหรือบทบาทเพิ่มเติมในเนมสเปซของคุณได้

  • คุณจะต้องรวมขีดจำกัดทรัพยากรในการปรับใช้ทั้งหมดของคุณ

แม้จะมีข้อจำกัดเหล่านี้ คุณยังคงสามารถติดตั้ง Helm Chart ที่ปิดผนึกไว้ได้ แต่มีข้อกำหนดเบื้องต้นเพียงข้อเดียวเท่านั้น:

  • คลัสเตอร์ต้องมี CRDs ความลับที่ปิดผนึกไว้อยู่แล้ว

เมื่อผู้ดูแลระบบของคุณติดตั้ง CRD แล้ว หากยังไม่มี คุณสามารถติดตั้งแผนภูมิได้โดยเตรียมไฟล์กำหนดค่า YAML ดังนี้:

 บัญชีบริการ:
  สร้าง: เท็จ
  ชื่อ: {บัญชีบริการที่จัดสรร}
แบค:
  สร้าง: เท็จ
  คลัสเตอร์บทบาท: ทรัพยากรที่ผิดพลาด:
  ขีดจำกัด:
    ซีพียู: 150m
    หน่วยความจำ: 256Mi

โปรดทราบว่า:

  • ไม่มีการสร้างบัญชีบริการ แต่จะใช้บัญชีที่จัดสรรให้กับคุณแทน

    • {allocated-service-account} คือชื่อของ service account ที่คุณได้รับการจัดสรรบนคลัสเตอร์

  • ไม่มีการสร้างบทบาท RBAC ทั้งในเนมสเปซหรือคลัสเตอร์

  • ต้องระบุขีดจำกัดทรัพยากร

    • ขีดจำกัดคือตัวอย่างที่ควรได้ผล แต่คุณอาจต้องการตรวจสอบในการตั้งค่าเฉพาะของคุณ

เมื่อไฟล์นั้นพร้อม หากคุณตั้งชื่อเป็น config.yaml ตอนนี้คุณสามารถติดตั้ง Helm Chart ที่ปิดผนึกไว้ได้ดังนี้:

 หางเสือติดตั้ง SEALED-Secrets -n {allocated-namespace} SEALED-Secrets/sealed-secrets --skip-crds -f config.yaml

โดยที่ {allocated-namespace} คือชื่อของ namespace ที่คุณได้รับการจัดสรรในคลัสเตอร์

คูบีซีล

โฮมบรูว์

ไคลเอนต์ kubeseal นั้นมีอยู่ใน homebrew ด้วย:

 ชงติดตั้ง kubeseal

แมคพอร์ต

ไคลเอ็นต์ kubeseal ยังมีให้บริการบน MacPorts:

 พอร์ตติดตั้ง kubeseal

Nixpkgs

ไคลเอนต์ kubeseal นั้นมีอยู่ใน Nixpkgs ด้วย: ( การปฏิเสธความรับผิด : ไม่ได้รับการดูแลโดย bitnami-labs)

 ห้าม-env -iA nixpkgs.kubeseal

ลินุกซ์

ไคลเอ็นต์ kubeseal สามารถติดตั้งบน Linux ได้โดยใช้คำสั่งด้านล่าง:

 KUBESEAL_VERSION='' # ตั้งค่านี้เป็น KUBESEAL_VERSION='0.23.0'curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION:?} /kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz"tar -xvzf kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz kubeseal
sudo ติดตั้ง -m 755 kubeseal /usr/local/bin/kubeseal

หากคุณติดตั้ง curl และ jq บนเครื่องของคุณ คุณสามารถรับเวอร์ชันแบบไดนามิกได้ด้วยวิธีนี้ สิ่งนี้มีประโยชน์สำหรับสภาพแวดล้อมที่ใช้ในระบบอัตโนมัติและอื่นๆ 

# Fetch the latest sealed-secrets version using GitHub API
KUBESEAL_VERSION=$(curl -s https://api.github.com/repos/bitnami-labs/sealed-secrets/tags | jq -r '.[0].name' | cut -c 2-)

# Check if the version was fetched successfully
if [ -z "$KUBESEAL_VERSION" ]; then
    echo "Failed to fetch the latest KUBESEAL_VERSION"
    exit 1
fi

curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION}/kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz"
tar -xvzf kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

โดยที่ KUBESEAL_VERSION คือแท็กเวอร์ชันของ kubeseal release ที่คุณต้องการใช้ ตัวอย่างเช่น: v0.18.0

การติดตั้งจากแหล่งที่มา

หากคุณต้องการเครื่องมือไคลเอ็นต์ล่าสุด สามารถติดตั้งลงใน $GOPATH/bin ด้วย:

 ไปติดตั้ง github.com/bitnami-labs/sealed-secrets/cmd/kubeseal@main

คุณสามารถระบุแท็ก release หรือคอมมิต SHA แทน main ได้

คำสั่ง go install จะวางไบนารี kubeseal ไว้ที่ $GOPATH/bin :

 $(go env GOPATH)/bin/kubeseal

อัพเกรด

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

เวอร์ชันที่รองรับ

ปัจจุบัน เฉพาะเวอร์ชันล่าสุดของ Sealed Secrets เท่านั้นที่ได้รับการสนับสนุนสำหรับสภาพแวดล้อมการใช้งานจริง

ความเข้ากันได้กับเวอร์ชัน Kubernetes

ตัวควบคุม Sealed Secrets รับประกันความเข้ากันได้กับ Kubernetes เวอร์ชันต่างๆ โดยอาศัย Kubernetes API ที่เสถียร โดยทั่วไปแล้ว Kubernetes เวอร์ชันที่สูงกว่า 1.16 จะถือว่าเข้ากันได้ อย่างไรก็ตาม เราสนับสนุน Kubernetes เวอร์ชันที่แนะนำในปัจจุบันอย่างเป็นทางการ นอกจากนี้ เวอร์ชันที่สูงกว่า 1.24 ยังได้รับการตรวจสอบอย่างละเอียดผ่านกระบวนการ CI ของเราทุกครั้งที่มีการเผยแพร่

การใช้งาน

 # สร้างความลับที่เข้ารหัส json/yaml:# (หมายเหตุการใช้ `--dry-run` - นี่เป็นเพียงไฟล์ในเครื่อง!) echo -n bar | kubectl สร้างความลับทั่วไป mysecret --dry-run=client --from-file=foo=/dev/stdin -o json >mysecret.json# นี่คือบิตสำคัญ:kubeseal -f mysecret.json -w mysealedsecret.json# ณ จุดนี้ mysealedsecret.json สามารถอัปโหลดไปยัง Github ได้อย่างปลอดภัย # โพสต์บน Twitter ฯลฯ # ในที่สุด:kubectl create -f mysealedsecret.json# Profit!kubectl get secret mysecret

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

kubeseal อ่านเนมสเปซจากข้อมูลลับอินพุต ยอมรับอาร์กิวเมนต์ --namespace ที่ชัดเจน และใช้เนมสเปซเริ่มต้น kubectl (ตามลำดับนั้น) ป้ายกำกับ คำอธิบายประกอบ ฯลฯ บน Secret ดั้งเดิมจะถูกเก็บรักษาไว้ แต่จะไม่สะท้อนให้เห็นโดยอัตโนมัติใน SealedSecret

โดยการออกแบบ โครงการนี้ ไม่รับรองความถูกต้องของผู้ใช้ กล่าวอีกนัยหนึ่ง ทุกคน สามารถสร้าง SealedSecret ที่มี Secret ใดๆ ที่พวกเขาชอบได้ (โดยระบุเนมสเปซ/ชื่อที่ตรงกัน) ขึ้นอยู่กับเวิร์กโฟลว์การจัดการการกำหนดค่าที่มีอยู่ของคุณ กฎ RBAC ของคลัสเตอร์ ฯลฯ เพื่อให้แน่ใจว่าจะอัปโหลดเฉพาะ SealedSecret ที่ต้องการไปยังคลัสเตอร์เท่านั้น การเปลี่ยนแปลงเพียงอย่างเดียวจาก Kubernetes ที่มีอยู่คือตอนนี้ เนื้อหา ของ Secret ถูกซ่อนขณะอยู่นอกคลัสเตอร์

การจัดการความลับที่มีอยู่

หากคุณต้องการให้คอนโทรลเลอร์ Sealed Secrets จัดการ Secret ที่มีอยู่ คุณสามารถใส่คำอธิบายประกอบเกี่ยวกับ Secret ของคุณด้วย sealedsecrets.bitnami.com/managed: "true" Secret ที่มีอยู่จะถูกเขียนทับเมื่อเปิดผนึก SealedSecret ด้วยชื่อและเนมสเปซเดียวกัน และ SealedSecret จะเป็นเจ้าของ Secret (เพื่อที่ว่าเมื่อ SealedSecret ถูกลบ Secret ก็จะถูกลบด้วย)

การแก้ไขความลับที่มีอยู่

ใหม่ใน v0.23.0

มีกรณีการใช้งานบางกรณีที่คุณไม่ต้องการแทนที่ Secret ทั้งหมด แต่เพียงเพิ่มหรือแก้ไขคีย์บางคีย์จาก Secret ที่มีอยู่ สำหรับสิ่งนี้ คุณสามารถใส่คำอธิบายประกอบ Secret ของคุณด้วย sealedsecrets.bitnami.com/patch: "true" การใช้คำอธิบายประกอบนี้จะทำให้แน่ใจว่าคีย์ลับ ป้ายกำกับ และคำอธิบายประกอบใน Secret ที่ไม่ปรากฏใน SealedSecret จะไม่ถูกลบ และรายการที่มีอยู่ใน SealedSecret จะถูกเพิ่มลงใน Secret (คีย์ลับ ป้ายกำกับ และคำอธิบายประกอบที่มีอยู่ ทั้งใน Secret และ SealedSecret จะถูกแก้ไขโดย SealedSecret )

คำอธิบายประกอบนี้ไม่ได้ทำให้ SealedSecret เป็นเจ้าของ Secret คุณสามารถเพิ่มทั้ง patch และคำอธิบายประกอบ managed เพื่อให้ได้ลักษณะการแพตช์ในขณะที่ยังเป็นเจ้าของ Secret ด้วย

ปิดผนึกความลับซึ่งสามารถข้ามการอ้างอิงเจ้าของชุดได้

หากคุณต้องการให้ SealedSecret และ Secret มีความเป็นอิสระ ซึ่งหมายความว่าเมื่อคุณลบ SealedSecret Secret จะไม่หายไปด้วย คุณจะต้องใส่คำอธิบายประกอบให้กับ Secret นั้นด้วยคำอธิบายประกอบปิดผนึก sealedsecrets.bitnami.com/skip-set-owner-references: "true" ก่อนดำเนินการตามขั้นตอนการใช้งาน คุณยังอาจเพิ่ม sealedsecrets.bitnami.com/managed: "true" ลงใน Secret ของคุณ เพื่อให้ความลับของคุณจะได้รับการอัปเดตเมื่อมีการอัปเดต SealedSecret

อัปเดตความลับที่มีอยู่

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

คุณต้องดูแลการปิดผนึกรายการที่อัปเดตด้วยชื่อและเนมสเปซที่เข้ากันได้ (ดูหมายเหตุเกี่ยวกับขอบเขตด้านบน)

คุณสามารถใช้คำสั่ง --merge-into เพื่ออัปเดตความลับที่ปิดผนึกที่มีอยู่ หากคุณไม่ต้องการคัดลอกและวาง:

 echo -n บาร์ | kubectl สร้างความลับ mysecret ทั่วไป --dry-run=client --from-file=foo=/dev/stdin -o json  | kubeseal > mysealedsecret.jsonecho -n baz | kubectl สร้างความลับ mysecret ทั่วไป --dry-run=client --from-file=bar=/dev/stdin -o json  | kubeseal -- ผสานเข้ากับ mysealedsecret.json

โหมด Raw (ทดลอง)

การสร้างความลับชั่วคราวด้วยคำสั่ง kubectl เพียงเพื่อทิ้งมันไปเมื่อส่งไปที่ kubeseal อาจทำให้ผู้ใช้ได้รับประสบการณ์ที่ไม่เป็นมิตรนัก เรากำลังดำเนินการยกเครื่องประสบการณ์ CLI ในระหว่างนี้ เราขอเสนอโหมดทางเลือกที่ kubeseal ใส่ใจเฉพาะการเข้ารหัสค่าเป็น stdout และเป็นความรับผิดชอบของคุณที่จะต้องใส่ไว้ในทรัพยากร SealedSecret (ไม่ต่างจากทรัพยากร k8s อื่นๆ)

นอกจากนี้ยังสามารถใช้เป็นแบบเอกสารสำเร็จรูปสำหรับการรวมตัวแก้ไข/IDE ได้ด้วย

ข้อเสียคือคุณต้องระมัดระวังเพื่อให้สอดคล้องกับขอบเขตการปิดผนึก เนมสเปซ และชื่อ

ดูขอบเขต

ขอบเขต strict (ค่าเริ่มต้น):

 $ echo -n foo | kubeseal --raw -- แถบเนมสเปซ -- ชื่อ mysecretAgBChHUWLMx...

ขอบเขต namespace-wide :

 $ echo -n foo | kubeseal --raw -- แถบเนมสเปซ -- ขอบเขตเนมสเปซ-wideAgAbbFNkM54 ...

รวมคำอธิบายประกอบ sealedsecrets.bitnami.com/namespace-wide ใน SealedSecret

 ข้อมูลเมตา: คำอธิบายประกอบ: Sealedsecrets.bitnami.com/namespace-wide: "จริง"

ขอบเขต cluster-wide :

 $ echo -n foo | kubeseal --raw --ขอบเขตคลัสเตอร์-wideAgAjLKpIYV+...

รวมคำอธิบายประกอบ sealedsecrets.bitnami.com/cluster-wide ใน SealedSecret

 ข้อมูลเมตา: คำอธิบายประกอบ: Sealedsecrets.bitnami.com/cluster-wide: "จริง"

ตรวจสอบความลับที่ปิดผนึก

หากคุณต้องการตรวจสอบความลับที่ปิดผนึกที่มีอยู่ kubeseal มีแฟล็ก --validate เพื่อช่วยคุณ

การให้ไฟล์ชื่อ sealed-secrets.yaml ซึ่งมีความลับที่ปิดผนึกต่อไปนี้:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: ชื่อ: mysecret เนมสเปซ: mynamespacespec: encryptedData: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

คุณสามารถตรวจสอบว่าความลับที่ปิดผนึกถูกสร้างขึ้นอย่างถูกต้องหรือไม่:

 $ cat ปิดผนึก-secrets.yaml | kubeseal --ตรวจสอบ

ในกรณีที่ความลับที่ปิดผนึกไม่ถูกต้อง kubeseal จะแสดง:

 $ cat ปิดผนึก-secrets.yaml | kubeseal --validateerror: ไม่สามารถถอดรหัสความลับที่ปิดผนึกได้

การหมุนความลับ

คุณควรหมุนเวียนความลับของคุณอยู่เสมอ แต่เนื่องจากความลับของคุณถูกเข้ารหัสด้วยความลับอื่น คุณจึงต้องเข้าใจว่าสองชั้นนี้เกี่ยวข้องกันอย่างไรในการตัดสินใจที่ถูกต้อง

TL; DR:

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

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

การต่ออายุกุญแจปิดผนึก

กุญแจปิดผนึกจะต่ออายุโดยอัตโนมัติทุก 30 วัน ซึ่งหมายความว่าคีย์การปิดผนึกใหม่จะถูกสร้างขึ้นและต่อท้ายชุดของคีย์การปิดผนึกที่ใช้งานอยู่ ซึ่งคอนโทรลเลอร์สามารถใช้เพื่อเปิดผนึกทรัพยากร SealedSecret

คีย์การปิดผนึกที่สร้างขึ้นล่าสุดคือคีย์ที่ใช้ในการปิดผนึกความลับใหม่เมื่อคุณใช้ kubeseal และเป็นคีย์ที่มีการดาวน์โหลดใบรับรองเมื่อคุณใช้ kubeseal --fetch-cert

เวลาต่ออายุ 30 วันเป็นค่าเริ่มต้นที่สมเหตุสมผล แต่สามารถปรับแต่งได้ตามต้องการด้วยแฟล็ก --key-renew-period= สำหรับคำสั่งในเทมเพลต pod ของคอนโทรลเลอร์ SealedSecret ฟิลด์ value สามารถกำหนดให้เป็นแฟล็กระยะเวลา golang (เช่น: 720h30m ) สมมติว่าคุณได้ติดตั้ง Sealed Secrets ลงในเนมสเปซ kube-system ให้ใช้คำสั่งต่อไปนี้เพื่อแก้ไข Deployment controller และเพิ่มพารามิเตอร์ --key-renew-period เมื่อคุณปิดโปรแกรมแก้ไขข้อความ และตัวควบคุมการปรับใช้ได้รับการแก้ไขแล้ว พ็อดใหม่จะถูกสร้างขึ้นโดยอัตโนมัติเพื่อแทนที่พ็อดเก่า 

kubectl edit deployment/sealed-secrets-controller --namespace=kube-system

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

ขออภัย คุณไม่สามารถใช้เช่น "d" เป็นหน่วยเป็นเวลาหลายวันได้ เนื่องจาก Go stdlib ไม่รองรับ แทนที่จะเอาฝ่ามือตบหน้า ให้ถือโอกาสนี้นั่งสมาธิเกี่ยวกับความเท็จที่โปรแกรมเมอร์เชื่อเรื่องเวลา

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

ข้อมูลลับที่ถูกปิดผนึกจะไม่ถูกหมุนเวียนโดยอัตโนมัติ และคีย์เก่าจะไม่ถูกลบเมื่อมีการสร้างคีย์ใหม่ ทรัพยากร SealedSecret เก่ายังคงสามารถถอดรหัสได้ (นั่นเป็นเพราะคีย์การปิดผนึกเก่าไม่ได้ถูกลบ)

การหมุนเวียนความลับของผู้ใช้

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

คุณค่าหลักของเครื่องมือนี้คือ:

เข้ารหัสความลับของคุณลงใน SealedSecret ซึ่ง จัดเก็บได้อย่างปลอดภัย แม้จะอยู่ในที่เก็บข้อมูลสาธารณะก็ตาม

หากคุณจัดเก็บสิ่งใดๆ ไว้ในที่เก็บข้อมูลการควบคุมเวอร์ชัน และโดยเฉพาะในที่สาธารณะ คุณต้องถือว่าคุณไม่สามารถลบข้อมูลนั้นได้

หาก คีย์การปิดผนึกรั่วไหลออกจากคลัสเตอร์ คุณต้องพิจารณาว่าทรัพยากร SealedSecret ทั้งหมดของคุณที่เข้ารหัสด้วยคีย์นั้นถูกบุกรุก จำนวนการหมุนคีย์การปิดผนึกในคลัสเตอร์หรือแม้แต่การเข้ารหัสซ้ำของไฟล์ SealedSecrets ที่มีอยู่ไม่สามารถเปลี่ยนแปลงสิ่งนั้นได้

แนวทางปฏิบัติที่ดีที่สุดคือการหมุนเวียนความลับที่แท้จริงทั้งหมดของคุณเป็นระยะ (เช่น เปลี่ยนรหัสผ่าน) และ สร้างทรัพยากร SealedSecret ใหม่ด้วยความลับใหม่เหล่านั้น

แต่หากตัวควบคุม SealedSecret ไม่ได้ต่ออายุ คีย์การปิดผนึก การหมุนนั้นอาจเป็นเรื่องที่สงสัย เนื่องจากผู้โจมตีสามารถถอดรหัสความลับใหม่ได้เช่นกัน ดังนั้นคุณต้องทำทั้งสองอย่าง: ต่ออายุคีย์ปิดผนึกเป็นระยะและหมุนความลับที่แท้จริงของคุณ!

การต่ออายุคีย์ล่วงหน้า

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

สามารถสร้างคีย์ได้ตั้งแต่เนิ่นๆ โดยส่งการประทับเวลาปัจจุบันไปยังคอนโทรลเลอร์ไปยังแฟล็กที่เรียกว่า --key-cutoff-time หรือ env var ที่เรียกว่า SEALED_SECRETS_KEY_CUTOFF_TIME รูปแบบที่ต้องการคือ RFC1123 คุณสามารถสร้างได้ด้วยคำสั่ง date -R unix

ความเข้าใจผิดที่พบบ่อยเกี่ยวกับการต่ออายุคีย์

ความลับที่ปิดผนึก กุญแจปิดผนึกไม่ใช่กุญแจควบคุมการเข้าถึง (เช่น รหัสผ่าน) คล้ายกับคีย์ GPG ที่คุณอาจใช้เพื่ออ่านอีเมลที่เข้ารหัสที่ส่งถึงคุณ มาดูการเปรียบเทียบอีเมลกันอีกสักหน่อย:

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

แน่นอนว่าเนื้อหาของอีเมลที่เข้ารหัสเหล่านั้นไม่ปลอดภัย เนื่องจากผู้โจมตีอาจสามารถถอดรหัสอีเมลเหล่านั้นได้ แต่สิ่งที่ทำเสร็จแล้ว การสูญเสียความสามารถในการอ่านอีเมลเหล่านั้นอย่างกะทันหันไม่ได้ช่วยแก้ไขความเสียหายได้อย่างแน่นอน หากมีสิ่งใดจะแย่กว่านั้นเพราะคุณไม่ทราบแน่ชัดอีกต่อไปว่าผู้โจมตีได้รู้ความลับอะไร สิ่งที่คุณต้องการทำจริงๆ คือทำให้แน่ใจว่าเพื่อนของคุณหยุดใช้คีย์เก่าของคุณ และจากนี้ไปการสื่อสารเพิ่มเติมทั้งหมดจะถูกเข้ารหัสด้วยคู่คีย์ใหม่ (กล่าวคือ เพื่อนของคุณต้องรู้เกี่ยวกับคีย์ใหม่นั้น)

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

ขั้นแรกคุณต้องตรวจสอบให้แน่ใจว่าความลับใหม่ไม่ได้รับการเข้ารหัสด้วยคีย์เก่าที่ถูกบุกรุก (ในการเทียบเคียงอีเมลข้างต้น นั่นคือ: สร้างคู่คีย์ใหม่และมอบคีย์สาธารณะใหม่ให้กับเพื่อนของคุณทุกคน)

ขั้นตอนที่สองคือการต่อต้านความเสียหาย ซึ่งขึ้นอยู่กับลักษณะของความลับ ตัวอย่างง่ายๆ คือรหัสผ่านฐานข้อมูล: หากคุณทำให้รหัสผ่านฐานข้อมูลของคุณรั่วไหลโดยไม่ได้ตั้งใจ สิ่งที่คุณควรทำคือเพียงเปลี่ยนรหัสผ่านฐานข้อมูลของคุณ (บนฐานข้อมูล และเพิกถอนรหัสผ่านเก่า!) และ อัปเดตทรัพยากร SealedSecret ด้วย รหัสผ่านใหม่ (เช่น เรียกใช้ kubeseal อีกครั้ง)

ทั้งสองขั้นตอนได้อธิบายไว้ในส่วนที่แล้ว แม้ว่าจะมีรายละเอียดน้อยกว่าก็ตาม ไม่ใช่เรื่องน่าละอายที่จะอ่านอีกครั้ง ตอนนี้คุณเข้าใจเหตุผลที่ซ่อนอยู่อย่างลึกซึ้งมากขึ้นแล้ว

การจัดการคีย์ด้วยตนเอง (ขั้นสูง)

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

อย่างไรก็ตาม หากคุณต้องการ คุณสามารถจัดการ (สร้าง ย้าย ลบ) คีย์การปิดผนึก ได้ด้วยตนเอง สิ่งเหล่านี้เป็นเพียงความลับของ k8 ปกติที่อยู่ในเนมสเปซเดียวกันกับที่คอนโทรลเลอร์ SealedSecret ใช้งานอยู่ (โดยปกติจะเป็น kube-system แต่สามารถกำหนดค่าได้)

มีกรณีการใช้งานขั้นสูงที่คุณสามารถแก้ไขได้ด้วยการจัดการคีย์การปิดผนึกอย่างสร้างสรรค์ ตัวอย่างเช่น คุณสามารถใช้คีย์การปิดผนึกเดียวกันร่วมกันในคลัสเตอร์ไม่กี่คลัสเตอร์ เพื่อให้คุณสามารถใช้ความลับที่ปิดผนึกเดียวกันทุกประการในหลายคลัสเตอร์ เนื่องจากการปิดผนึกคีย์เป็นเพียงความลับของ k8s ปกติ คุณจึงสามารถใช้ความลับที่ปิดผนึกได้ด้วยตนเอง และใช้เวิร์กโฟลว์ GitOps เพื่อจัดการคีย์การปิดผนึกของคุณ (มีประโยชน์เมื่อคุณต้องการแชร์คีย์เดียวกันระหว่างคลัสเตอร์ต่างๆ)!

การติดป้ายกำกับความลับ ของคีย์การปิดผนึก ด้วยสิ่งอื่นที่ไม่ใช่ active จะเป็นการลบคีย์ออกจากคอนโทรลเลอร์ SealedSecret อย่างมีประสิทธิภาพ แต่ยังคงมีให้ใช้งานใน k8s สำหรับการเข้ารหัส/ถอดรหัสด้วยตนเอง หากจำเป็น

หมายเหตุ ปัจจุบันตัวควบคุม SealedSecret จะไม่รับคีย์การปิดผนึกที่สร้าง ลบ หรือติดป้ายกำกับใหม่โดยอัตโนมัติ ผู้ดูแลระบบต้องรีสตาร์ทคอนโทรลเลอร์ก่อนจึงจะมีผลใช้งาน

การเข้ารหัสซ้ำ (ขั้นสูง)

ก่อนที่คุณจะสามารถกำจัดคีย์การปิดผนึกเก่าบางส่วนได้ คุณจะต้องเข้ารหัส SealedSecrets ของคุณอีกครั้งด้วยคีย์ส่วนตัวล่าสุด

 kubeseal --เข้ารหัสใหม่ tmp.json  && mv tmp.json my_sealed_secret.json

การร้องขอข้างต้นจะสร้างไฟล์ลับที่ปิดผนึกใหม่ซึ่งมีการเข้ารหัสใหม่ด้วยคีย์ล่าสุด โดยไม่ทำให้ความลับออกจากคลัสเตอร์ไปยังไคลเอ็นต์ จากนั้นคุณสามารถบันทึกไฟล์นั้นในระบบควบคุมเวอร์ชันของคุณได้ ( kubeseal --re-encrypt ไม่ได้อัปเดตวัตถุในคลัสเตอร์)

ปัจจุบันคีย์เก่าจะไม่ถูกรวบรวมโดยอัตโนมัติ

เป็นความคิดที่ดีที่จะเข้ารหัส SealedSecrets ของคุณอีกครั้งเป็นระยะๆ แต่ดังที่ได้กล่าวไว้ข้างต้น อย่าหลอกตัวเองด้วยความรู้สึกผิด ๆ เกี่ยวกับความปลอดภัย: คุณต้องถือว่าทรัพยากร SealedSecret เวอร์ชันเก่า (อันที่เข้ารหัสด้วยคีย์ที่คุณคิดว่าเสียแล้ว) ยังคงมีโอกาสอยู่ใกล้ ๆ และสามารถเข้าถึงได้โดยผู้โจมตี กล่าวคือ การเข้ารหัสใหม่ไม่สามารถทดแทนการสับเปลี่ยนความลับที่แท้จริงของคุณเป็นระยะๆ

รายละเอียด (ขั้นสูง)

คอนโทรลเลอร์นี้เพิ่มทรัพยากรแบบกำหนดเอง SealedSecret ใหม่ ส่วนที่น่าสนใจของ SealedSecret คือ Secret ที่เข้ารหัสแบบอสมมาตรที่เข้ารหัส base64

ตัวควบคุมจะรักษาชุดของคู่คีย์ส่วนตัว/สาธารณะไว้เป็นความลับของ Kubernetes คีย์จะมีป้ายกำกับว่า sealedsecrets.bitnami.com/sealed-secrets-key และระบุในป้ายกำกับว่า active หรือ compromised เมื่อเริ่มต้น ผู้ควบคุมความลับที่ปิดผนึกจะ...

  1. ค้นหาคีย์เหล่านี้และเพิ่มลงในร้านค้าในพื้นที่หากมีป้ายกำกับว่าใช้งานอยู่

  2. สร้างคีย์ใหม่

  3. เริ่มวงจรการหมุนที่สำคัญ

การเข้ารหัสลับ

รายละเอียดเพิ่มเติมเกี่ยวกับ crypto สามารถพบได้ที่นี่

กำลังพัฒนา

แนวทางการพัฒนาสามารถพบได้ในคู่มือนักพัฒนา

คำถามที่พบบ่อย

ฉันสามารถเข้ารหัสความลับหลายอย่างพร้อมกันในไฟล์ Yaml / JSON หนึ่งไฟล์ได้หรือไม่?

ใช่คุณทำได้! ลดความลับให้มากที่สุดเท่าที่คุณต้องการในไฟล์เดียว ตรวจสอบให้แน่ใจว่าได้แยกพวกเขาผ่าน --- สำหรับ Yaml และเป็นพิเศษวัตถุเดี่ยวใน JSON

คุณจะยังสามารถถอดรหัสได้หรือไม่หากคุณไม่สามารถเข้าถึงคลัสเตอร์ของคุณได้อีกต่อไป?

ไม่คีย์ส่วนตัวจะถูกเก็บไว้ในความลับที่จัดการโดยคอนโทรลเลอร์เท่านั้น (เว้นแต่คุณจะมีการสำรองข้อมูลอื่น ๆ ของวัตถุ K8S ของคุณ) ไม่มีแบ็คดอร์ - หากไม่มีคีย์ส่วนตัวที่ใช้ในการเข้ารหัส SealedSecrets ที่กำหนดคุณไม่สามารถถอดรหัสได้ หากคุณไม่สามารถไปที่ความลับด้วยคีย์การเข้ารหัสและคุณยังไม่สามารถไปที่ความลับที่ถอดรหัสของคุณอาศัยอยู่ในคลัสเตอร์ได้คุณจะต้องสร้างรหัสผ่านใหม่สำหรับทุกสิ่ง การปิดผนึกคีย์ ฯลฯ

ฉันจะสำรองข้อมูล SealedSecrets ได้อย่างไร?

หากคุณต้องการทำการสำรองข้อมูลคีย์ส่วนตัวเข้ารหัสมันเป็นเรื่องง่ายที่จะทำจากบัญชีที่มีการเข้าถึงที่เหมาะสม:

 kubectl รับความลับ -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml> main.keyecho "---" >> main.key
kubectl รับความลับ -n kube-system ปิดผนึก secrets-key -o yaml >> main.key

หมายเหตุ: คุณต้องใช้คำสั่งที่สองเฉพาะในกรณีที่คุณเคยติดตั้งอสังหาริมทรัพย์ที่ปิดผนึกเก่ากว่าเวอร์ชัน 0.9.x บนคลัสเตอร์ของคุณ

หมายเหตุ: ไฟล์นี้จะมีคีย์สาธารณะ + ส่วนตัวของคอนโทรลเลอร์และควรเก็บ OMG-SAFE!

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

หากต้องการกู้คืนจากการสำรองข้อมูลหลังจากหายนะเพียงแค่นำความลับนั้นกลับมาก่อนที่จะเริ่มต้นคอนโทรลเลอร์ - หรือหากคอนโทรลเลอร์เริ่มขึ้นแล้วให้แทนที่ความลับที่สร้างขึ้นใหม่และรีสตาร์ทคอนโทรลเลอร์:

  • สำหรับการปรับใช้ Helm:

     kubectl ใช้ -f main.key
kubectl delete pod -n kube -system -l app.kubernetes.io/name=sealed-secrets

  • สำหรับการปรับใช้ผ่าน controller.yaml Manifest

     kubectl ใช้ -f main.key
Kubectl DELETE POD -N KUBE-SYSTEM -L NAME = Sealed-Secrets-Controller

ฉันสามารถถอดรหัสความลับของฉันออฟไลน์ด้วยคีย์สำรองได้หรือไม่?

ในขณะที่การรักษาความลับที่ปิดผนึกเนื่องจากระบบจัดเก็บข้อมูลระยะยาวสำหรับความลับไม่ใช่กรณีการใช้งานที่แนะนำบางคนมีข้อกำหนดที่ถูกต้องตามกฎหมายสำหรับความสามารถในการกู้คืนความลับเมื่อคลัสเตอร์ K8S ลดลงและการกู้คืนการ SealedSecret ใหม่ ใช้ได้จริง.

หากคุณสำรองข้อมูลคีย์ส่วนตัวของคุณอย่างน้อยหนึ่งรายการ (ดูคำถามก่อนหน้า) คุณสามารถใช้ kubeseal --recovery-unseal --recovery-private-key file1.key,file2.key,... คำสั่งเพื่อถอดรหัส ไฟล์ความลับที่ปิดผนึก

มีธงอะไรบ้างสำหรับ Kubeseal?

คุณสามารถตรวจสอบธงที่มีได้โดยใช้ kubeseal --help

ฉันจะอัปเดตชิ้นส่วนของ JSON/YAML/TOML/.. ไฟล์ที่เข้ารหัสด้วยความลับที่ปิดผนึกได้อย่างไร

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

เนื่องจากนี่เป็นปัญหาที่พบบ่อยโดยเฉพาะอย่างยิ่งเมื่อต้องรับมือกับแอปพลิเคชันดั้งเดิมเราจึงเสนอตัวอย่างของวิธีแก้ปัญหาที่เป็นไปได้

ฉันสามารถนำใบรับรองของตัวเอง (สร้างล่วงหน้า) ได้หรือไม่?

ใช่คุณสามารถให้ใบรับรองของคุณเองและมันจะกินพวกเขา โปรดตรวจสอบที่นี่เพื่อหาวิธีแก้ปัญหา

จะใช้ kubeseal ได้อย่างไรหากคอนโทรลเลอร์ไม่ทำงานภายในเนมสเปซ kube-system ?

หากคุณติดตั้งคอนโทรลเลอร์ในเนมสเปซที่แตกต่างจาก kube-system เริ่มต้นคุณต้องจัดเตรียมเนมสเปซนี้ให้กับเครื่องมือคำสั่ง kubeseal มีสองตัวเลือก:

  1. คุณสามารถระบุเนมสเปซผ่านตัวเลือกบรรทัดคำสั่ง --controller-namespace ::

 Kubeseal-ความลับที่ปิดผนึก-คอนโทรลเลอร์-แอนเมสเปซ  mysealedsecret.json

  1. ผ่านตัวแปรสภาพแวดล้อม SEALED_SECRETS_CONTROLLER_NAMESPACE :

 ส่งออก sealed_secrets_controller_namespace = sealed-secrets
kubeseal  mysealedsecret.json

จะตรวจสอบภาพได้อย่างไร?

ภาพของเรากำลังลงนามโดยใช้ COSIGN ลายเซ็นได้รับการบันทึกไว้ในรีจิสทรีคอนเทนเนอร์ GitHub ของเรา

ภาพที่สูงถึงและรวมถึง v0.20.2 ได้รับการลงนามโดยใช้ COSIGN V1 ภาพที่ใหม่กว่าได้รับการลงนามด้วย Cosign V2

มันค่อนข้างง่ายในการตรวจสอบภาพ:

 # ส่งออก cosign_variable การตั้งค่า GitHub คอนเทนเนอร์รีจิสทรีลงนาม pathexport cosign_repository = ghcr.io/bitnami-labs/sex-secrets-controller/signs# ตรวจสอบภาพที่อัปโหลดใน Ghcrcosign Verify io/bitnami-labs/seeled-secrets-controller:# ล่าสุดตรวจสอบภาพที่อัปโหลดใน Dockerhubcosign Verify-Key .github/Workflows/cosign.pub Docker.io/bitnami/sealed-secrets-controller:latest

วิธีใช้คอนโทรลเลอร์หนึ่งตัวสำหรับชุดย่อยของเนมสเปซ

หากคุณต้องการใช้คอนโทรลเลอร์หนึ่งตัวสำหรับเนมสเปซมากกว่าหนึ่งตัว แต่ไม่ใช่เนมสเปซทั้งหมดคุณสามารถให้เนมสเปซเพิ่มเติมโดยใช้แฟล็กบรรทัดคำสั่ง --additional-namespaces=,,<...> ตรวจสอบให้แน่ใจว่าคุณมีบทบาทและการผูกมัดที่เหมาะสมในเนมสเปซเป้าหมายเพื่อให้คอนโทรลเลอร์สามารถจัดการความลับในนั้นได้

ฉันสามารถกำหนดค่าการเปิดตัวคอนโทรลเลอร์ retries ได้หรือไม่?

คำตอบคือใช่คุณสามารถกำหนดค่าจำนวนการตอบกลับในคอนโทรลเลอร์ของคุณโดยใช้ธง --max-unseal-retries แฟล็กนี้ช่วยให้คุณกำหนดค่าจำนวนการลองใหม่สูงสุดเพื่อปลดปล่อยความลับที่ปิดผนึกของคุณ

ชุมชน

  • #ปิดผนึกความลับบน Kubernetes Slack

คลิกที่นี่เพื่อลงทะเบียนกับ Kubernetes Slack org

โครงการที่เกี่ยวข้อง

  • kubeseal-convert : https://github.com/eladleev/kubeseal-convert

  • ส่วนขยายรหัส Visual Studio: https://marketplace.visualstudio.com/items?itemname=codecontemplator.kubeseal

  • WebSEAL: สร้างความลับในเบราว์เซอร์: https://socialgouv.github.io/webseal

  • การใช้งาน hybridencrypt typescript: https://github.com/socialgouv/aes-gcm-rsa-oaep

  • [ผู้ที่ไม่ได้ลงโทษ] ผู้ดำเนินการความลับที่ปิดผนึก: https://github.com/disposab1e/sealed-secrets-operator-helm

ขยาย
ข้อมูลเพิ่มเติม
แอปที่เกี่ยวข้อง
แนะนำสำหรับคุณ
ข้อมูลที่เกี่ยวข้อง ทั้งหมด
ความคิดเห็นจากผู้ใช้