NebulaCR: รีจิสทรี OCI ระดับองค์กร ความสามารถในการสังเกต และการปฏิบัติตามข้อกำหนดโดยไม่มีการประนีประนอม
สถาปัตยกรรม การตรวจสอบสิทธิ์แบบ Zero Trust ความสามารถในการสังเกต และการดำเนินการ Kubernetes
Balinder Walia15 เมษายน 25692 min readบทสรุปผู้บริหาร
NebulaCRเป็นรีจีสทรีคอนเทนเนอร์OCI แบบโอเพ่นซอร์สบนคลาวด์เนทีฟเขียนด้วยภาษา Rust โดยจะจับคู่บริการnebula-registry ที่ตรงตามมาตรฐาน (พอร์ต 5000) กับบริการโทเค็นnebula-authโดยเฉพาะ (พอร์ต 5001) การผสานรวมHashiCorp Vaultสำหรับการลงนามคีย์ พื้นที่จัดเก็บอ็อบเจ็กต์แบบเสียบได้(ระบบไฟล์, S3, GCS, Azure Blob) และบรรจุภัณฑ์Kubernetesชั้นหนึ่งพร้อม CRD สำหรับผู้เช่า โครงการ และนโยบาย โครงการต้นน้ำวางตำแหน่งผลิตภัณฑ์โดยมีการกระจายรูปภาพแบบส่วนตัว สังเกตได้ และควบคุมได้ ดูnebulacr.orgสำหรับหน้า Landing Page สาธารณะ และgithub.com/bwalia/nebulacrสำหรับแหล่งที่มาและการเผยแพร่
เหตุใดองค์กรต่างๆ จึงนำรีจิสทรี OCI ส่วนตัวมาใช้ อิมเมจคอนเทนเนอร์
จึงเป็นหน่วยของการปรับใช้สำหรับทีมที่เน้นระบบคลาวด์ส่วนใหญ่ รีจิสทรีที่อยู่ภายในขอบเขตความปลอดภัยของคุณเท่านั้น ช่วยให้คุณสามารถบังคับใช้ถิ่นที่อยู่ของข้อมูล,การควบคุมซัพพลายเชน,แบบละเอียด RBACและต้นทุนที่คาดการณ์ได้(โดยเฉพาะอย่างยิ่งเมื่อรวมกับแคชแบบดึงผ่านสำหรับการลงทะเบียนอัปสตรีม) NebulaCR กำหนดเป้าหมายผู้ปฏิบัติงานที่ต้องการเวิร์กโฟลว์ที่เข้ากันได้กับ Docker โดยไม่สูญเสียเอกลักษณ์ ความสามารถในการตรวจสอบ หรือความยืดหยุ่นในหลายภูมิภาค
Rust workspace (Cargo.toml)
UpstreamCargo.tomlประกาศพื้นที่ทำงานที่มีเจ็ดลัง:nebula-common,nebula-auth,nebula-registry,nebula-controller,ความยืดหยุ่นของเนบิวลา,เนบิวลากระจกและการจำลองเนบิวลาแผนผังโปรเจ็กต์ของ README แมปแต่ละลังกับไบนารีหรือไลบรารี เช่น บริการรีจิสทรีและการรับรองความถูกต้อง ตัวกระทบยอด Kubernetes กลไกแคชแบบดึงผ่าน ตัวช่วยความยืดหยุ่น และการจำลองแบบหลายภูมิภาค จากแหล่งที่มา ให้รันcargo build --workspace --releaseและcargo test --workspaceก่อนที่จะสร้างคอนเทนเนอร์ด้วยรูทDockerfileหรือDockerfile.scratchที่ปรับให้เหมาะสม
สถาปัตยกรรมกลั่นจากเอกสารโครงการ
นอกเหนือจากไบนารี/ไลบรารีหลักทั้งสามที่อธิบายไว้ข้างต้นnebula-controllerกระทบยอดผู้เช่า/โครงการ/นโยบายการเข้าถึง/TokenPolicy CRDsnebula-mirrorใช้แคชแบบดึงผ่านสำหรับการลงทะเบียนอัปสตรีมnebula-resilienceดำเนินการลองใหม่และเซอร์กิตเบรกเกอร์สำหรับเส้นทางการจำลอง และnebula-replicationรองรับโหมดอะซิงก์หรือกึ่งซิงค์หลายภูมิภาคพร้อมเฟลโอเวอร์ที่อธิบายไว้ในdocs/architecture.mdเนบิวลารีจิสทรียังคงใช้ Axum โดยมีการบังคับใช้ JWT ตามคำขอnebula-authตรวจสอบโทเค็นประจำตัว OIDC และออก JWT รีจิสทรีที่มีอายุสั้น พื้นที่เก็บข้อมูลยังคงเป็นแบบลำดับชั้นสำหรับผู้เช่า/โปรเจ็กต์ ในขณะที่แบ็กเอนด์ยังคงเสียบปลั๊กได้
เส้นทางขาเข้า การตรวจสอบสภาพ และหน่วยวัด
สถาปัตยกรรม ASCII ของ README แสดงการแยกการรับส่งข้อมูล:/v2ไปยังบริการรีจิสทรี (5000) และโฟลว์การรับรองความถูกต้อง (มักจะอยู่ภายใต้/auth) ไปยังnebula-auth(5001) โดยมีผู้ให้บริการ OIDC ภายนอกทั้งสองแห่ง แผนภูมิ Helm แสดงตัววัด Prometheus (ตัวอย่าง ได้แก่nebulacr_http_requests_total,nebulacr_http_request_duration_seconds,nebulacr_storage_operations_total,nebulacr_auth_tokens_issued_total) และเอกสารcurl http://localhost:5000/healthหลังจากkubectl port-forwardไปยังบริการรีจิสทรี
การตรวจสอบสิทธิ์แบบ Zero-trust และการบูรณาการ CI
NebulaCR เน้นย้ำว่าไม่มีรหัสผ่านรีจิสทรีที่มีอายุการใช้งานยาวนานสำหรับระบบอัตโนมัติ ระบบ CI นำเสนอโทเค็นประจำตัว OIDC จากผู้ออกที่เชื่อถือได้ nebula-auth ตรวจสอบความถูกต้องของลายเซ็น ใช้นโยบาย และส่งคืน JWT ที่กำหนดขอบเขตด้วยค่าเริ่มต้น TTL ที่จำกัด (โดยทั่วไปประมาณห้านาที) ผู้ปฏิบัติงานที่เป็นมนุษย์จะตรวจสอบสิทธิ์ผ่านโฟลว์รหัสการให้สิทธิ์ OIDC มาตรฐานที่มี PKCE กับผู้ให้บริการ เช่น Azure AD, Okta หรือ Google Workspace
CRDs, แคชแบบดึงผ่าน และขีดจำกัดอัตรา
ตัวดำเนินการ Kubernetes จัดการTenant(โควต้า, การเชื่อมโยง OIDC),Project(กลุ่มพื้นที่เก็บข้อมูลและนโยบาย),AccessPolicy(RBAC) และTokenPolicy(บัญชี TTL และโรบ็อต) เอกสาร README ดึงผ่านเอกสารเช่นคำนำหน้าdocker pull <host>:5000/library/nginx:latest, GHCR และ Quay และบทมิเรอร์containerdที่ชี้docker.ioที่ NebulaCR การจำกัดอัตราจะใช้ต่อ IP และต่อผู้เช่าโดยใช้ลังgovernor
ความสามารถในการสังเกต การตรวจสอบ และการปฏิบัติตามข้อกำหนด
ตามเอกสารประกอบโครงการที่ตั้งไว้ภายใต้docs/NebulaCR เปิดเผยPrometheus เมตริกจากบริการรีจิสทรีและการรับรองความถูกต้อง โดยปล่อยบันทึก JSON ที่มีโครงสร้างและรองรับOpenTelemetrytracing เพื่อการวิเคราะห์เชิงลึก แดชบอร์ดแบบฝังจะแสดง CPU, หน่วยความจำ, ดิสก์, ความสมบูรณ์ของการจำลอง, การเรียกดูพื้นที่เก็บข้อมูล และเส้นทางการตรวจสอบที่กรองแล้วสำหรับการพุช ดึง และลบ ซึ่งเป็นหลักฐานสำคัญสำหรับการตรวจสอบความปลอดภัยSCIM 2.0 การจัดเตรียมจะทำให้วงจรของ joiner-mover-leaver เป็นแบบอัตโนมัติด้วยผู้ให้บริการข้อมูลระบุตัวตน ซึ่งจะลดขนาดหน้าต่างที่อดีตพนักงานยังคงสามารถเข้าถึงการเข้าถึงที่แฝงอยู่ได้
ความพร้อมใช้งานสูง แคชแบบดึงผ่านหลายภูมิภาค
README เน้นย้ำบริการไร้สัญชาติพร้อมด้วยการปรับขนาดพ็อดอัตโนมัติแนวนอน งบประมาณการหยุดชะงักของพ็อด และเซอร์กิตเบรกเกอร์สำหรับเส้นทางการจำลอง การจำลองแบบหลายภูมิภาคได้รับการอธิบายว่าเป็นแบบอะซิงโครนัสกับการควบคุมความยืดหยุ่น ดังนั้นการอ่านอาจล้มเหลวเมื่อขอบเขตลดลง การแคชแบบดึงผ่านจะช่วยลดแบนด์วิดท์และเวลาแฝงในการดึงสำหรับการลงทะเบียนอัปสตรีม รวมถึง Docker Hub, GHCR, GCR, Quay.io และ register.k8s.io
เริ่มต้นใช้งาน
สำหรับการทดลองใช้ในพื้นที่ขั้นต่ำ เอกสาร READMEdocker run -p 5000:5000 bwalia/nebulacr:latest,docker compose up -dสำหรับการลงทะเบียนพร้อมการรับรองความถูกต้องใน 5001 ด้วยคีย์ JWT ที่สร้างขึ้น และ Helm ติดตั้งจากoci://ghcr.io/bwalia/charts/nebulacrหรือ repo GitHub Pages รูปภาพแบบหลายอาร์คจัดส่งเป็นlinux/amd64และlinux/arm64บน Docker Hub และ GHCR ทีมงานฝ่ายผลิตวางสายdeploy/helm/nebulacrพร้อมทางเข้า TLS, OIDC และ S3 ที่เป็นตัวเลือก, ServiceMonitor scraping และเทมเพลต NetworkPolicy จากแผนภูมิ
Workstation สามารถช่วย
Workstation ได้อย่างไรในการออกแบบและใช้รูปแบบวิศวกรรมแพลตฟอร์มที่ปลอดภัย—การลงทะเบียนส่วนตัว ไปป์ไลน์การส่งเสริมการขาย GitOps นโยบายที่เป็นโค้ด และความสามารถในการสังเกต SRE—ทั่วทั้งสภาพแวดล้อมคลาวด์และในสถานที่ สำหรับการตรวจสอบสถาปัตยกรรมหรือการสนับสนุนการจัดส่ง โปรดติดต่อinfo@workstation.co.uk