Score:0

ใบรับรองหลักที่กำหนดเองสำหรับไฟล์ kubeconfig

ธง jp

วิ่ง kubeadm init phase certs apiserver --config kubeadm.yaml

เป็นไปได้หรือไม่ที่จะใช้ใบรับรองรูทหลายรายการ/แบบกำหนดเองสำหรับกลุ่มผู้ใช้/ไฟล์ kubectl/config

ฉันถามเพราะฉันต้องการให้สิทธิ์การเข้าถึงเป็นรายโครงการ - จากนั้นจึงลบใบรับรองรูทที่กำหนดเองออก - แต่เก็บใบรับรองรูท "ดั้งเดิม" ไว้สำหรับผู้ดูแลระบบ kubectl พิเศษ

ฉันเห็นว่าคุณสามารถใช้ ssh tunneling เป็นด่านแรกในการป้องกัน เพื่อป้องกันคีย์สาธารณะของใบรับรองหลักแต่คุณยังคงต้องแจกจ่ายใบรับรองที่ลงนามสาธารณะแม้ว่าจะอยู่ด้านหลังคีย์ส่วนตัวสาธารณะ ssh ดังนั้นอาจมีวิธีการใช้ ssh tunneling - และใส่ใบรับรองที่กำหนดเองเข้าไป ใบรับรองDir: /etc/kubernetes/pki?

kubeadm.yaml

apiเซิร์ฟเวอร์:
  อาร์กิวเมนต์พิเศษ:
    โหมดการให้สิทธิ์: โหนด RBAC
  หมดเวลาสำหรับการควบคุมเครื่องบิน: 4m0s
apiVersion: kubeadm.k8s.io/v1beta1
ใบรับรองDir: /etc/kubernetes/pki

ฉันรู้ว่าคุณสามารถใช้ --insecure-skip-tls-ตรวจสอบ ในไฟล์ปรับแต่ง แต่ดูเหมือนว่าเป็นความคิดที่ไม่ดี

Score:1
ธง in

เป็นไปได้หรือไม่ที่จะใช้ใบรับรองรูทหลายรายการ/แบบกำหนดเองสำหรับกลุ่มผู้ใช้/ไฟล์ kubectl/config

ไม่ มีใบรับรอง "รูท" เพียงใบเดียว นั่นเป็นเหตุผลว่าทำไมจึงเรียกว่ารูท

อย่างไรก็ตาม x509 เป็นไฟล์ โซ่ ของความน่าเชื่อถือ หมายความว่าค่อนข้างเป็นไปได้ที่จะออก CA รองภายใต้รูทนั้น จากนั้นจึงออกใบรับรองผู้ใช้ภายใต้ CA เหล่านั้น โดยเลือกที่จะลบ CA รองเมื่อโครงการสิ้นสุดลง ซึ่งจะทำให้ใบรับรอง leaf เหล่านั้นหมดไป โปรดทราบว่าด้วยความรู้ที่ดีที่สุดของฉัน การเปลี่ยนใบรับรองหรือห่วงโซ่ของใบรับรองจำเป็นต้องรีสตาร์ทแผงควบคุม เนื่องจากไม่ได้โหลดไฟล์ใบรับรองเหล่านั้นซ้ำ ฉันเชื่อว่ามีปัญหา GitHub เช่นเดียวกับส่วนที่เหลือทั้งหมด 15,000 รายการ

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

ฉันติดตั้งอันที่ 2 เป็นการส่วนตัวแล้ว (โดยใช้ Vault) แต่ฉันเชื่อว่าอันแรกเป็นไปได้เพราะ apiserver ใช้ x509 chains สำหรับการตรวจสอบส่วนประกอบในคลัสเตอร์บางส่วน ดังนั้นฉันจึงไม่เห็นว่าทำไมคุณไม่สามารถใช้ประโยชน์ในลักษณะเดียวกันได้ ของกลไกนั้นๆ


ฉันรู้ว่านี่ไม่ใช่สิ่งที่คุณถาม แต่การใช้ x509 สำหรับการตรวจสอบสิทธิ์ชั่วคราวเช่นนั้นคือหนทางสู่ความพินาศ เพราะอย่างที่คุณประสบอยู่ ทั้งสองฝ่าย การออกและการเพิกถอน เป็นสิ่งที่เจ็บปวดอย่างมาก ถ้าพร้อมให้คุณใช้งานแล้ว กลไกการรับรอง OIDC ง่ายกว่ามากที่จะให้เหตุผลเกี่ยวกับและ คูเบก มีมากหรือน้อย การสนับสนุนในตัวสำหรับมัน

jp flag
ขอบคุณสำหรับคำตอบ - ฉันคิดว่าฉันจะทำตามคำแนะนำของคุณโดยใช้ OpenID (OIDC) ฉันจะพยายามรวม https://github.com/micahhausler/k8s-oidc-helper นี้กับ github https://docs.github.com/en/developers/apps/building-oauth-apps/authorizing-oauth-apps

โพสต์คำตอบ

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