โปรโฮสต์ > บล็อก > การบริหาร > ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

ถูกต้องแล้วหลังจากการเปิดตัว กงสุล Hashicorp 1.5.0 เมื่อต้นเดือนพฤษภาคม 2019 ในกงสุล คุณสามารถอนุญาตแอปพลิเคชันและบริการที่ทำงานใน Kubernetes ได้

ในบทช่วยสอนนี้ เราจะสร้างทีละขั้นตอน POC (Proof of concept, PoC) สาธิตคุณลักษณะใหม่นี้ คุณถูกคาดหวังให้มีความรู้พื้นฐานเกี่ยวกับ Kubernetes และกงสุลของ Hashicorp แม้ว่าคุณสามารถใช้แพลตฟอร์มระบบคลาวด์หรือสภาพแวดล้อมในองค์กรใดก็ได้ แต่ในบทช่วยสอนนี้ เราจะใช้ Cloud Platform ของ Google

ทบทวน

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

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

แผนภาพที่ 1: ภาพรวมอย่างเป็นทางการของวิธีการอนุมัติกงสุล

มาดูข้างในกันดีกว่า เอกสารประกอบสำหรับวิธีการอนุญาต Kubernetes เฉพาะ.

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

ก่อนที่เราจะไปยังการสร้าง POC ของเรา เรากลับไปที่ภาพรวมของวิธีการอนุญาตของกงสุล (แผนภาพที่ 1) และปรับปรุงในบริบทของ Kubernetes

สถาปัตยกรรม

ในบทช่วยสอนนี้ เราจะสร้างเซิร์ฟเวอร์ Consul บนเครื่องแยกต่างหากที่จะสื่อสารกับคลัสเตอร์ Kubernetes ที่ติดตั้งไคลเอ็นต์ Consul ไว้ จากนั้นเราจะสร้างแอปพลิเคชันจำลองของเราในพ็อดและใช้วิธีการอนุญาตที่กำหนดค่าไว้เพื่ออ่านจากที่เก็บคีย์/ค่ากงสุลของเรา

แผนภาพด้านล่างให้รายละเอียดเกี่ยวกับสถาปัตยกรรมที่เรากำลังสร้างในบทช่วยสอนนี้ รวมถึงตรรกะเบื้องหลังวิธีการอนุญาต ซึ่งจะอธิบายในภายหลัง

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

แผนภาพที่ 2: ภาพรวมวิธีการอนุญาต Kubernetes

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

ดังนั้น เมื่อนำแผนภาพภาพรวมกงสุล (แผนภาพ 1) และใช้ Kubernetes กับมัน เราจะได้แผนภาพด้านบน (แผนภาพ 2) และตรรกะที่นี่จะเป็นดังนี้:

  1. แต่ละพ็อดจะมีบัญชีบริการแนบอยู่ซึ่งมีโทเค็น JWT ที่สร้างและรู้จักโดย Kubernetes โทเค็นนี้จะถูกแทรกลงในพ็อดตามค่าเริ่มต้นด้วย
  2. แอปพลิเคชันหรือบริการของเราภายในพ็อดจะเริ่มต้นคำสั่งการเข้าสู่ระบบให้กับลูกค้ากงสุลของเรา คำขอเข้าสู่ระบบจะรวมโทเค็นและชื่อของเราด้วย สร้างขึ้นเป็นพิเศษ วิธีการอนุญาต (ประเภท Kubernetes) ขั้นตอน #2 นี้สอดคล้องกับขั้นตอนที่ 1 ของแผนภาพกงสุล (โครงการที่ 1)
  3. ลูกค้ากงสุลของเราจะส่งต่อคำขอนี้ไปยังเซิร์ฟเวอร์กงสุลของเรา
  4. มายากล! นี่คือจุดที่เซิร์ฟเวอร์กงสุลตรวจสอบความถูกต้องของคำขอ รวบรวมข้อมูลเกี่ยวกับตัวตนของคำขอ และเปรียบเทียบกับกฎที่กำหนดไว้ล่วงหน้าที่เกี่ยวข้อง ด้านล่างนี้เป็นอีกแผนภาพหนึ่งที่แสดงให้เห็นสิ่งนี้ ขั้นตอนนี้สอดคล้องกับขั้นตอนที่ 3, 4 และ 5 ของแผนภาพภาพรวมกงสุล (แผนภาพที่ 1)
  5. เซิร์ฟเวอร์กงสุลของเราสร้างโทเค็นกงสุลพร้อมสิทธิ์ตามกฎวิธีการอนุญาตที่ระบุของเรา (ที่เรากำหนดไว้) เกี่ยวกับตัวตนของผู้ร้องขอ จากนั้นจะส่งโทเค็นนั้นกลับมา ซึ่งสอดคล้องกับขั้นตอนที่ 6 ของแผนภาพกงสุล (แผนภาพที่ 1)
  6. ลูกค้ากงสุลของเราจะส่งต่อโทเค็นไปยังแอปพลิเคชันหรือบริการที่ร้องขอ

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

ปาฏิหาริย์ถูกเปิดเผยแล้ว!

สำหรับใครที่ไม่ปลื้มแค่กระต่ายหลุดหมวกแล้วอยากรู้ว่ามันเป็นยังไง...ขอ “แสดงให้ดูว่าล้ำลึกขนาดไหน” หลุมกระต่าย'

ตามที่กล่าวไว้ข้างต้น ขั้นตอน "มหัศจรรย์" ของเรา (รูปที่ 2: ขั้นตอนที่ 4) เป็นที่ที่เซิร์ฟเวอร์กงสุลตรวจสอบสิทธิ์คำขอ รวบรวมข้อมูลคำขอ และเปรียบเทียบกับกฎที่กำหนดไว้ล่วงหน้าที่เกี่ยวข้อง ขั้นตอนนี้สอดคล้องกับขั้นตอนที่ 3, 4 และ 5 ของแผนภาพภาพรวมกงสุล (แผนภาพที่ 1) ด้านล่างนี้เป็นแผนภาพ (แผนภาพที่ 3) โดยมีจุดประสงค์เพื่อแสดงให้ชัดเจนว่าเกิดอะไรขึ้นจริง ใต้ฝากระโปรง วิธีการอนุญาต Kubernetes เฉพาะ

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

แผนภาพที่ 3: ความมหัศจรรย์ถูกเปิดเผย!

  1. ในจุดเริ่มต้น ลูกค้ากงสุลของเราจะส่งต่อคำขอเข้าสู่ระบบไปยังเซิร์ฟเวอร์กงสุลของเราด้วยโทเค็นบัญชี Kubernetes และชื่ออินสแตนซ์เฉพาะของวิธีการอนุญาตที่สร้างขึ้นก่อนหน้านี้ ขั้นตอนนี้สอดคล้องกับขั้นตอนที่ 3 ในคำอธิบายวงจรก่อนหน้านี้
  2. ขณะนี้เซิร์ฟเวอร์กงสุล (หรือผู้นำ) จำเป็นต้องตรวจสอบความถูกต้องของโทเค็นที่ได้รับ ดังนั้น จะปรึกษาคลัสเตอร์ Kubernetes (ผ่านไคลเอ็นต์กงสุล) และด้วยสิทธิ์ที่เหมาะสม เราจะตรวจสอบว่าโทเค็นเป็นของแท้และเป็นของใคร
  3. จากนั้นคำขอที่ได้รับการตรวจสอบแล้วจะถูกส่งกลับไปยังผู้นำกงสุล และเซิร์ฟเวอร์กงสุลจะค้นหาอินสแตนซ์วิธีการอนุญาตด้วยชื่อที่ระบุจากคำขอเข้าสู่ระบบ (และประเภท Kubernetes)
  4. ผู้นำกงสุลระบุอินสแตนซ์วิธีการอนุญาตที่ระบุ (หากพบ) และอ่านชุดกฎการผูกมัดที่แนบมาด้วย จากนั้นจะอ่านกฎเหล่านี้และเปรียบเทียบกับแอตทริบิวต์ข้อมูลประจำตัวที่ยืนยันแล้ว
  5. ตา-ดะ! มาดูขั้นตอนที่ 5 ในคำอธิบายวงจรก่อนหน้านี้กันดีกว่า

เรียกใช้ Consul-server บนเครื่องเสมือนปกติ

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

  • เริ่มเครื่องเสมือน (อินสแตนซ์/เซิร์ฟเวอร์)

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

  • สร้างกฎสำหรับไฟร์วอลล์ (กลุ่มความปลอดภัยใน AWS):
  • ฉันต้องการกำหนดชื่อเครื่องเดียวกันให้กับทั้งกฎและแท็กเครือข่าย ในกรณีนี้คือ "skywiz-consul-server-poc"
  • ค้นหาที่อยู่ IP ของคอมพิวเตอร์ของคุณและเพิ่มลงในรายการที่อยู่ IP ต้นทาง เพื่อให้เราสามารถเข้าถึงอินเทอร์เฟซผู้ใช้ (UI)
  • เปิดพอร์ต 8500 สำหรับ UI คลิกสร้าง เราจะเปลี่ยนไฟร์วอลล์นี้อีกครั้งเร็วๆ นี้ [ลิงค์].
  • เพิ่มกฎไฟร์วอลล์ให้กับอินสแตนซ์ กลับไปที่แดชบอร์ด VM บน Consul Server และเพิ่ม “skywiz-consul-server-poc” ลงในฟิลด์แท็กเครือข่าย คลิกบันทึก

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

  • ติดตั้ง Consul บนเครื่องเสมือน ตรวจสอบที่นี่ จำไว้ว่าคุณต้องใช้รุ่นกงสุล ≥ 1.5 [ลิงก์]
  • มาสร้างกงสุลโหนดเดียว - การกำหนดค่ามีดังนี้

groupadd --system consul
useradd -s /sbin/nologin --system -g consul consul
mkdir -p /var/lib/consul
chown -R consul:consul /var/lib/consul
chmod -R 775 /var/lib/consul
mkdir /etc/consul.d
chown -R consul:consul /etc/consul.d

  • หากต้องการคำแนะนำโดยละเอียดเพิ่มเติมเกี่ยวกับการติดตั้ง Consul และการตั้งค่าคลัสเตอร์ 3 โหนด โปรดดู ที่นี่.
  • สร้างไฟล์ /etc/consul.d/agent.json ดังนี้ [ลิงค์]:

### /etc/consul.d/agent.json
{
 "acl" : {
 "enabled": true,
 "default_policy": "deny",
 "enable_token_persistence": true
 }
}

  • เริ่มเซิร์ฟเวอร์กงสุลของเรา:

consul agent 
-server 
-ui 
-client 0.0.0.0 
-data-dir=/var/lib/consul 
-bootstrap-expect=1 
-config-dir=/etc/consul.d

  • คุณควรเห็นผลลัพธ์จำนวนมากและจบลงด้วย "... การอัปเดตถูกบล็อกโดย ACL"
  • ค้นหาที่อยู่ IP ภายนอกของเซิร์ฟเวอร์กงสุล และเปิดเบราว์เซอร์ด้วยที่อยู่ IP นี้บนพอร์ต 8500 ตรวจสอบให้แน่ใจว่า UI เปิดขึ้น
  • ลองเพิ่มคู่คีย์/ค่า จะต้องมีข้อผิดพลาด เนื่องจากเราโหลดเซิร์ฟเวอร์กงสุลด้วย ACL และปิดใช้งานกฎทั้งหมด
  • กลับไปที่เชลล์ของคุณบนเซิร์ฟเวอร์กงสุล และเริ่มกระบวนการในเบื้องหลังหรือวิธีอื่นเพื่อให้เชลล์ทำงาน และป้อนข้อมูลต่อไปนี้:

consul acl bootstrap

  • ค้นหาค่า "SecretID" และกลับสู่ UI ในแท็บ ACL ให้ป้อนรหัสลับของโทเค็นที่คุณเพิ่งคัดลอก คัดลอก SecretID ไว้ที่อื่น เราจะต้องใช้ในภายหลัง
  • ตอนนี้เพิ่มคู่คีย์/ค่า สำหรับ POC นี้ ให้เพิ่มรายการต่อไปนี้: คีย์: “custom-ns/test_key”, ค่า: “ฉันอยู่ในโฟลเดอร์ custom-ns!”

การเปิดตัวคลัสเตอร์ Kubernetes สำหรับแอปพลิเคชันของเราด้วยไคลเอนต์ Consul ในฐานะ Daemonset

  • สร้างคลัสเตอร์ K8s (Kubernetes) เราจะสร้างมันขึ้นมาในโซนเดียวกับเซิร์ฟเวอร์เพื่อการเข้าถึงที่เร็วขึ้น และเพื่อให้เราสามารถใช้ซับเน็ตเดียวกันเพื่อเชื่อมต่อกับที่อยู่ IP ภายในได้อย่างง่ายดาย เราจะเรียกมันว่า "skywiz-app-with-consul-client-poc"

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

  • โปรดทราบว่าต่อไปนี้เป็นบทช่วยสอนที่ดีที่ฉันพบขณะตั้งค่าคลัสเตอร์ POC Consul ด้วย Consul Connect
  • นอกจากนี้เรายังจะใช้แผนภูมิหางเสือของ Hashicorp พร้อมไฟล์ค่าเพิ่มเติม
  • ติดตั้งและกำหนดค่า Helm ขั้นตอนการกำหนดค่า:

kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding 
   --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --service-account=tiller
./helm update

  • แผนภูมิหางเสือ: https://www.consul.io/docs/platform/k8s/helm.html
  • ใช้ไฟล์ค่าต่อไปนี้ (หมายเหตุว่าฉันได้ปิดการใช้งานมากที่สุด):

### poc-helm-consul-values.yaml
global:
 enabled: false
 image: "consul:latest"
# Expose the Consul UI through this LoadBalancer
ui:
 enabled: false
# Allow Consul to inject the Connect proxy into Kubernetes containers
connectInject:
 enabled: false
# Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect.
client:
 enabled: true
 join: ["<PRIVATE_IP_CONSUL_SERVER>"]
 extraConfig: |
{
  "acl" : {
 "enabled": true,   
 "default_policy": "deny",   
 "enable_token_persistence": true 
  }
}
# Minimal Consul configuration. Not suitable for production.
server:
 enabled: false
# Sync Kubernetes and Consul services
syncCatalog:
 enabled: false

  • ใช้แผนภูมิหางเสือ:

./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc

  • เมื่อพยายามเรียกใช้ จะต้องมีสิทธิ์สำหรับเซิร์ฟเวอร์กงสุล ดังนั้นมาเพิ่มกัน
  • สังเกต “ช่วงที่อยู่พ็อด” ที่อยู่บนแดชบอร์ดคลัสเตอร์ และอ้างอิงกลับไปที่กฎไฟร์วอลล์ “skywiz-consul-server-poc” ของเรา
  • เพิ่มช่วงที่อยู่สำหรับพ็อดลงในรายการที่อยู่ IP และเปิดพอร์ต 8301 และ 8300

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

  • ไปที่ Consul UI และหลังจากนั้นไม่กี่นาที คุณจะเห็นคลัสเตอร์ของเราปรากฏในแท็บโหนด

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

การกำหนดค่าวิธีการอนุญาตโดยการรวมกงสุลกับ Kubernetes

  • กลับไปที่เชลล์เซิร์ฟเวอร์กงสุลและส่งออกโทเค็นที่คุณบันทึกไว้ก่อนหน้านี้:

export CONSUL_HTTP_TOKEN=<SecretID>

  • เราต้องการข้อมูลจากคลัสเตอร์ Kubernetes เพื่อสร้างอินสแตนซ์ของวิธีการรับรองความถูกต้อง:
  • kubernetes-โฮสต์

kubectl get endpoints | grep kubernetes

  • kubernetes-บริการบัญชี-jwt

kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "- name:"
kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:

  • โทเค็นมีการเข้ารหัส base64 ดังนั้นถอดรหัสโดยใช้เครื่องมือที่คุณชื่นชอบ [ลิงค์]
  • kubernetes-ca-cert

kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:

  • นำใบรับรอง “ca.crt” (หลังจากการถอดรหัส base64) แล้วเขียนลงในไฟล์ “ca.crt”
  • ตอนนี้สร้างอินสแตนซ์ของวิธีการรับรองความถูกต้องโดยแทนที่ตัวยึดตำแหน่งด้วยค่าที่คุณเพิ่งได้รับ

consul acl auth-method create 
-type "kubernetes" 
-name "auth-method-skywiz-consul-poc" 
-description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc" 
-kubernetes-host "<k8s_endpoint_retrieved earlier>" 
[email protected] 
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"

  • ต่อไปเราต้องสร้างกฎและแนบไปกับบทบาทใหม่ ในส่วนนี้คุณสามารถใช้ Consul UI ได้ แต่เราจะใช้บรรทัดคำสั่ง
  • เขียนกฎ

### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
 policy = "write"
}

  • ใช้กฎ

consul acl policy create 
-name kv-custom-ns-policy 
-description "This is an example policy for kv at custom-ns/" 
-rules @kv-custom-ns-policy.hcl

  • ค้นหา ID ของกฎที่คุณเพิ่งสร้างจากเอาต์พุต
  • สร้างบทบาทด้วยกฎใหม่

consul acl role create 
-name "custom-ns-role" 
-description "This is an example role for custom-ns namespace" 
-policy-id <policy_id>

  • ตอนนี้เราจะเชื่อมโยงบทบาทใหม่ของเรากับอินสแตนซ์วิธีการรับรองความถูกต้อง โปรดทราบว่าธง "ตัวเลือก" จะกำหนดว่าคำขอเข้าสู่ระบบของเราจะได้รับบทบาทนี้หรือไม่ ตรวจสอบตัวเลือกตัวเลือกอื่นๆ ที่นี่: https://www.consul.io/docs/acl/auth-methods/kubernetes.html#trusted-identity-attributes

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-ns-role' 
-selector='serviceaccount.namespace=="custom-ns"'

สุดท้ายนี้การกำหนดค่า

สิทธิ์การเข้าถึง

  • สร้างสิทธิ์การเข้าถึง เราจำเป็นต้องให้สิทธิ์กงสุลในการตรวจสอบและระบุตัวตนของโทเค็นบัญชีบริการ K8
  • เขียนสิ่งต่อไปนี้ลงในไฟล์ [ลิงค์]:

###skywiz-poc-consul-server_rbac.yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: review-tokens
 namespace: default
subjects:
- kind: ServiceAccount
 name: skywiz-app-with-consul-client-poc-consul-client
 namespace: default
roleRef:
 kind: ClusterRole
 name: system:auth-delegator
 apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: service-account-getter
 namespace: default
rules:
- apiGroups: [""]
 resources: ["serviceaccounts"]
 verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: get-service-accounts
 namespace: default
subjects:
- kind: ServiceAccount
 name: skywiz-app-with-consul-client-poc-consul-client
 namespace: default
roleRef:
 kind: ClusterRole
 name: service-account-getter
 apiGroup: rbac.authorization.k8s.io

  • มาสร้างสิทธิ์การเข้าถึงกันเถอะ

kubectl create -f skywiz-poc-consul-server_rbac.yaml

กำลังเชื่อมต่อกับลูกค้ากงสุล

  • ตามที่ระบุไว้ ที่นี่มีหลายตัวเลือกสำหรับการเชื่อมต่อกับ daemonset แต่เรามาดูวิธีแก้ปัญหาง่ายๆ ต่อไปนี้:
  • ใช้ไฟล์ต่อไปนี้ [ลิงค์].

### poc-consul-client-ds-svc.yaml
apiVersion: v1
kind: Service
metadata:
 name: consul-ds-client
spec:
 selector:
   app: consul
   chart: consul-helm
   component: client
   hasDNS: "true"
   release: skywiz-app-with-consul-client-poc
 ports:
 - protocol: TCP
   port: 80
   targetPort: 8500

  • จากนั้นใช้คำสั่งบิวด์อินต่อไปนี้เพื่อสร้าง configmap [ลิงค์] โปรดทราบว่าเรากำลังหมายถึงชื่อของบริการของเรา โปรดเปลี่ยนใหม่หากจำเป็น

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
 labels:
   addonmanager.kubernetes.io/mode: EnsureExists
 name: kube-dns
 namespace: kube-system
data:
 stubDomains: |
   {"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]}
EOF

ทดสอบวิธีการรับรองความถูกต้อง

มาดูการทำงานของเวทมนตร์กัน!

  • สร้างโฟลเดอร์คีย์เพิ่มเติมอีกหลายโฟลเดอร์ด้วยคีย์ระดับบนสุดเดียวกัน (เช่น /sample_key) และค่าที่คุณเลือก สร้างนโยบายและบทบาทที่เหมาะสมสำหรับเส้นทางหลักใหม่ เราจะทำการผูกในภายหลัง

ข้อมูลเบื้องต้นเกี่ยวกับการอนุญาต Kubernetes ของ Hashicorp Consul

การทดสอบเนมสเปซที่กำหนดเอง:

  • มาสร้างเนมสเปซของเราเองกันดีกว่า:

kubectl create namespace custom-ns

  • มาสร้างพ็อดในเนมสเปซใหม่ของเรากันดีกว่า เขียนการกำหนดค่าสำหรับพ็อด

###poc-ubuntu-custom-ns.yaml
apiVersion: v1
kind: Pod
metadata:
 name: poc-ubuntu-custom-ns
 namespace: custom-ns
spec:
 containers:
 - name: poc-ubuntu-custom-ns
   image: ubuntu
   command: ["/bin/bash", "-ec", "sleep infinity"]
 restartPolicy: Never

  • สร้างภายใต้:

kubectl create -f poc-ubuntu-custom-ns.yaml

  • เมื่อคอนเทนเนอร์ทำงานแล้ว ให้ไปที่นั่นและติดตั้ง curl

kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y

  • ตอนนี้เราจะส่งคำขอเข้าสู่ระบบไปยังกงสุลโดยใช้วิธีการอนุญาตที่เราสร้างไว้ก่อนหน้านี้ [ลิงค์].
  • หากต้องการดูโทเค็นที่ป้อนจากบัญชีบริการของคุณ:

cat /run/secrets/kubernetes.io/serviceaccount/token

  • เขียนสิ่งต่อไปนี้ลงในไฟล์ภายในคอนเทนเนอร์:

### payload.json
{
 "AuthMethod": "auth-method-test",
 "BearerToken": "<jwt_token>"
}

  • เข้าสู่ระบบ!

curl 
--request POST 
--data @payload.json 
consul-ds-client.default.svc.cluster.local/v1/acl/login

  • หากต้องการทำตามขั้นตอนข้างต้นให้เสร็จสิ้นในบรรทัดเดียว (เนื่องจากเราจะทำการทดสอบหลายรายการ) คุณสามารถทำสิ่งต่อไปนี้:

echo "{ 
"AuthMethod": "auth-method-skywiz-consul-poc", 
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)" 
}" 
| curl 
--request POST 
--data @- 
consul-ds-client.default.svc.cluster.local/v1/acl/login

  • ได้ผล! อย่างน้อยก็ควร ตอนนี้รับ SecretID แล้วลองเข้าถึงคีย์/ค่าที่เราควรเข้าถึง

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”

  • คุณสามารถถอดรหัส "ค่า" base64 และดูว่าตรงกับค่าใน custom-ns/test_key ใน UI หากคุณใช้ค่าเดียวกันข้างต้นในบทช่วยสอนนี้ ค่าที่เข้ารหัสของคุณจะเป็น IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi

การทดสอบบัญชีบริการผู้ใช้:

  • สร้าง ServiceAccount แบบกำหนดเองโดยใช้คำสั่งต่อไปนี้ [ลิงค์].

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: custom-sa
EOF

  • สร้างไฟล์การกำหนดค่าใหม่สำหรับพ็อด โปรดทราบว่าฉันได้รวมการติดตั้ง curl เพื่อประหยัดแรงงาน :)

###poc-ubuntu-custom-sa.yaml
apiVersion: v1
kind: Pod
metadata:
 name: poc-ubuntu-custom-sa
 namespace: default
spec:
 serviceAccountName: custom-sa
 containers:
 - name: poc-ubuntu-custom-sa
   image: ubuntu
   command: ["/bin/bash","-ec"]
   args: ["apt-get update && apt-get install curl -y; sleep infinity"]
 restartPolicy: Never

  • หลังจากนั้นให้รันเชลล์ภายในคอนเทนเนอร์

kubectl exec -it poc-ubuntu-custom-sa /bin/bash

  • เข้าสู่ระบบ!

echo "{ 
"AuthMethod": "auth-method-skywiz-consul-poc", 
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)" 
}" 
| curl 
--request POST 
--data @- 
consul-ds-client.default.svc.cluster.local/v1/acl/login

  • การอนุญาตถูกปฏิเสธ โอ้ เราลืมเพิ่มกฎใหม่ที่เชื่อมโยงกับสิทธิ์ที่เหมาะสม เรามาดำเนินการกันตอนนี้เลย

ทำซ้ำขั้นตอนก่อนหน้าข้างต้น:
ก) สร้างนโยบายที่เหมือนกันสำหรับคำนำหน้า “custom-sa/”
b) สร้างบทบาท เรียกว่า "บทบาทที่กำหนดเอง"
c) แนบนโยบายเข้ากับบทบาท

  • สร้างการเชื่อมโยงกฎ (ทำได้จาก cli/api เท่านั้น) สังเกตความหมายที่แตกต่างกันของแฟล็กตัวเลือก

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='custom-sa-role' 
-selector='serviceaccount.name=="custom-sa"'

  • เข้าสู่ระบบอีกครั้งจากคอนเทนเนอร์ "poc-ubuntu-custom-sa" ความสำเร็จ!
  • ตรวจสอบการเข้าถึงเส้นทาง custom-sa/ ของเรา

curl 
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”

  • คุณยังมั่นใจได้ว่าโทเค็นนี้ไม่ได้ให้สิทธิ์การเข้าถึง kv ใน "custom-ns/" เพียงทำซ้ำคำสั่งข้างต้นหลังจากแทนที่ "custom-sa" ด้วยคำนำหน้า "custom-ns"
    ปฏิเสธการอนุญาต

ตัวอย่างการซ้อนทับ:

  • เป็นที่น่าสังเกตว่าการแมปที่ผูกกฎทั้งหมดจะถูกเพิ่มลงในโทเค็นด้วยสิทธิ์เหล่านี้
  • คอนเทนเนอร์ "poc-ubuntu-custom-sa" ของเราอยู่ในเนมสเปซเริ่มต้น - ดังนั้นเรามาใช้สำหรับการเชื่อมโยงกฎอื่นกัน
  • ทำซ้ำขั้นตอนก่อนหน้า:
    ก) สร้างนโยบายที่เหมือนกันสำหรับคำนำหน้าคีย์ "default/"
    b) สร้างบทบาท ตั้งชื่อเป็น "default-ns-role"
    c) แนบนโยบายเข้ากับบทบาท
  • สร้างการเชื่อมโยงกฎ (ทำได้จาก cli/api เท่านั้น)

consul acl binding-rule create 
-method=auth-method-skywiz-consul-poc 
-bind-type=role 
-bind-name='default-ns-role' 
-selector='serviceaccount.namespace=="default"'

  • กลับไปที่คอนเทนเนอร์ "poc-ubuntu-custom-sa" ของเราแล้วลองเข้าถึงเส้นทาง "default/" kv
  • ปฏิเสธการอนุญาต
    คุณสามารถดูข้อมูลประจำตัวที่ระบุสำหรับแต่ละโทเค็นได้ใน UI ภายใต้ ACL > โทเค็น อย่างที่คุณเห็น โทเค็นปัจจุบันของเรามีเพียง "บทบาทที่กำหนดเอง" แนบอยู่เพียงอันเดียวเท่านั้น โทเค็นที่เราใช้อยู่ในปัจจุบันถูกสร้างขึ้นเมื่อเราเข้าสู่ระบบ และมีเพียงการเชื่อมโยงกฎเดียวที่ตรงกันในขณะนั้น เราจำเป็นต้องเข้าสู่ระบบอีกครั้งและใช้โทเค็นใหม่
  • ตรวจสอบให้แน่ใจว่าคุณสามารถอ่านได้จากทั้งเส้นทาง "custom-sa/" และ "default/" kv
    ที่ประสบความสำเร็จ!
    นี่เป็นเพราะว่า "poc-ubuntu-custom-sa" ของเราตรงกับการเชื่อมโยงกฎ "custom-sa" และ "default-ns"

ข้อสรุป

การจัดการโทเค็น TTL?

ในขณะที่เขียนบทความนี้ ยังไม่มีวิธีบูรณาการในการกำหนด TTL สำหรับโทเค็นที่สร้างโดยวิธีการอนุญาตนี้ มันจะเป็นโอกาสอันดีที่จะจัดให้มีการอนุมัติกงสุลโดยอัตโนมัติอย่างปลอดภัย

มีตัวเลือกในการสร้างโทเค็นด้วย TTL ด้วยตนเอง:

หวังว่าในอนาคตอันใกล้นี้ เราจะสามารถควบคุมวิธีการสร้างโทเค็นได้ (ต่อกฎหรือวิธีการอนุญาต) และเพิ่ม TTL

จนกว่าจะถึงตอนนั้น ขอแนะนำให้คุณใช้จุดสิ้นสุดการออกจากระบบในตรรกะของคุณ

อ่านบทความอื่น ๆ ในบล็อกของเราด้วย:

ที่มา: will.com

เพิ่มความคิดเห็น