ການເຂົ້າລະຫັດໃນ MySQL: Keystore

ໃນຄວາມຄາດຫວັງຂອງການເລີ່ມຕົ້ນຂອງການລົງທະບຽນໃຫມ່ສໍາລັບຫຼັກສູດ "ຖານຂໍ້ມູນ" ພວກເຮົາໄດ້ກະກຽມການແປພາສາຂອງບົດຄວາມທີ່ເປັນປະໂຫຍດສໍາລັບທ່ານ.

ການເຂົ້າລະຫັດຂໍ້ມູນໂປ່ງໃສ (TDE) ປາກົດຢູ່ໃນ ເຊີບເວີ Percona ສໍາລັບ MySQL ແລະ MySQL ສໍາລັບບາງເວລາ. ແຕ່ທ່ານເຄີຍຄິດກ່ຽວກັບວິທີທີ່ມັນເຮັດວຽກພາຍໃຕ້ hood ແລະຜົນກະທົບອັນໃດທີ່ TDE ສາມາດມີຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງທ່ານ? ໃນຊຸດຂອງບົດຄວາມນີ້ພວກເຮົາຈະເບິ່ງວິທີການ TDE ເຮັດວຽກພາຍໃນ. ມາເລີ່ມຕົ້ນດ້ວຍການເກັບຮັກສາກະແຈ, ເພາະວ່າອັນນີ້ຈຳເປັນສຳລັບການເຂົ້າລະຫັດໃດໆກໍຕາມທີ່ຈະເຮັດວຽກໄດ້. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະພິຈາລະນາຢ່າງໃກ້ຊິດກ່ຽວກັບວິທີການເຂົ້າລະຫັດໃນ Percona Server ສໍາລັບ MySQL / MySQL ແລະຄຸນສົມບັດເພີ່ມເຕີມຂອງ Percona Server ສໍາລັບ MySQL ມີຫຍັງແດ່.

MySQL Keyring

ກະແຈແມ່ນປລັກອິນທີ່ອະນຸຍາດໃຫ້ເຊີບເວີສອບຖາມ, ສ້າງ ແລະລຶບກະແຈໃນໄຟລ໌ທ້ອງຖິ່ນ (keyring_file) ຫຼືໃນເຊີບເວີທາງໄກ (ເຊັ່ນ: HashiCorp Vault). ລະຫັດຈະຖືກເກັບໄວ້ໃນເຄື່ອງສະເໝີເພື່ອເລັ່ງການດຶງຂໍ້ມູນ.

Plugins ສາມາດແບ່ງອອກເປັນສອງປະເພດ:

• ການເກັບຮັກສາທ້ອງຖິ່ນ. ຕົວຢ່າງ, ໄຟລ໌ທ້ອງຖິ່ນ (ພວກເຮົາເອີ້ນນີ້ວ່າ keyring ໄຟລ໌).
• ການເກັບຮັກສາໄລຍະໄກ. ຕົວຢ່າງເຊັ່ນ, Vault Server (ພວກເຮົາເອີ້ນອັນນີ້ວ່າເຄື່ອງໃຊ້ລະຫັດເຊີບເວີ).

ການແຍກນີ້ເປັນສິ່ງສໍາຄັນເພາະວ່າປະເພດຕ່າງໆຂອງການເກັບຮັກສາປະຕິບັດຕົວແຕກຕ່າງກັນເລັກນ້ອຍ, ບໍ່ພຽງແຕ່ໃນເວລາທີ່ເກັບຮັກສາແລະດຶງລະຫັດ, ແຕ່ຍັງໃນເວລາທີ່ແລ່ນໃຫ້ເຂົາເຈົ້າ.

ເມື່ອໃຊ້ການເກັບຮັກສາໄຟລ໌, ເມື່ອເລີ່ມຕົ້ນ, ເນື້ອໃນທັງຫມົດຂອງການເກັບຮັກສາຈະຖືກໂຫລດເຂົ້າໄປໃນ cache: key id, key user, key type, and the key itself.

ໃນກໍລະນີຂອງການເກັບຮັກສາຂ້າງເຊີຟເວີ (ເຊັ່ນ: ເຊີຟເວີ Vault), ພຽງແຕ່ id ລະຫັດແລະຜູ້ໃຊ້ທີ່ສໍາຄັນຖືກໂຫລດໃນເວລາເລີ່ມຕົ້ນ, ດັ່ງນັ້ນການໄດ້ຮັບລະຫັດທັງຫມົດບໍ່ໄດ້ຊ້າລົງໃນການເລີ່ມຕົ້ນ. ກະແຈຖືກໂຫຼດຢ່າງອິດເມື່ອຍ. ນັ້ນແມ່ນ, ກຸນແຈຕົວມັນເອງຖືກໂຫລດຈາກ Vault ພຽງແຕ່ໃນເວລາທີ່ມັນຕ້ອງການຕົວຈິງ. ເມື່ອດາວໂຫລດແລ້ວ, ລະຫັດຈະຖືກເກັບໄວ້ໃນຫນ່ວຍຄວາມຈໍາເພື່ອວ່າມັນບໍ່ຈໍາເປັນຕ້ອງເຂົ້າເຖິງໂດຍຜ່ານການເຊື່ອມຕໍ່ TLS ກັບ Vault Server ໃນອະນາຄົດ. ຕໍ່ໄປ, ໃຫ້ເບິ່ງວ່າຂໍ້ມູນໃດທີ່ມີຢູ່ໃນຮ້ານທີ່ສໍາຄັນ.

ຂໍ້​ມູນ​ທີ່​ສໍາ​ຄັນ​ປະ​ກອບ​ດ້ວຍ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• ລະຫັດລະຫັດ — ຕົວ​ລະ​ບຸ​ທີ່​ສໍາ​ຄັນ​, ສໍາ​ລັບ​ການ​ຍົກ​ຕົວ​ຢ່າງ​:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• ປະເພດທີ່ ສຳ ຄັນ — ປະ​ເພດ​ທີ່​ສໍາ​ຄັນ​ອີງ​ຕາມ​ວິ​ທີ​ການ​ການ​ເຂົ້າ​ລະ​ຫັດ​ທີ່​ນໍາ​ໃຊ້​, ຄຸນ​ຄ່າ​ທີ່​ເປັນ​ໄປ​ໄດ້​: “AES​”​, “RSA​” ຫຼື “DSA​”​.
• ຄວາມຍາວທີ່ ສຳ ຄັນ — ຄວາມ​ຍາວ​ທີ່​ສໍາ​ຄັນ​ໃນ bytes​, AES​: 16​, 24 ຫຼື 32​, RSA 128​, 256​, 512 ແລະ DSA 128​, 256 ຫຼື 384​.
• ຜູ້ໃຊ້ - ເຈົ້າ​ຂອງ​ທີ່​ສໍາ​ຄັນ​. ຖ້າລະຫັດແມ່ນລະບົບ, ຕົວຢ່າງ, Master Key, ຫຼັງຈາກນັ້ນຊ່ອງຂໍ້ມູນນີ້ແມ່ນຫວ່າງເປົ່າ. ຖ້າກະແຈຖືກສ້າງໂດຍໃຊ້ keyring_udf, ຊ່ອງຂໍ້ມູນນີ້ຈະລະບຸເຈົ້າຂອງກະແຈ.
• ກຸນແຈຂອງມັນເອງ

ຄີແມ່ນຖືກກໍານົດໂດຍຄູ່: key_id, ຜູ້ໃຊ້.

ຍັງມີຄວາມແຕກຕ່າງໃນການເກັບຮັກສາແລະການລຶບລະຫັດ.

ການເກັບຮັກສາໄຟລ໌ໄວຂຶ້ນ. ທ່ານອາດຈະຄິດວ່າຮ້ານທີ່ສໍາຄັນແມ່ນພຽງແຕ່ຂຽນກະແຈໃສ່ໄຟລ໌ຫນຶ່ງຄັ້ງ, ແຕ່ບໍ່ແມ່ນ, ມັນມີຫຼາຍກວ່ານີ້. ເມື່ອໃດກໍ່ຕາມການດັດແກ້ການເກັບຮັກສາໄຟລ໌ຖືກເຮັດ, ສໍາເນົາສໍາຮອງຂອງເນື້ອຫາທັງຫມົດຈະຖືກສ້າງຂື້ນຄັ້ງທໍາອິດ. ໃຫ້ເວົ້າວ່າໄຟລ໌ເອີ້ນວ່າ my_biggest_secrets, ຫຼັງຈາກນັ້ນສໍາເນົາສໍາຮອງຂໍ້ມູນຈະເປັນ my_biggest_secrets.backup. ຕໍ່ໄປ, cache ໄດ້ຖືກປ່ຽນແປງ (ປຸ່ມຖືກເພີ່ມຫຼືລຶບອອກ) ແລະ, ຖ້າທຸກສິ່ງທຸກຢ່າງສໍາເລັດ, cache ຈະຖືກຕັ້ງໃຫມ່ເປັນໄຟລ໌. ໃນກໍລະນີທີ່ຫາຍາກ, ເຊັ່ນຄວາມລົ້ມເຫຼວຂອງເຄື່ອງແມ່ຂ່າຍ, ທ່ານອາດຈະເຫັນໄຟລ໌ສໍາຮອງຂໍ້ມູນນີ້. ໄຟລ​໌​າ​ຮອງ​ຈະ​ຖືກ​ລົບ​ໃນ​ຄັ້ງ​ຕໍ່​ໄປ​ທີ່​ກະ​ແຈ​ໄດ້​ຖືກ​ໂຫຼດ (ໂດຍ​ປົກ​ກະ​ຕິ​ຫຼັງ​ຈາກ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ແມ່ນ restarted​)​.

ເມື່ອບັນທຶກຫຼືລຶບກະແຈຢູ່ໃນບ່ອນເກັບຂໍ້ມູນຂອງເຄື່ອງແມ່ຂ່າຍ, ການເກັບຮັກສາຕ້ອງເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ MySQL ດ້ວຍຄໍາສັ່ງ "ສົ່ງລະຫັດ" / "ຮ້ອງຂໍການລຶບລະຫັດ".

ໃຫ້ກັບຄືນສູ່ຄວາມໄວການເລີ່ມຕົ້ນຂອງເຄື່ອງແມ່ຂ່າຍ. ນອກເໜືອໄປຈາກຄວາມຈິງທີ່ວ່າຄວາມໄວໃນການເປີດຕົວແມ່ນໄດ້ຮັບຜົນກະທົບໂດຍ vault ຕົວຂອງມັນເອງ, ຍັງມີບັນຫາກ່ຽວກັບຈໍານວນກະແຈຈາກ vault ຕ້ອງໄດ້ຮັບການດຶງອອກມາໃນເວລາເລີ່ມຕົ້ນ. ແນ່ນອນ, ນີ້ເປັນສິ່ງສໍາຄັນໂດຍສະເພາະສໍາລັບການເກັບຮັກສາເຄື່ອງແມ່ຂ່າຍ. ໃນຕອນເລີ່ມຕົ້ນ, ເຊີບເວີຈະກວດເບິ່ງວ່າກະແຈໃດຕ້ອງການສໍາລັບການເຂົ້າລະຫັດຕາຕະລາງ/ພື້ນທີ່ຕາຕະລາງ ແລະຮ້ອງຂໍລະຫັດຈາກບ່ອນເກັບຂໍ້ມູນ. ໃນເຊີບເວີທີ່ "ສະອາດ" ດ້ວຍການເຂົ້າລະຫັດ Master Key, ຕ້ອງມີ Master Key ອັນໜຶ່ງ, ເຊິ່ງຕ້ອງໄດ້ດຶງມາຈາກບ່ອນເກັບຂໍ້ມູນ. ຢ່າງໃດກໍຕາມ, ຈໍານວນລະຫັດທີ່ໃຫຍ່ກວ່າອາດຈະຕ້ອງການ, ຕົວຢ່າງ, ເມື່ອເຄື່ອງແມ່ຂ່າຍສໍາຮອງຂໍ້ມູນກໍາລັງຟື້ນຟູການສໍາຮອງຂໍ້ມູນຈາກເຄື່ອງແມ່ຂ່າຍຕົ້ນຕໍ. ໃນກໍລະນີດັ່ງກ່າວ, ການຫມຸນຂອງ Master Key ຄວນໄດ້ຮັບການສະຫນອງ. ນີ້ຈະໄດ້ຮັບການກວມເອົາໃນລາຍລະອຽດເພີ່ມເຕີມໃນບົດຄວາມໃນອະນາຄົດ, ເຖິງແມ່ນວ່າໃນທີ່ນີ້ຂ້າພະເຈົ້າຢາກຈະສັງເກດວ່າເຄື່ອງແມ່ຂ່າຍທີ່ໃຊ້ Master Keys ຫຼາຍອາດຈະໃຊ້ເວລາດົນກວ່າທີ່ຈະເລີ່ມຕົ້ນ, ໂດຍສະເພາະໃນເວລາທີ່ການນໍາໃຊ້ຮ້ານທີ່ສໍາຄັນຂອງເຄື່ອງແມ່ຂ່າຍ.

ຕອນນີ້ໃຫ້ເວົ້າຕື່ມອີກເລັກນ້ອຍກ່ຽວກັບ keyring_file. ໃນເວລາທີ່ຂ້ອຍກໍາລັງພັດທະນາ keyring_file, ຂ້ອຍຍັງກັງວົນກ່ຽວກັບວິທີກວດສອບການປ່ຽນແປງ keyring_file ໃນຂະນະທີ່ເຄື່ອງແມ່ຂ່າຍກໍາລັງເຮັດວຽກ. ໃນ 5.7, ການກວດສອບໄດ້ຖືກປະຕິບັດໂດຍອີງໃສ່ສະຖິຕິໄຟລ໌, ເຊິ່ງບໍ່ແມ່ນການແກ້ໄຂທີ່ເຫມາະສົມ, ແລະໃນ 8.0 ມັນຖືກແທນທີ່ດ້ວຍ checksum SHA256.

ຄັ້ງທໍາອິດທີ່ທ່ານດໍາເນີນການ keyring_file, ສະຖິຕິໄຟລ໌ແລະ checksum ໄດ້ຖືກຄິດໄລ່, ເຊິ່ງຖືກຈົດຈໍາໂດຍເຄື່ອງແມ່ຂ່າຍ, ແລະການປ່ຽນແປງແມ່ນໃຊ້ພຽງແຕ່ຖ້າພວກເຂົາກົງກັນ. ເມື່ອໄຟລ໌ປ່ຽນແປງ, checksum ຈະຖືກປັບປຸງ.

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

ສິ່ງ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ຫມາຍ​ຄວາມ​ວ່າ? ແຕ່ລະເຊີບເວີ (ຕົວຢ່າງ, Percona Server) ໃນກຸ່ມຕ້ອງມີສະຖານທີ່ແຍກຕ່າງຫາກຢູ່ໃນ Vault Server ທີ່ Percona Server ຕ້ອງເກັບກະແຈຂອງມັນ. ແຕ່ລະ Master Key ທີ່ບັນທຶກໄວ້ໃນບ່ອນເກັບມ້ຽນມີ GUID ຂອງເຊີບເວີ Percona ພາຍໃນຕົວລະບຸຂອງມັນ. ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນ? ຈິນຕະນາການວ່າທ່ານມີ Vault Server ໜ່ວຍດຽວ ແລະເຊີບເວີ Percona ທັງໝົດໃນກຸ່ມໃຊ້ Vault Server ດຽວນັ້ນ. ບັນຫາເບິ່ງຄືວ່າຈະແຈ້ງ. ຖ້າເຄື່ອງແມ່ຂ່າຍຂອງ Percona ທັງຫມົດໃຊ້ Master Key ໂດຍບໍ່ມີຕົວລະບຸທີ່ເປັນເອກະລັກ, ເຊັ່ນ: id = 1, id = 2, ແລະອື່ນໆ, ເຄື່ອງແມ່ຂ່າຍທັງຫມົດໃນ cluster ຈະໃຊ້ Master Key ດຽວກັນ. ສິ່ງທີ່ GUID ສະຫນອງແມ່ນຄວາມແຕກຕ່າງລະຫວ່າງເຄື່ອງແມ່ຂ່າຍ. ເປັນຫຍັງຈິ່ງເວົ້າເລື່ອງການແບ່ງປັນກະແຈລະຫວ່າງເຊີບເວີ ຖ້າມີ GUID ທີ່ເປັນເອກະລັກຢູ່ແລ້ວ? ມີ plugin ອື່ນ - keyring_udf . ດ້ວຍປັ໊ກອິນນີ້, ຜູ້ໃຊ້ເຊີບເວີຂອງທ່ານສາມາດເກັບກະແຈຂອງພວກເຂົາຢູ່ໃນເຊີບເວີ Vault. ບັນຫາເກີດຂື້ນເມື່ອຜູ້ໃຊ້ສ້າງລະຫັດໃນ server1, ຕົວຢ່າງ, ແລະຫຼັງຈາກນັ້ນພະຍາຍາມສ້າງລະຫັດທີ່ມີ ID ດຽວກັນຢູ່ໃນ server2, ຕົວຢ່າງ:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

ລໍຖ້າ. ເຊີບເວີທັງສອງກຳລັງໃຊ້ Vault Server ດຽວກັນ, ຟັງຊັນ keyring_key_store ລົ້ມເຫລວໃນ server2 ບໍ? ຫນ້າສົນໃຈ, ຖ້າທ່ານພະຍາຍາມເຮັດສິ່ງດຽວກັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງ, ທ່ານຈະໄດ້ຮັບຂໍ້ຜິດພາດ:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

ຖືກແລ້ວ, ROB_1 ມີຢູ່ແລ້ວ.

ໃຫ້ພິຈາລະນາຕົວຢ່າງທີສອງກ່ອນ. ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວກ່ອນຫນ້ານັ້ນ, keyring_vault ຫຼື plugin keyring ອື່ນໆຈະເກັບ ID ທີ່ສໍາຄັນທັງຫມົດໃນຫນ່ວຍຄວາມຈໍາ. ດັ່ງນັ້ນ, ຫຼັງຈາກການສ້າງລະຫັດໃຫມ່, ROB_1 ຖືກເພີ່ມໃສ່ server1, ແລະນອກເຫນືອຈາກການສົ່ງລະຫັດນີ້ໄປຫາ Vault, ລະຫັດຍັງຖືກເພີ່ມໃສ່ cache. ໃນປັດຈຸບັນ, ເມື່ອພວກເຮົາພະຍາຍາມເພີ່ມລະຫັດດຽວກັນເປັນຄັ້ງທີສອງ, keyring_vault ກວດເບິ່ງວ່າລະຫັດມີຢູ່ໃນ cache ແລະຖິ້ມຄວາມຜິດພາດ.

ໃນກໍລະນີທໍາອິດ, ສະຖານະການແມ່ນແຕກຕ່າງກັນ. Server1 ແລະ server2 ມີແຄດແຍກຕ່າງຫາກ. ຫຼັງຈາກເພີ່ມ ROB_1 ໃສ່ cache ຫຼັກໃນ server1 ແລະ Vault server, key cache ໃນ server2 ບໍ່ໄດ້ຊິ້ງ. ບໍ່ມີກະແຈ ROB_2 ໃນ cache ໃນ server1. ດັ່ງນັ້ນ, ລະຫັດ ROB_1 ຖືກຂຽນໃສ່ keyring_key_store ແລະເຄື່ອງແມ່ຂ່າຍ Vault, ເຊິ່ງຕົວຈິງແລ້ວຂຽນທັບ (!) ຄ່າທີ່ຜ່ານມາ. ຕອນນີ້ກະແຈ ROB_1 ໃນເຊີບເວີ Vault ແມ່ນ 543210987654321. ຫນ້າສົນໃຈ, ເຊີບເວີ Vault ບໍ່ໄດ້ປິດກັ້ນການກະທຳດັ່ງກ່າວ ແລະຂຽນທັບຄ່າເກົ່າໄດ້ຢ່າງງ່າຍດາຍ.

ຕອນນີ້ພວກເຮົາສາມາດເຫັນໄດ້ວ່າເປັນຫຍັງການແບ່ງສ່ວນຂອງເຄື່ອງແມ່ຂ່າຍໃນ Vault ສາມາດມີຄວາມສໍາຄັນ - ເມື່ອທ່ານກໍາລັງໃຊ້ keyring_udf ແລະຕ້ອງການເກັບກະແຈຢູ່ໃນ Vault. ວິທີການບັນລຸການແຍກນີ້ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ Vault?

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

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

ໃນທີ່ນີ້ທ່ານສາມາດເບິ່ງວ່າ server1 ແລະ server2 ກໍາລັງໃຊ້ຈຸດເຊື່ອມຕໍ່ທີ່ແຕກຕ່າງກັນ. ໃນ​ເວ​ລາ​ທີ່​ແບ່ງ​ປັນ​ເສັ້ນ​ທາງ​, ການ​ຕັ້ງ​ຄ່າ​ຈະ​ເປັນ​ດັ່ງ​ນີ້​:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

ໃນກໍລະນີນີ້, ທັງສອງເຄື່ອງແມ່ຂ່າຍໃຊ້ຈຸດ mount ດຽວກັນ "mount_point", ແຕ່ເສັ້ນທາງທີ່ແຕກຕ່າງກັນ. ເມື່ອທ່ານສ້າງຄວາມລັບຄັ້ງທໍາອິດໃນ server1 ໂດຍໃຊ້ເສັ້ນທາງນີ້, ເຄື່ອງແມ່ຂ່າຍ Vault ຈະສ້າງໄດເລກະທໍລີ "server1" ໂດຍອັດຕະໂນມັດ. ສໍາລັບ server2 ທຸກສິ່ງທຸກຢ່າງແມ່ນຄ້າຍຄືກັນ. ເມື່ອທ່ານລຶບຄວາມລັບສຸດທ້າຍໃນ mount_point/server1 ຫຼື mount_point/server2, ເຊີບເວີ Vault ຈະລຶບໄດເລກະທໍລີເຫຼົ່ານັ້ນເຊັ່ນກັນ. ໃນກໍລະນີທີ່ທ່ານໃຊ້ການແຍກເສັ້ນທາງ, ທ່ານຕ້ອງສ້າງຈຸດເຊື່ອມຕໍ່ດຽວແລະປ່ຽນໄຟລ໌ການຕັ້ງຄ່າເພື່ອໃຫ້ເຄື່ອງແມ່ຂ່າຍໃຊ້ເສັ້ນທາງແຍກຕ່າງຫາກ. ຈຸດເຊື່ອມຕໍ່ສາມາດສ້າງໄດ້ໂດຍໃຊ້ຄໍາຮ້ອງຂໍ HTTP. ການນໍາໃຊ້ CURL ນີ້ສາມາດເຮັດໄດ້ເຊັ່ນນີ້:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

ຊ່ອງຂໍ້ມູນທັງໝົດ (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) ກົງກັບພາລາມິເຕີຂອງໄຟລ໌ການຕັ້ງຄ່າ. ແນ່ນອນ, ທ່ານສາມາດໃຊ້ Vault Utilities ເພື່ອເຮັດເຊັ່ນດຽວກັນ. ແຕ່ມັນງ່າຍຕໍ່ການສ້າງຈຸດເຊື່ອມຕໍ່ໂດຍອັດຕະໂນມັດ. ຂ້ອຍຫວັງວ່າເຈົ້າພົບວ່າຂໍ້ມູນນີ້ເປັນປະໂຫຍດແລະພວກເຮົາຈະເຫັນເຈົ້າໃນບົດຄວາມຕໍ່ໄປໃນຊຸດນີ້.

ອ່ານ​ຕື່ມ:

• Sysbench ແລະການແຈກຢາຍຕົວແປແບບສຸ່ມ

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