ການແນະນໍາການອະນຸຍາດ Kubernetes ຂອງກົງສຸນ Hashicorp

ນັ້ນແມ່ນ, ຫຼັງຈາກປ່ອຍ ກົງສຸນ Hashicorp 1.5.0 ໃນຕອນຕົ້ນຂອງເດືອນພຶດສະພາ 2019, ໃນ Consul ທ່ານສາມາດອະນຸຍາດໃຫ້ຄໍາຮ້ອງສະຫມັກແລະການບໍລິການທີ່ເຮັດວຽກຢູ່ໃນ Kubernetes ໂດຍກໍາເນີດ.

ໃນ tutorial ນີ້ພວກເຮົາຈະສ້າງຂັ້ນຕອນໂດຍຂັ້ນຕອນ POC (ຫຼັກຖານສະແດງແນວຄວາມຄິດ, PoC) ສະແດງໃຫ້ເຫັນຄຸນສົມບັດໃຫມ່ນີ້. ຄາດວ່າຈະມີຄວາມຮູ້ພື້ນຖານຂອງ Kubernetes ແລະກົງສຸນຂອງ Hashicorp. ໃນຂະນະທີ່ທ່ານສາມາດນໍາໃຊ້ທຸກເວທີຄລາວຫຼືສະພາບແວດລ້ອມໃນພື້ນທີ່, ໃນບົດສອນນີ້ພວກເຮົາຈະໃຊ້ Google's Cloud Platform.

ພາບລວມ

ຖ້າພວກເຮົາໄປ ເອກະສານ Consul ກ່ຽວກັບວິທີການອະນຸຍາດຂອງຕົນ, ພວກເຮົາຈະໄດ້ຮັບພາບລວມໄວກ່ຽວກັບຈຸດປະສົງແລະກໍລະນີການນໍາໃຊ້ຂອງມັນ, ເຊັ່ນດຽວກັນກັບບາງລາຍລະອຽດດ້ານວິຊາການແລະສະພາບລວມທົ່ວໄປຂອງເຫດຜົນ. ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ອ່ານມັນຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງກ່ອນທີ່ຈະດໍາເນີນການ, ເພາະວ່າຕອນນີ້ຂ້ອຍຈະອະທິບາຍແລະ chewing ມັນທັງຫມົດ.

ແຜນວາດທີ 1: ພາບລວມຢ່າງເປັນທາງການຂອງວິທີການອະນຸຍາດກົງສຸນ

ໃຫ້ເບິ່ງໃນ ເອກະສານສໍາລັບວິທີການອະນຸຍາດ Kubernetes ສະເພາະ.

ແນ່ນອນ, ມີຂໍ້ມູນທີ່ເປັນປະໂຫຍດຢູ່ທີ່ນັ້ນ, ແຕ່ບໍ່ມີຄໍາແນະນໍາກ່ຽວກັບວິທີການນໍາໃຊ້ມັນທັງຫມົດ. ດັ່ງ​ນັ້ນ, ເຊັ່ນ​ດຽວ​ກັບ​ຄົນ​ທີ່​ມີ​ສຸ​ຂະ​ພາບ, ທ່ານ scour ອິນ​ເຕີ​ເນັດ​ສໍາ​ລັບ​ການ​ຊີ້​ນໍາ. ແລະຫຼັງຈາກນັ້ນ ... ເຈົ້າລົ້ມເຫລວ. ມັນ​ເກີດ​ຂື້ນ. ໃຫ້ແກ້ໄຂນີ້.

ກ່ອນທີ່ພວກເຮົາຈະກ້າວໄປສູ່ການສ້າງ POC ຂອງພວກເຮົາ, ໃຫ້ກັບຄືນໄປຫາພາບລວມຂອງວິທີການອະນຸຍາດຂອງກົງສຸນ (ແຜນວາດ 1) ແລະປັບປຸງມັນໃນສະພາບການຂອງ Kubernetes.

ຖາປັດຕະຍະ

ໃນບົດສອນນີ້, ພວກເຮົາຈະສ້າງເຄື່ອງແມ່ຂ່າຍ Consul ໃນເຄື່ອງແຍກຕ່າງຫາກທີ່ຈະຕິດຕໍ່ສື່ສານກັບກຸ່ມ Kubernetes ກັບລູກຄ້າ Consul ຕິດຕັ້ງ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະສ້າງຄໍາຮ້ອງສະຫມັກ dummy ຂອງພວກເຮົາໃນຝັກແລະນໍາໃຊ້ວິທີການກໍານົດການອະນຸຍາດຂອງພວກເຮົາເພື່ອອ່ານຈາກ Consul key / value store ຂອງພວກເຮົາ.

ແຜນວາດຂ້າງລຸ່ມນີ້ລາຍລະອຽດກ່ຽວກັບສະຖາປັດຕະຍະກໍາທີ່ພວກເຮົາກໍາລັງສ້າງຢູ່ໃນບົດສອນນີ້, ເຊັ່ນດຽວກັນກັບເຫດຜົນທາງຫລັງຂອງວິທີການອະນຸຍາດ, ເຊິ່ງຈະຖືກອະທິບາຍໃນພາຍຫລັງ.

ແຜນວາດ 2: ລາຍລະອຽດວິທີການອະນຸຍາດ Kubernetes

ບັນທຶກດ່ວນ: ເຊີບເວີ Consul ບໍ່ຈໍາເປັນຕ້ອງອາໄສຢູ່ນອກກຸ່ມ Kubernetes ເພື່ອໃຫ້ມັນເຮັດວຽກໄດ້. ແຕ່ແມ່ນແລ້ວ, ລາວສາມາດເຮັດໄດ້ດ້ວຍວິທີນີ້ແລະແບບນັ້ນ.

ດັ່ງນັ້ນ, ເອົາແຜນວາດພາບລວມຂອງກົງສຸນ (ແຜນຜັງ 1) ແລະນໍາໃຊ້ Kubernetes ກັບມັນ, ພວກເຮົາໄດ້ຮັບແຜນວາດຂ້າງເທິງ (ແຜນວາດ 2), ແລະເຫດຜົນໃນທີ່ນີ້ແມ່ນດັ່ງຕໍ່ໄປນີ້:

1. ແຕ່ລະຝັກຈະມີບັນຊີບໍລິການທີ່ຕິດຢູ່ກັບມັນທີ່ປະກອບມີ token JWT ທີ່ສ້າງຂຶ້ນ ແລະຮູ້ຈັກໂດຍ Kubernetes. ໂທເຄັນນີ້ຖືກໃສ່ໃສ່ໃນພອດຕາມຄ່າເລີ່ມຕົ້ນ.
2. ຄໍາຮ້ອງສະຫມັກຫຼືການບໍລິການຂອງພວກເຮົາພາຍໃນຝັກເລີ່ມຕົ້ນຄໍາສັ່ງເຂົ້າສູ່ລະບົບໃຫ້ກັບລູກຄ້າ Consul ຂອງພວກເຮົາ. ການຮ້ອງຂໍການເຂົ້າສູ່ລະບົບຈະປະກອບມີ token ແລະຊື່ຂອງພວກເຮົາ ສ້າງເປັນພິເສດ ວິທີການອະນຸຍາດ (ປະເພດ Kubernetes). ຂັ້ນ​ຕອນ​ທີ 2 ນີ້​ກົງ​ກັບ​ຂັ້ນ​ຕອນ​ທີ 1 ຂອງ​ແຜນ​ວາດ Consul (ໂຄງ​ການ 1).
3. ລູກຄ້າ Consul ຂອງພວກເຮົາຈະສົ່ງຕໍ່ຄໍາຮ້ອງຂໍນີ້ໄປຫາເຄື່ອງແມ່ຂ່າຍ Consul ຂອງພວກເຮົາ.
4. MAGIC! ນີ້ແມ່ນບ່ອນທີ່ເຄື່ອງແມ່ຂ່າຍ Consul ກວດສອບຄວາມຖືກຕ້ອງຂອງຄໍາຮ້ອງຂໍ, ເກັບກໍາຂໍ້ມູນກ່ຽວກັບຕົວຕົນຂອງຄໍາຮ້ອງຂໍແລະປຽບທຽບມັນກັບກົດລະບຽບທີ່ກໍານົດໄວ້ກ່ອນທີ່ກ່ຽວຂ້ອງ. ຂ້າງລຸ່ມນີ້ແມ່ນແຜນວາດອື່ນເພື່ອສະແດງໃຫ້ເຫັນເລື່ອງນີ້. ຂັ້ນຕອນນີ້ກົງກັບຂັ້ນຕອນທີ 3, 4 ແລະ 5 ຂອງແຜນວາດພາບລວມຂອງກົງສຸນ (ແຜນວາດທີ 1).
5. ເຊີບເວີ Consul ຂອງພວກເຮົາສ້າງ Consul token ດ້ວຍການອະນຸຍາດຕາມກົດລະບຽບວິທີການອະນຸຍາດຂອງພວກເຮົາ (ທີ່ພວກເຮົາໄດ້ກໍານົດ) ກ່ຽວກັບຕົວຕົນຂອງຜູ້ຮ້ອງຂໍ. ຫຼັງຈາກນັ້ນມັນຈະສົ່ງ token ນີ້ຄືນ. ນີ້ກົງກັບຂັ້ນຕອນທີ 6 ຂອງແຜນວາດກົງສຸນ (ແຜນວາດທີ 1).
6. ລູກຄ້າ Consul ຂອງພວກເຮົາສົ່ງ token ໄປຫາຄໍາຮ້ອງສະຫມັກຫຼືການບໍລິການທີ່ຮ້ອງຂໍ.

ແອັບພລິເຄຊັນ ຫຼືບໍລິການຂອງພວກເຮົາຕອນນີ້ສາມາດໃຊ້ໂທເຄັນ Consul ນີ້ເພື່ອຕິດຕໍ່ສື່ສານກັບຂໍ້ມູນ Consul ຂອງພວກເຮົາ, ຕາມທີ່ກຳນົດໂດຍສິດທິພິເສດຂອງ token.

ວິເສດຖືກເປີດເຜີຍ!

ສຳລັບທ່ານໃດທີ່ບໍ່ພໍໃຈກັບພຽງແຕ່ກະຕ່າຍອອກຈາກໝວກ ແລະຢາກຮູ້ວ່າມັນເຮັດວຽກແນວໃດ... ໃຫ້ຂ້ອຍເບິ່ງວ່າ ເລິກຊຶ້ງປານໃດ ຂຸມກະຕ່າຍ".

ດັ່ງທີ່ໄດ້ກ່າວມາກ່ອນຫນ້ານີ້, ຂັ້ນຕອນ "magic" ຂອງພວກເຮົາ (ຮູບ 2: ຂັ້ນຕອນທີ 4) ແມ່ນບ່ອນທີ່ເຄື່ອງແມ່ຂ່າຍຂອງ Consul ຢືນຢັນຄໍາຮ້ອງຂໍ, ເກັບກໍາຂໍ້ມູນການຮ້ອງຂໍ, ແລະປຽບທຽບມັນກັບກົດລະບຽບທີ່ກໍານົດໄວ້ກ່ອນທີ່ກ່ຽວຂ້ອງ. ຂັ້ນຕອນນີ້ກົງກັບຂັ້ນຕອນທີ 3, 4 ແລະ 5 ຂອງແຜນວາດພາບລວມຂອງກົງສຸນ (ແຜນວາດທີ 1). ຂ້າງລຸ່ມນີ້ແມ່ນແຜນວາດ (ແຜນວາດ 3), ຈຸດປະສົງແມ່ນເພື່ອສະແດງໃຫ້ເຫັນຢ່າງຊັດເຈນວ່າສິ່ງທີ່ເກີດຂຶ້ນຈິງ ພາຍໃຕ້ Hood ໄດ້ ວິທີການອະນຸຍາດ Kubernetes ສະເພາະ.

ແຜນວາດທີ 3: ຄວາມວິເສດຖືກເປີດເຜີຍ!

1. ເປັນຈຸດເລີ່ມຕົ້ນ, ລູກຄ້າ Consul ຂອງພວກເຮົາສົ່ງຕໍ່ຄໍາຮ້ອງຂໍເຂົ້າສູ່ລະບົບໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງ Consul ຂອງພວກເຮົາດ້ວຍ token ບັນຊີ Kubernetes ແລະຊື່ສະເພາະຂອງວິທີການອະນຸຍາດທີ່ຖືກສ້າງຂື້ນກ່ອນຫນ້ານີ້. ຂັ້ນຕອນນີ້ກົງກັບຂັ້ນຕອນທີ 3 ໃນຄໍາອະທິບາຍວົງຈອນທີ່ຜ່ານມາ.
2. ໃນປັດຈຸບັນເຄື່ອງແມ່ຂ່າຍຂອງ Consul (ຫຼືຜູ້ນໍາ) ຈໍາເປັນຕ້ອງກວດສອບຄວາມຖືກຕ້ອງຂອງ token ທີ່ໄດ້ຮັບ. ດັ່ງນັ້ນ, ມັນຈະປຶກສາຫາລືກັບກຸ່ມ Kubernetes (ຜ່ານລູກຄ້າ Consul) ແລະ, ດ້ວຍການອະນຸຍາດທີ່ເຫມາະສົມ, ພວກເຮົາຈະຊອກຫາວ່າ token ເປັນຂອງແທ້ຫຼືບໍ່ແລະມັນແມ່ນຂອງໃຜ.
3. ຫຼັງຈາກນັ້ນ, ຄໍາຮ້ອງຂໍທີ່ຖືກຕ້ອງຖືກສົ່ງກັບຄືນໄປຫາຜູ້ນໍາ Consul, ແລະເຄື່ອງແມ່ຂ່າຍຂອງ Consul ຊອກຫາຕົວຢ່າງວິທີການອະນຸຍາດທີ່ມີຊື່ທີ່ລະບຸໄວ້ຈາກຄໍາຮ້ອງຂໍເຂົ້າສູ່ລະບົບ (ແລະປະເພດ Kubernetes).
4. ຜູ້ນໍາກົງສຸນກໍານົດວິທີການອະນຸຍາດທີ່ກໍານົດໄວ້ (ຖ້າພົບເຫັນ) ແລະອ່ານກົດລະບຽບການຜູກມັດທີ່ຕິດກັບມັນ. ຫຼັງຈາກນັ້ນມັນອ່ານກົດລະບຽບເຫຼົ່ານີ້ແລະປຽບທຽບພວກມັນກັບຄຸນລັກສະນະຂອງຕົວຕົນທີ່ຖືກຢືນຢັນ.
5. ດ່າ! ໃຫ້ກ້າວໄປສູ່ຂັ້ນຕອນທີ 5 ໃນຄໍາອະທິບາຍວົງຈອນທີ່ຜ່ານມາ.

ແລ່ນ Consul-server ໃນເຄື່ອງ virtual ປົກກະຕິ

ຈາກນີ້ໄປ, ສ່ວນຫຼາຍຂ້ອຍຈະໃຫ້ຄໍາແນະນໍາກ່ຽວກັບວິທີການສ້າງ POC ນີ້, ມັກຈະຢູ່ໃນຈຸດ bullet, ໂດຍບໍ່ມີຄໍາອະທິບາຍເຕັມປະໂຫຍກ. ນອກຈາກນີ້, ດັ່ງທີ່ໄດ້ລະບຸໄວ້ກ່ອນຫນ້ານີ້, ຂ້ອຍຈະໃຊ້ GCP ເພື່ອສ້າງໂຄງສ້າງພື້ນຖານທັງຫມົດ, ແຕ່ທ່ານສາມາດສ້າງໂຄງສ້າງພື້ນຖານດຽວກັນຢູ່ບ່ອນອື່ນ.

• ເລີ່ມເຄື່ອງ virtual (ຕົວຢ່າງ/ເຊີບເວີ).

• ສ້າງກົດລະບຽບສໍາລັບ firewall (ກຸ່ມຄວາມປອດໄພໃນ AWS):
• ຂ້ອຍມັກກໍານົດຊື່ເຄື່ອງດຽວກັນກັບທັງກົດລະບຽບແລະແທັກເຄືອຂ່າຍ, ໃນກໍລະນີນີ້ "skywiz-consul-server-poc".
• ຊອກຫາທີ່ຢູ່ IP ຂອງຄອມພິວເຕີທ້ອງຖິ່ນຂອງທ່ານແລະເພີ່ມມັນໃສ່ບັນຊີລາຍຊື່ຂອງທີ່ຢູ່ IP ແຫຼ່ງດັ່ງນັ້ນພວກເຮົາສາມາດເຂົ້າເຖິງສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ (UI).
• ເປີດພອດ 8500 ສໍາລັບ UI. ກົດ ສ້າງ. ພວກເຮົາຈະປ່ຽນ firewall ນີ້ອີກເທື່ອຫນຶ່ງໃນໄວໆນີ້ [ຫນ້າທໍາອິດ].
• ເພີ່ມກົດລະບຽບໄຟວໍໃສ່ຕົວຢ່າງ. ກັບຄືນໄປຫາ dashboard VM ໃນ Consul Server ແລະເພີ່ມ "skywiz-consul-server-poc" ໃສ່ຊ່ອງແທັກເຄືອຂ່າຍ. ກົດ Save.

• ຕິດຕັ້ງ Consul ໃນເຄື່ອງ virtual, ກວດເບິ່ງທີ່ນີ້. ຈື່ໄວ້ວ່າທ່ານຕ້ອງການ Consul version ≥ 1.5 [link]
• ໃຫ້ສ້າງ node Consul ດຽວ - ການຕັ້ງຄ່າແມ່ນດັ່ງຕໍ່ໄປນີ້.

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 ແລະການຕັ້ງຄ່າ cluster ຂອງ 3 nodes, ເບິ່ງ ທີ່ນີ້.
• ສ້າງໄຟລ໌ /etc/consul.d/agent.json ດັ່ງຕໍ່ໄປນີ້ [ຫນ້າທໍາອິດ]:

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

• ເລີ່ມເຊີບເວີ Consul ຂອງພວກເຮົາ:

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

• ທ່ານຄວນເບິ່ງຜົນໄດ້ຮັບຫຼາຍແລະສິ້ນສຸດດ້ວຍ "... ການປັບປຸງທີ່ຖືກບລັອກໂດຍ ACLs."
• ຊອກຫາທີ່ຢູ່ IP ພາຍນອກຂອງເຊີບເວີ Consul ແລະເປີດຕົວທ່ອງເວັບທີ່ມີທີ່ຢູ່ IP ນີ້ຢູ່ໃນພອດ 8500. ໃຫ້ແນ່ໃຈວ່າ UI ເປີດ.
• ລອງເພີ່ມຄູ່ຄີ/ຄ່າ. ຕ້ອງມີຄວາມຜິດພາດ. ນີ້ແມ່ນຍ້ອນວ່າພວກເຮົາໄດ້ໂຫລດເຄື່ອງແມ່ຂ່າຍຂອງ Consul ດ້ວຍ ACL ແລະປິດກົດລະບຽບທັງຫມົດ.
• ກັບຄືນໄປຫາ Shell ຂອງທ່ານໃນເຊີບເວີ Consul ແລະເລີ່ມຕົ້ນຂະບວນການໃນພື້ນຫລັງຫຼືບາງວິທີອື່ນເພື່ອໃຫ້ມັນແລ່ນແລະໃສ່ຕໍ່ໄປນີ້:

consul acl bootstrap

• ຊອກຫາຄ່າ "SecretID" ແລະກັບຄືນໄປຫາ UI. ໃນແຖບ ACL, ໃສ່ລະຫັດລັບຂອງ token ທີ່ເຈົ້າຫາກໍ່ສຳເນົາ. ສຳເນົາ SecretID ໄປບ່ອນອື່ນ, ພວກເຮົາຈະຕ້ອງການມັນໃນພາຍຫຼັງ.
• ຕອນນີ້ເພີ່ມຄູ່ຄີ/ຄ່າ. ສໍາລັບ POC ນີ້, ໃຫ້ເພີ່ມສິ່ງຕໍ່ໄປນີ້: key: “custom-ns/test_key”, ຄ່າ: “ຂ້ອຍຢູ່ໃນໂຟເດີ custom-ns!”

ການເປີດຕົວກຸ່ມ Kubernetes ສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາກັບລູກຄ້າ Consul ເປັນ Daemonset

• ສ້າງກຸ່ມ K8s (Kubernetes). ພວກເຮົາຈະສ້າງມັນຢູ່ໃນເຂດດຽວກັນກັບເຄື່ອງແມ່ຂ່າຍສໍາລັບການເຂົ້າເຖິງໄວ, ແລະດັ່ງນັ້ນພວກເຮົາສາມາດນໍາໃຊ້ subnet ດຽວກັນເພື່ອເຊື່ອມຕໍ່ໄດ້ຢ່າງງ່າຍດາຍກັບທີ່ຢູ່ IP ພາຍໃນ. ພວກເຮົາຈະເອີ້ນມັນວ່າ "skywiz-app-with-consul-client-poc".

• ໃນຖານະເປັນບັນທຶກຂ້າງຄຽງ, ນີ້ແມ່ນການສອນທີ່ດີທີ່ຂ້ອຍພົບໃນຂະນະທີ່ຕັ້ງກຸ່ມ 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

• ເມື່ອມັນພະຍາຍາມແລ່ນ, ມັນຈະຕ້ອງການການອະນຸຍາດສໍາລັບເຄື່ອງແມ່ຂ່າຍຂອງ Consul, ດັ່ງນັ້ນໃຫ້ພວກເຮົາເພີ່ມພວກມັນ.
• ໃຫ້ສັງເກດ “ໄລຍະທີ່ຢູ່ Pod” ທີ່ຕັ້ງຢູ່ໃນ dashboard ຂອງກຸ່ມ ແລະສົ່ງກັບຄືນໄປຫາກົດລະບຽບໄຟວໍຂອງພວກເຮົາ “skywiz-consul-server-poc”.
• ເພີ່ມຊ່ວງທີ່ຢູ່ສຳລັບພອດໃສ່ລາຍຊື່ທີ່ຢູ່ IP ແລະເປີດພອດ 8301 ແລະ 8300.

• ໄປທີ່ Consul UI ແລະຫຼັງຈາກສອງສາມນາທີທ່ານຈະເຫັນກຸ່ມຂອງພວກເຮົາປາກົດຢູ່ໃນແຖບ nodes.

ການຕັ້ງຄ່າວິທີການອະນຸຍາດໂດຍການລວມກົງສຸນກັບ Kubernetes

• ກັບຄືນໄປຫາ Consul server shell ແລະສົ່ງອອກ token ທີ່ທ່ານບັນທຶກໄວ້ກ່ອນຫນ້ານີ້:

export CONSUL_HTTP_TOKEN=<SecretID>

• ພວກເຮົາຈະຕ້ອງການຂໍ້ມູນຈາກກຸ່ມ Kubernetes ຂອງພວກເຮົາເພື່ອສ້າງຕົວຢ່າງຂອງວິທີການກວດສອບຄວາມຖືກຕ້ອງ:
• kubernetes-ເຈົ້າພາບ

kubectl get endpoints | grep kubernetes

• kubernetes-service-account-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:

• token ແມ່ນເຂົ້າລະຫັດ base64, ສະນັ້ນ decrypt ມັນໂດຍໃຊ້ເຄື່ອງມືທີ່ທ່ານມັກ [ຫນ້າທໍາອິດ]
• 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"'

ສຸດ​ທ້າຍ​ການ​ຕັ້ງ​ຄ່າ​

ສິດທິໃນການເຂົ້າເຖິງ

• ສ້າງສິດການເຂົ້າເຖິງ. ພວກເຮົາຈໍາເປັນຕ້ອງໃຫ້ Consul ອະນຸຍາດໃຫ້ກວດສອບແລະລະບຸຕົວຕົນຂອງ token ບັນຊີບໍລິການ K8s.
• ຂຽນຕໍ່ໄປນີ້ໃສ່ໄຟລ໌ [link]:

###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

ການເຊື່ອມຕໍ່ກັບລູກຄ້າ Consul

• ດັ່ງທີ່ບັນທຶກໄວ້ ທີ່ນີ້ມີຫຼາຍທາງເລືອກໃນການເຊື່ອມຕໍ່ກັບ 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

• ຫຼັງຈາກນັ້ນ, ໃຊ້ຄໍາສັ່ງ buildin ຕໍ່ໄປນີ້ເພື່ອສ້າງ 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

ການທົດສອບວິທີການກວດສອບ

ບັດນີ້ເຮົາມາເບິ່ງວິເສດໃນການປະຕິບັດ!

• ສ້າງໂຟນເດີຫຼັກຫຼາຍອັນທີ່ມີລະຫັດລະດັບເທິງດຽວກັນ (i.e. /sample_key) ແລະຄ່າທີ່ທ່ານເລືອກ. ສ້າງນະໂຍບາຍແລະພາລະບົດບາດທີ່ເຫມາະສົມສໍາລັບການເສັ້ນທາງທີ່ສໍາຄັນໃຫມ່. ພວກເຮົາຈະເຮັດການຜູກມັດໃນພາຍຫຼັງ.

ການທົດສອບ namespace ແບບກຳນົດເອງ:

• ມາສ້າງ namespace ຂອງພວກເຮົາເອງ:

kubectl create namespace custom-ns

• ມາສ້າງ pod ໃນ namespace ໃໝ່ຂອງພວກເຮົາ. ຂຽນການຕັ້ງຄ່າສໍາລັບຝັກ.

###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

• ໃນປັດຈຸບັນພວກເຮົາຈະສົ່ງຄໍາຮ້ອງຂໍການເຂົ້າສູ່ລະບົບໄປຫາ Consul ໂດຍໃຊ້ວິທີການອະນຸຍາດທີ່ພວກເຮົາສ້າງກ່ອນຫນ້ານີ້ [ຫນ້າທໍາອິດ].
• ເພື່ອເບິ່ງໂທເຄັນທີ່ເຂົ້າມາຈາກບັນຊີບໍລິການຂອງທ່ານ:

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 ຖອດລະຫັດ "Value" ແລະເຫັນວ່າມັນກົງກັບຄ່າໃນ custom-ns/test_key ໃນ UI. ຖ້າທ່ານໃຊ້ຄ່າດຽວກັນຂ້າງເທິງໃນບົດສອນນີ້, ຄ່າທີ່ເຂົ້າລະຫັດຂອງທ່ານຈະເປັນ IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.

ການທົດສອບບັນຊີການບໍລິການຜູ້ໃຊ້:

• ສ້າງບັນຊີການບໍລິການແບບກຳນົດເອງໂດຍໃຊ້ຄຳສັ່ງຕໍ່ໄປນີ້ [ຫນ້າທໍາອິດ].

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

• ສ້າງໄຟລ໌ການຕັ້ງຄ່າໃຫມ່ສໍາລັບ pod ໄດ້. ກະລຸນາສັງເກດວ່າຂ້ອຍລວມການຕິດຕັ້ງ 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

• ການອະນຸຍາດຖືກປະຕິເສດ. ໂອ້, ພວກເຮົາລືມທີ່ຈະເພີ່ມກົດລະບຽບໃຫມ່ທີ່ຜູກມັດກັບການອະນຸຍາດທີ່ເຫມາະສົມ, ໃຫ້ເຮັດມັນດຽວນີ້.

ເຮັດຊ້ຳຂັ້ນຕອນກ່ອນໜ້ານີ້:
a) ສ້າງນະໂຍບາຍດຽວກັນສໍາລັບຄໍານໍາຫນ້າ "custom-sa/".
b) ສ້າງພາລະບົດບາດ, ໂທຫາມັນ " custom-sa-role "
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/ key path.

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

• ນອກນັ້ນທ່ານຍັງສາມາດຮັບປະກັນວ່າ token ນີ້ບໍ່ອະນຸຍາດໃຫ້ເຂົ້າເຖິງ kv ໃນ "custom-ns/". ພຽງແຕ່ເຮັດຊ້ໍາຄໍາສັ່ງຂ້າງເທິງຫຼັງຈາກປ່ຽນ "custom-sa" ກັບຄໍານໍາຫນ້າ "custom-ns".
  ການອະນຸຍາດຖືກປະຕິເສດ.

ຕົວຢ່າງ overlay:

• ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າການສ້າງແຜນທີ່ຜູກມັດກົດລະບຽບທັງຫມົດຈະຖືກເພີ່ມໃສ່ token ທີ່ມີສິດທິເຫຼົ່ານີ້.
• ກ່ອງບັນຈຸຂອງພວກເຮົາ "poc-ubuntu-custom-sa" ແມ່ນຢູ່ໃນ namespace ເລີ່ມຕົ້ນ - ສະນັ້ນໃຫ້ພວກເຮົາໃຊ້ມັນສໍາລັບການຜູກມັດກົດລະບຽບທີ່ແຕກຕ່າງກັນ.
• ເຮັດຊ້ຳຂັ້ນຕອນທີ່ຜ່ານມາ:
  a) ສ້າງນະໂຍບາຍດຽວກັນສໍາລັບ "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" ຂອງພວກເຮົາ ແລະພະຍາຍາມເຂົ້າຫາເສັ້ນທາງ kvv "default/".
• ການອະນຸຍາດຖືກປະຕິເສດ.
  ທ່ານສາມາດເບິ່ງຂໍ້ມູນປະຈໍາຕົວທີ່ລະບຸໄວ້ສໍາລັບແຕ່ລະ token ໃນ UI ພາຍໃຕ້ ACL > Token. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, token ໃນປະຈຸບັນຂອງພວກເຮົາມີພຽງແຕ່ຫນຶ່ງ "ພາລະບົດບາດ custom-sa-" ຕິດກັບມັນ. ໂທເຄັນທີ່ພວກເຮົາກຳລັງໃຊ້ຢູ່ໃນຂະນະນີ້ ແມ່ນຖືກສ້າງຂຶ້ນເມື່ອພວກເຮົາເຂົ້າສູ່ລະບົບ ແລະມີພຽງແຕ່ກົດທີ່ຜູກມັດອັນດຽວທີ່ກົງກັນໃນເວລານັ້ນ. ພວກເຮົາຕ້ອງເຂົ້າສູ່ລະບົບອີກຄັ້ງ ແລະໃຊ້ໂທເຄັນໃໝ່.
• ໃຫ້ແນ່ໃຈວ່າທ່ານສາມາດອ່ານໄດ້ຈາກທັງສອງ "custom-sa/" ແລະ "default/" ເສັ້ນທາງ kv.
  ຄວາມ​ສໍາ​ເລັດ!
  ນີ້ແມ່ນຍ້ອນວ່າ "poc-ubuntu-custom-sa" ຂອງພວກເຮົາກົງກັບ "custom-sa" ແລະ "default-ns" ການຜູກມັດກົດລະບຽບ.

ສະຫລຸບ

TTL token mgmt?

ໃນເວລາຂຽນນີ້, ບໍ່ມີວິທີການປະສົມປະສານເພື່ອກໍານົດ TTL ສໍາລັບ tokens ທີ່ສ້າງຂຶ້ນໂດຍວິທີການອະນຸຍາດນີ້. ມັນຈະເປັນໂອກາດທີ່ດີທີ່ຈະສະຫນອງການອັດຕະໂນມັດທີ່ປອດໄພຂອງການອະນຸຍາດກົງສຸນ.

ມີທາງເລືອກໃນການສ້າງ token ດ້ວຍຕົນເອງດ້ວຍ TTL:

• https://www.consul.io/docs/acl/acl-system.html#acl-tokens
  ເວລາໝົດອາຍຸ - ເວລາທີ່ token ນີ້ຈະຖືກຖອນຄືນ. (ທາງເລືອກ; ເພີ່ມໃນ Consul 1.5.0)
• ມີພຽງແຕ່ສໍາລັບການສ້າງ / ການປັບປຸງຄູ່ມື https://www.consul.io/api/acl/tokens.html#expirationtime

ຫວັງວ່າໃນອະນາຄົດອັນໃກ້ນີ້ພວກເຮົາສາມາດຄວບຄຸມວິທີການສ້າງ tokens (ຕໍ່ກົດລະບຽບຫຼືວິທີການອະນຸຍາດ) ແລະເພີ່ມ TTL.

ຈົນກ່ວານັ້ນ, ມັນໄດ້ຖືກແນະນໍາວ່າທ່ານໃຊ້ຈຸດສິ້ນສຸດອອກຈາກລະບົບໃນເຫດຜົນຂອງທ່ານ.

• https://www.consul.io/api/acl/acl.html#logout-from-auth-method
• https://www.consul.io/docs/acl/acl-auth-methods.html#overall-login-process

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

• ການເຄື່ອນຍ້າຍຈາກ ClickHouse ໂດຍບໍ່ມີການອະນຸຍາດໄປຫາ ClickHouse ດ້ວຍການອະນຸຍາດນໍາໄປສູ່ຫຍັງ?
• ວິທີການແລ່ນທໍ່ຫຼາຍສາຍໂດຍໃຊ້ GitLab CI/CD
• ສາມ tricks ງ່າຍດາຍທີ່ຈະຫຍໍ້ຮູບພາບ Docker
• Traefik ເປັນຕົວຄວບຄຸມ Ingress ສໍາລັບ K8S
• ການສໍາຮອງຂອງຈໍານວນຂະຫນາດໃຫຍ່ຂອງໂຄງການເວັບໄຊຕ໌ heterogeneous
• Telegram bot ສໍາລັບ Redmine. ວິທີການເຮັດໃຫ້ຊີວິດງ່າຍສໍາລັບຕົວທ່ານເອງແລະຄົນອື່ນ

ແຫຼ່ງຂໍ້ມູນ: www.habr.com