ฉันทำงานหนักกับ OAuth2/OIDC ในงานปัจจุบันของฉัน ตอนนี้ย้ายไปที่ GCP มากขึ้นเรื่อยๆ ฉันมีคำถามที่ชัดเจนเกี่ยวกับการใช้โทเค็น OIDC สำหรับการสื่อสารแบบบริการต่อบริการ ระดับสูง หนึ่งยุทธวิธี:
ปัญหา: ฉันกำลังรักษาความปลอดภัยงาน Cloud Scheduler ไปยังตำแหน่งข้อมูล Cloud Run ฉันได้แก้ปัญหาแล้ว (อย่างดีที่สุดที่ฉันสามารถบอกได้) แต่ฉันสับสนอย่างมากว่าทำไม Google จึงตั้งค่าด้วยวิธีนี้และหวังว่าจะได้รับคำชี้แจง ไม่ใช่สิ่งที่ท้าทายเพียงแสวงหาความเข้าใจ มันให้ความรู้สึกที่แตกต่างจากที่ฉันรู้ ฉันใช้ id_tokens กับมนุษย์มาโดยตลอด
เหตุใดพวกเขาจึงเลือก OIDC ID Token สำหรับบริการเพื่อการสื่อสารบริการ ฉันใช้ OIDC เป็นจำนวนมากในด้านผู้ใช้ แต่ไม่เคยใช้งานบนเซิร์ฟเวอร์ถึงฝั่งเซิร์ฟเวอร์ ดังนั้นการรับ ID Token สำหรับการสื่อสารระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์จึงรู้สึกแปลกมาก ฉันชอบลิงก์ที่ชี้ไปยังเอกสารที่อธิบายตัวเลือกสถาปัตยกรรมนี้บนเซิร์ฟเวอร์ไปยังฝั่งเซิร์ฟเวอร์ .. ฉันคาดว่าจะมีโทเค็นการเข้าถึง OAuth2 พร้อมข้อมูลประจำตัวไคลเอนต์สำหรับบริการทั้งหมดเพื่อการสื่อสารบริการไม่ใช่โทเค็น ID ฉันเห็นว่า เอกสารของพวกเขาระบุว่าแพลตฟอร์มใช้ทั้งสองอย่างผสมกัน
เหตุใดฟิลด์ผู้ชมจึงเป็นไปตามอำเภอใจ ใน Cloud Scheduler ดูเหมือนว่าตราบใดที่ฉันใช้บัญชีบริการที่ถูกต้องในโปรเจ็กต์ ฉันสามารถใส่ค่าใดๆ ในช่องผู้ชมได้หรือไม่ ฉันแน่ใจว่ามีเหตุผลสำหรับเรื่องนี้ คนใน Google ฉลาด แต่รู้สึกเหมือนเป็นช่องโหว่ด้านความปลอดภัย ฉันหมายความว่าผู้ชมอาจเป็น URL ที่ถูกต้อง (ดีที่สุดที่ฉันสามารถบอกได้) ฉันสามารถใส่กลุ่มเป้าหมายของตำแหน่งข้อมูล Cloud Run ในโครงการอื่นและทำการเรียกนั้นได้หรือไม่
เห็นได้ชัดว่ามีการแบ่งระหว่าง AuthN และ AuthZ ที่นี่ ดังนั้น id_token จึงเกี่ยวกับ authN มากกว่า แต่ฟิลด์ผู้ชมที่ตรวจสอบความถูกต้องตามคำขอของโทเค็นจะระบุ Authz ที่เป็นของแข็ง แต่ด้วยการที่มันเป็นไปตามอำเภอใจ ฉันรู้สึกว่าการตรวจสอบของผู้ชมไม่สามารถเชื่อถือได้ เพราะใครจะใส่อะไรลงไปก็ได้ โปรดบอกฉันว่าฉันขาดอะไร
ฉันหวังว่าคำถามเหล่านี้จะสมเหตุสมผล ฉันเพิ่งเริ่มใช้ GCP แต่ก็เหมือนกับสิ่งที่ฉันเห็น แต่ส่วนหนึ่งของงานของฉันคือการหาขอบของสิ่งต่างๆ และสิ่งเหล่านี้ก็รู้สึกแปลกเมื่อเทียบกับสิ่งที่ฉันเคยใช้ในอดีต
เหตุใดพวกเขาจึงเลือก OIDC ID Token สำหรับบริการต่อบริการ การสื่อสาร? ฉันใช้ OIDC เป็นจำนวนมากในด้านผู้ใช้ แต่ไม่เคยใช้ เซิร์ฟเวอร์ไปยังฝั่งเซิร์ฟเวอร์ ดังนั้นการรับ ID Token สำหรับเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ การสื่อสารรู้สึกแปลกมาก ฉันชอบลิงก์ที่ชี้ไปที่ เอกสารอธิบายตัวเลือกสถาปัตยกรรมนี้บนเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ ด้าน .. ฉันคาดว่าจะมีโทเค็นการเข้าถึง OAuth2 กับไคลเอนต์ ข้อมูลรับรองสำหรับการสื่อสารระหว่างบริการทั้งหมดไม่ใช่ ID Token
ใน Google Cloud มีการให้สิทธิ์สองประเภท ตามบทบาท (โทเค็นการเข้าถึง OAuth) และตามข้อมูลประจำตัว (โทเค็นข้อมูลประจำตัว OIDC) การอนุญาตตามบทบาทช่วยให้เข้าถึงทรัพยากรทั้งหมดตามบทบาท ตัวอย่างเช่น สิทธิ์ของผู้ดูในการเข้าถึงอินสแตนซ์ Compute Engine ทั้งหมด สิทธิ์ประเภทนี้ได้รับการจัดการในระดับโครงการ/โฟลเดอร์/องค์กร การอนุญาตตามข้อมูลประจำตัวทำให้สามารถเข้าถึงทรัพยากรแต่ละรายการได้ ข้อแตกต่างที่สำคัญคือตำแหน่งที่จะกำหนดสิทธิ์/บทบาท: ที่ระดับโครงการหรือที่ระดับทรัพยากร เนื่องจากบทบาทมีการอนุญาตที่กว้างเกินไปในระดับทรัพยากร คุณจึงต้องใช้วิธีอื่นทางนั้นคือตัวตน ฉันให้ จอห์น เข้าถึงคีย์ KMS ความลับ2. ข้อมูลประจำตัว + สิทธิ์ถูกจัดเก็บไว้ในเลเยอร์การจัดการการเข้าถึงคีย์ KMS
เหตุใดฟิลด์ผู้ชมจึงเป็นไปตามอำเภอใจ ใน Cloud Scheduler นั้น ดูเหมือนว่าตราบใดที่ฉันใช้บัญชีบริการที่ถูกต้องในโครงการ ฉันสามารถใส่ค่าใด ๆ ในช่องผู้ชมได้หรือไม่? ฉันแน่ใจว่ามีเหตุผล สำหรับสิ่งนี้ คนใน Google นั้นฉลาด แต่รู้สึกเหมือนเป็นช่องโหว่ด้านความปลอดภัย ฉันหมายความว่าผู้ชมอาจเป็น URL ที่ถูกต้อง (ดีที่สุดที่ฉันสามารถบอกได้) ให้ฉัน ใส่กลุ่มเป้าหมายของตำแหน่งข้อมูล Cloud Run ในโครงการอื่นและสร้าง ที่โทร?
หากรหัสของคุณสร้าง Identity Token แสดงว่า ผู้ชม ต้องระบุ. มีรหัสไคลเอ็นต์ OAuth ที่จัดการโดย Google บางรายการที่อนุญาตให้ละเว้นผู้ชม เนื่องจากข้อมูลประจำตัวและสิทธิ์ถูกเก็บไว้ที่ทรัพยากร การเรียกตำแหน่งข้อมูล Cloud Run อื่นจะไม่ผ่านการตรวจสอบข้อมูลประจำตัว IMHO ฟิลด์ผู้ชมเป็นวิธีการที่รวดเร็วสำหรับระบบระบุตัวตนเพื่อตรวจสอบก่อนว่าโทเค็นข้อมูลระบุตัวตนควรได้รับการอนุมัติสำหรับเลเยอร์ IAM หรือไม่
เห็นได้ชัดว่ามีการแบ่งระหว่าง AuthN และ AuthZ ดังนั้น id_token เป็นข้อมูลเพิ่มเติมเกี่ยวกับ authN แต่ฟิลด์ผู้ชมได้รับการตรวจสอบบน คำขอของโทเค็นจะระบุ Authz ที่เป็นของแข็ง แต่ด้วยความที่เป็นอยู่ ตามอำเภอใจ ฉันรู้สึกว่าการตรวจสอบของผู้ชมไม่สามารถเชื่อถือได้ เพราะใครจะใส่อะไรก็ได้ ช่วยบอกทีว่าฉันเป็นอะไร หายไป.
มีการเซ็นชื่อโทเค็นประจำตัว เฉพาะบริการและรหัสที่ได้รับอนุญาตเท่านั้นที่สามารถสร้างโทเค็นข้อมูลประจำตัวได้ ดังที่ฉันได้กล่าวถึงในข้อก่อนหน้านี้ ผู้ชมไม่ได้ให้สิทธิ์หรืออนุญาตการเข้าถึง เป็นขั้นตอนหนึ่งในชั้นของขั้นตอนในการอนุญาตการเข้าถึงตามโทเค็นข้อมูลประจำตัว การตรวจสอบสิ้นสุดคือข้อมูลประจำตัว + สิทธิ์ที่กำหนดให้กับทรัพยากร ผู้ชมไม่ได้อนุญาตสิ่งเหล่านี้ แต่สามารถใช้เป็นตัวกรองเพื่อทิ้งโทเค็นได้อย่างรวดเร็ว
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
