MySQL-ൽ എൻക്രിപ്ഷൻ: കീസ്റ്റോർ

കോഴ്‌സിനായി ഒരു പുതിയ എൻറോൾമെന്റിന്റെ ആരംഭം പ്രതീക്ഷിച്ച് "ഡാറ്റാബേസ്" നിങ്ങൾക്കായി ഉപയോഗപ്രദമായ ഒരു ലേഖനത്തിന്റെ വിവർത്തനം ഞങ്ങൾ തയ്യാറാക്കിയിട്ടുണ്ട്.

സുതാര്യമായ ഡാറ്റ എൻക്രിപ്ഷൻ (TDE) പ്രത്യക്ഷപ്പെട്ടു MySQL-നുള്ള പെർക്കോണ സെർവർ കുറച്ച് സമയത്തേക്ക് MySQL ഉം. എന്നാൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും ടിഡിഇ നിങ്ങളുടെ സെർവറിൽ എന്ത് സ്വാധീനം ചെലുത്തുമെന്നും നിങ്ങൾ എപ്പോഴെങ്കിലും ചിന്തിച്ചിട്ടുണ്ടോ? ഈ ലേഖന പരമ്പരയിൽ, TDE ആന്തരികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നോക്കാം. ഏത് എൻക്രിപ്ഷനും പ്രവർത്തിക്കാൻ ഇത് ആവശ്യമായതിനാൽ നമുക്ക് കീ സംഭരണത്തിൽ നിന്ന് ആരംഭിക്കാം. MySQL/MySQL-നുള്ള പെർക്കോണ സെർവറിൽ എൻക്രിപ്ഷൻ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും MySQL-നുള്ള പെർക്കോണ സെർവറിന് എന്തൊക്കെ അധിക സവിശേഷതകൾ ഉണ്ടെന്നും ഞങ്ങൾ സൂക്ഷ്മമായി പരിശോധിക്കും.

MySQL കീറിംഗ്

ഒരു ലോക്കൽ ഫയലിൽ (keyring_file) അല്ലെങ്കിൽ ഒരു റിമോട്ട് സെർവറിൽ (HashiCorp Vault പോലുള്ളവ) കീകൾ അന്വേഷിക്കാനും സൃഷ്ടിക്കാനും ഇല്ലാതാക്കാനും സെർവറിനെ അനുവദിക്കുന്ന പ്ലഗിന്നുകളാണ് കീറിംഗ്. വീണ്ടെടുക്കൽ വേഗത്തിലാക്കാൻ കീകൾ എല്ലായ്പ്പോഴും പ്രാദേശികമായി കാഷെ ചെയ്യുന്നു.

പ്ലഗിനുകളെ രണ്ട് വിഭാഗങ്ങളായി തിരിക്കാം:

• പ്രാദേശിക സംഭരണം. ഉദാഹരണത്തിന്, ഒരു ലോക്കൽ ഫയൽ (ഇതിനെ ഞങ്ങൾ ഫയൽ അടിസ്ഥാനമാക്കിയുള്ള കീറിംഗ് എന്ന് വിളിക്കുന്നു).
• വിദൂര സംഭരണം. ഉദാഹരണത്തിന്, വോൾട്ട് സെർവർ (ഞങ്ങൾ ഇതിനെ സെർവർ അടിസ്ഥാനമാക്കിയുള്ള കീറിംഗ് എന്ന് വിളിക്കുന്നു).

ഈ വേർതിരിവ് പ്രധാനമാണ്, കാരണം വ്യത്യസ്ത തരം സ്റ്റോറേജ് കീകൾ സംഭരിക്കുമ്പോഴും വീണ്ടെടുക്കുമ്പോഴും മാത്രമല്ല, അവ പ്രവർത്തിപ്പിക്കുമ്പോഴും അല്പം വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു.

ഒരു ഫയൽ സ്റ്റോറേജ് ഉപയോഗിക്കുമ്പോൾ, സ്റ്റാർട്ടപ്പ് ചെയ്യുമ്പോൾ, സ്റ്റോറേജിലെ മുഴുവൻ ഉള്ളടക്കങ്ങളും കാഷെയിലേക്ക് ലോഡ് ചെയ്യപ്പെടും: കീ ഐഡി, കീ യൂസർ, കീ തരം, കീ തന്നെ.

സെർവർ അധിഷ്‌ഠിത സ്‌റ്റോറിന്റെ കാര്യത്തിൽ (വോൾട്ട് സെർവർ പോലുള്ളവ), സ്റ്റാർട്ടപ്പിൽ കീ ഐഡിയും കീ യൂസറും മാത്രമേ ലോഡ് ചെയ്യപ്പെടുന്നുള്ളൂ, അതിനാൽ എല്ലാ കീകളും ലഭിക്കുന്നത് സ്റ്റാർട്ടപ്പിനെ മന്ദഗതിയിലാക്കില്ല. കീകൾ അലസമായി ലോഡ് ചെയ്യുന്നു. അതായത്, കീ തന്നെ യഥാർത്ഥത്തിൽ ആവശ്യമുള്ളപ്പോൾ മാത്രമേ വോൾട്ടിൽ നിന്ന് ലോഡുചെയ്യുകയുള്ളൂ. ഒരിക്കൽ ഡൗൺലോഡ് ചെയ്‌താൽ, കീ മെമ്മറിയിൽ കാഷെ ചെയ്‌തതിനാൽ ഭാവിയിൽ വോൾട്ട് സെർവറിലേക്കുള്ള TLS കണക്ഷനുകൾ വഴി അത് ആക്‌സസ് ചെയ്യേണ്ടതില്ല. അടുത്തതായി, കീ സ്റ്റോറിൽ എന്ത് വിവരങ്ങളാണ് ഉള്ളതെന്ന് നോക്കാം.

പ്രധാന വിവരങ്ങളിൽ ഇനിപ്പറയുന്നവ അടങ്ങിയിരിക്കുന്നു:

• കീ ഐഡി - കീ ഐഡന്റിഫയർ, ഉദാഹരണത്തിന്:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• കീ തരം — ഉപയോഗിച്ച എൻക്രിപ്ഷൻ അൽഗോരിതം അടിസ്ഥാനമാക്കിയുള്ള കീ തരം, സാധ്യമായ മൂല്യങ്ങൾ: "AES", "RSA" അല്ലെങ്കിൽ "DSA".
• കീ ദൈർഘ്യം — ബൈറ്റുകളിലെ കീ ദൈർഘ്യം, AES: 16, 24 അല്ലെങ്കിൽ 32, RSA 128, 256, 512, DSA 128, 256 അല്ലെങ്കിൽ 384.
• ഉപയോക്താവ് - കീയുടെ ഉടമ. കീ സിസ്റ്റമാണെങ്കിൽ, ഉദാഹരണത്തിന്, മാസ്റ്റർ കീ, ഈ ഫീൽഡ് ശൂന്യമാണ്. keyring_udf ഉപയോഗിച്ചാണ് ഒരു കീ സൃഷ്ടിച്ചതെങ്കിൽ, ഈ ഫീൽഡ് കീയുടെ ഉടമയെ തിരിച്ചറിയുന്നു.
• താക്കോൽ തന്നെ

കീയെ ജോടി അദ്വിതീയമായി തിരിച്ചറിയുന്നു: key_id, ഉപയോക്താവ്.

കീകൾ സംഭരിക്കുന്നതിലും ഇല്ലാതാക്കുന്നതിലും വ്യത്യാസങ്ങളുണ്ട്.

ഫയൽ സംഭരണം വേഗതയുള്ളതാണ്. ഒരു കീ സ്റ്റോർ ഒരു ഫയലിന്റെ താക്കോൽ ഒരിക്കൽ എഴുതുകയാണെന്ന് നിങ്ങൾ ചിന്തിച്ചേക്കാം, പക്ഷേ ഇല്ല, ഇവിടെ കൂടുതൽ കാര്യങ്ങൾ നടക്കുന്നുണ്ട്. ഒരു ഫയൽ സ്റ്റോറേജ് പരിഷ്‌ക്കരണം നടത്തുമ്പോഴെല്ലാം, എല്ലാ ഉള്ളടക്കത്തിന്റെയും ബാക്കപ്പ് പകർപ്പ് ആദ്യം സൃഷ്ടിക്കപ്പെടും. ഫയലിനെ my_biggest_secrets എന്ന് വിളിക്കാം, അപ്പോൾ ബാക്കപ്പ് കോപ്പി my_biggest_secrets.backup ആയിരിക്കും. അടുത്തതായി, കാഷെ മാറ്റി (കീകൾ ചേർക്കുകയോ ഇല്ലാതാക്കുകയോ ചെയ്യുന്നു), എല്ലാം വിജയകരമാണെങ്കിൽ, കാഷെ ഒരു ഫയലിലേക്ക് പുനഃസജ്ജമാക്കും. സെർവർ പരാജയം പോലുള്ള അപൂർവ സന്ദർഭങ്ങളിൽ, നിങ്ങൾ ഈ ബാക്കപ്പ് ഫയൽ കണ്ടേക്കാം. അടുത്ത തവണ കീകൾ ലോഡ് ചെയ്യുമ്പോൾ ബാക്കപ്പ് ഫയൽ ഇല്ലാതാക്കപ്പെടും (സാധാരണയായി സെർവർ പുനരാരംഭിച്ചതിന് ശേഷം).

ഒരു സെർവർ സ്റ്റോറേജിൽ ഒരു കീ സംരക്ഷിക്കുകയോ ഇല്ലാതാക്കുകയോ ചെയ്യുമ്പോൾ, സ്റ്റോറേജ് “കീ അയയ്‌ക്കുക” / “കീ ഇല്ലാതാക്കാൻ അഭ്യർത്ഥിക്കുക” എന്ന കമാൻഡുകൾ ഉപയോഗിച്ച് MySQL സെർവറുമായി ബന്ധിപ്പിക്കണം.

നമുക്ക് സെർവർ സ്റ്റാർട്ടപ്പ് വേഗതയിലേക്ക് മടങ്ങാം. വിക്ഷേപണ വേഗതയെ നിലവറ തന്നെ ബാധിക്കുന്നു എന്നതിന് പുറമേ, സ്റ്റാർട്ടപ്പിൽ നിലവറയിൽ നിന്ന് എത്ര കീകൾ വീണ്ടെടുക്കേണ്ടതുണ്ട് എന്ന പ്രശ്നവുമുണ്ട്. തീർച്ചയായും, സെർവർ സംഭരണത്തിന് ഇത് വളരെ പ്രധാനമാണ്. ആരംഭത്തിൽ, എൻക്രിപ്റ്റ് ചെയ്ത ടേബിളുകൾ/ടേബിൾസ്പേസുകൾക്ക് ഏത് കീയാണ് വേണ്ടതെന്ന് സെർവർ പരിശോധിക്കുകയും സ്റ്റോറേജിൽ നിന്ന് കീ അഭ്യർത്ഥിക്കുകയും ചെയ്യുന്നു. മാസ്റ്റർ കീ എൻക്രിപ്ഷനുള്ള ഒരു "ക്ലീൻ" സെർവറിൽ, ഒരു മാസ്റ്റർ കീ ഉണ്ടായിരിക്കണം, അത് സ്റ്റോറേജിൽ നിന്ന് വീണ്ടെടുക്കേണ്ടതാണ്. എന്നിരുന്നാലും, ഒരു വലിയ സംഖ്യ കീകൾ ആവശ്യമായി വന്നേക്കാം, ഉദാഹരണത്തിന്, ബാക്കപ്പ് സെർവർ പ്രാഥമിക സെർവറിൽ നിന്ന് ഒരു ബാക്കപ്പ് പുനഃസ്ഥാപിക്കുമ്പോൾ. അത്തരം സന്ദർഭങ്ങളിൽ, മാസ്റ്റർ കീയുടെ റൊട്ടേഷൻ നൽകണം. ഇത് കൂടുതൽ വിശദമായി ഭാവിയിലെ ലേഖനങ്ങളിൽ ഉൾപ്പെടുത്തും, എന്നിരുന്നാലും ഒന്നിലധികം മാസ്റ്റർ കീകൾ ഉപയോഗിക്കുന്ന ഒരു സെർവർ ആരംഭിക്കുന്നതിന് കുറച്ച് സമയമെടുത്തേക്കാം, പ്രത്യേകിച്ചും സെർവർ സൈഡ് കീ സ്റ്റോർ ഉപയോഗിക്കുമ്പോൾ.

ഇനി നമുക്ക് keyring_file-നെ കുറിച്ച് കുറച്ചുകൂടി സംസാരിക്കാം. ഞാൻ keyring_file വികസിപ്പിച്ചെടുക്കുമ്പോൾ, സെർവർ പ്രവർത്തിക്കുമ്പോൾ keyring_file മാറ്റങ്ങൾ എങ്ങനെ പരിശോധിക്കാം എന്നതിനെ കുറിച്ചും ഞാൻ ആശങ്കാകുലനായിരുന്നു. 5.7-ൽ, ഫയൽ സ്ഥിതിവിവരക്കണക്കുകൾ അടിസ്ഥാനമാക്കിയാണ് പരിശോധന നടത്തിയത്, അത് അനുയോജ്യമായ ഒരു പരിഹാരമായിരുന്നില്ല, 8.0-ൽ അത് SHA256 ചെക്ക്സം ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിച്ചു.

നിങ്ങൾ ആദ്യമായി keyring_file പ്രവർത്തിപ്പിക്കുമ്പോൾ, ഫയൽ സ്ഥിതിവിവരക്കണക്കുകളും ഒരു ചെക്ക്‌സവും കണക്കുകൂട്ടും, അവ സെർവർ ഓർമ്മിക്കും, മാറ്റങ്ങൾ പൊരുത്തപ്പെടുന്നെങ്കിൽ മാത്രമേ ബാധകമാകൂ. ഫയൽ മാറുമ്പോൾ, ചെക്ക്സം അപ്ഡേറ്റ് ചെയ്യപ്പെടും.

പ്രധാന നിലവറകളെക്കുറിച്ചുള്ള നിരവധി ചോദ്യങ്ങൾ ഞങ്ങൾ ഇതിനകം ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. എന്നിരുന്നാലും, പലപ്പോഴും മറന്നുപോകുകയോ തെറ്റിദ്ധരിക്കപ്പെടുകയോ ചെയ്യുന്ന മറ്റൊരു പ്രധാന വിഷയമുണ്ട്: സെർവറുകളിലുടനീളം കീകൾ പങ്കിടൽ.

ഞാൻ ഉദ്ദേശിച്ചത്? ക്ലസ്റ്ററിലെ ഓരോ സെർവറിനും (ഉദാഹരണത്തിന്, പെർക്കോണ സെർവർ) വോൾട്ട് സെർവറിൽ ഒരു പ്രത്യേക സ്ഥാനം ഉണ്ടായിരിക്കണം, അതിൽ പെർക്കോണ സെർവർ അതിന്റെ കീകൾ സൂക്ഷിക്കണം. സ്റ്റോറേജിൽ സംരക്ഷിച്ചിരിക്കുന്ന ഓരോ മാസ്റ്റർ കീയിലും അതിന്റെ ഐഡന്റിഫയറിൽ പെർകോണ സെർവറിന്റെ GUID അടങ്ങിയിരിക്കുന്നു. എന്തുകൊണ്ട് അത് പ്രധാനമാണ്? നിങ്ങൾക്ക് ഒരു വോൾട്ട് സെർവർ മാത്രമേയുള്ളൂവെന്നും ക്ലസ്റ്ററിലെ എല്ലാ പെർക്കോണ സെർവറുകളും ആ ഒറ്റ വോൾട്ട് സെർവർ ഉപയോഗിക്കുന്നുണ്ടെന്നും സങ്കൽപ്പിക്കുക. പ്രശ്നം വ്യക്തമാണെന്ന് തോന്നുന്നു. എല്ലാ Percona സെർവറുകളും id = 1, id = 2, എന്നിങ്ങനെയുള്ള അദ്വിതീയ ഐഡന്റിഫയറുകൾ ഇല്ലാതെ ഒരു മാസ്റ്റർ കീ ഉപയോഗിച്ചാൽ, ക്ലസ്റ്ററിലെ എല്ലാ സെർവറുകളും ഒരേ മാസ്റ്റർ കീ ഉപയോഗിക്കും. GUID നൽകുന്നത് സെർവറുകൾ തമ്മിലുള്ള വ്യത്യാസമാണ്. ഒരു അദ്വിതീയ GUID നിലവിലുണ്ടെങ്കിൽ സെർവറുകൾക്കിടയിൽ കീകൾ പങ്കിടുന്നതിനെക്കുറിച്ച് എന്തിനാണ് സംസാരിക്കുന്നത്? മറ്റൊരു പ്ലഗിൻ ഉണ്ട് - keyring_udf. ഈ പ്ലഗിൻ ഉപയോഗിച്ച്, നിങ്ങളുടെ സെർവർ ഉപയോക്താവിന് അവരുടെ കീകൾ വോൾട്ട് സെർവറിൽ സംഭരിക്കാൻ കഴിയും. ഒരു ഉപയോക്താവ് സെർവർ 1-ൽ ഒരു കീ സൃഷ്ടിക്കുമ്പോൾ പ്രശ്നം സംഭവിക്കുന്നു, ഉദാഹരണത്തിന്, സെർവർ 2-ൽ അതേ ഐഡി ഉപയോഗിച്ച് ഒരു കീ സൃഷ്ടിക്കാൻ ശ്രമിക്കുമ്പോൾ, ഉദാഹരണത്തിന്:

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

കാത്തിരിക്കൂ. രണ്ട് സെർവറുകളും ഒരേ വോൾട്ട് സെർവർ ആണ് ഉപയോഗിക്കുന്നത്, സെർവർ2-ൽ keyring_key_store ഫംഗ്‌ഷൻ പരാജയപ്പെടേണ്ടതല്ലേ? രസകരമെന്നു പറയട്ടെ, നിങ്ങൾ ഒരു സെർവറിൽ ഇത് ചെയ്യാൻ ശ്രമിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഒരു പിശക് ലഭിക്കും:

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

അത് ശരിയാണ്, ROB_1 ഇതിനകം നിലവിലുണ്ട്.

രണ്ടാമത്തെ ഉദാഹരണം ആദ്യം ചർച്ച ചെയ്യാം. ഞങ്ങൾ നേരത്തെ പറഞ്ഞതുപോലെ, keyring_vault അല്ലെങ്കിൽ മറ്റേതെങ്കിലും കീറിംഗ് പ്ലഗിൻ മെമ്മറിയിലെ എല്ലാ കീ ഐഡികളും കാഷെ ചെയ്യുന്നു. അതിനാൽ, ഒരു പുതിയ കീ സൃഷ്ടിച്ച ശേഷം, ROB_1 സെർവർ 1-ലേക്ക് ചേർക്കുന്നു, കൂടാതെ ഈ കീ വോൾട്ടിലേക്ക് അയയ്‌ക്കുന്നതിന് പുറമേ, കീയും കാഷെയിലേക്ക് ചേർക്കുന്നു. ഇപ്പോൾ, നമ്മൾ അതേ കീ രണ്ടാമതും ചേർക്കാൻ ശ്രമിക്കുമ്പോൾ, keyring_vault കീ കാഷെയിൽ ഉണ്ടോ എന്ന് പരിശോധിക്കുകയും ഒരു പിശക് തള്ളുകയും ചെയ്യുന്നു.

ആദ്യ കേസിൽ സ്ഥിതി വ്യത്യസ്തമാണ്. സെർവർ1, സെർവർ2 എന്നിവയ്ക്ക് പ്രത്യേക കാഷെകളുണ്ട്. സെർവർ1, വോൾട്ട് സെർവർ എന്നിവയിലെ കീ കാഷെയിലേക്ക് ROB_1 ചേർത്തതിന് ശേഷം, സെർവർ2-ലെ കീ കാഷെ സമന്വയത്തിന് പുറത്താണ്. സെർവർ2-ലെ കാഷെയിൽ ROB_1 കീ ഇല്ല. അങ്ങനെ, ROB_1 കീ കീറിംഗ്_കീ_സ്റ്റോറിലേക്കും വോൾട്ട് സെർവറിലേക്കും എഴുതപ്പെടുന്നു, അത് യഥാർത്ഥത്തിൽ മുമ്പത്തെ മൂല്യത്തെ തിരുത്തിയെഴുതുന്നു (!). ഇപ്പോൾ വോൾട്ട് സെർവറിലെ ROB_1 കീ 543210987654321 ആണ്. രസകരമെന്നു പറയട്ടെ, വോൾട്ട് സെർവർ അത്തരം പ്രവർത്തനങ്ങളെ തടയില്ല, പഴയ മൂല്യം എളുപ്പത്തിൽ പുനരാലേഖനം ചെയ്യുന്നു.

നിങ്ങൾ keyring_udf ഉപയോഗിക്കുകയും വോൾട്ടിൽ കീകൾ സംഭരിക്കാൻ ആഗ്രഹിക്കുകയും ചെയ്യുമ്പോൾ Vault-ലെ സെർവർ പാർട്ടീഷൻ പ്രധാനമായിരിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് ഇപ്പോൾ നമുക്ക് കാണാൻ കഴിയും. ഒരു വോൾട്ട് സെർവറിൽ ഈ വേർതിരിവ് എങ്ങനെ നേടാം?

വോൾട്ടിലേക്ക് വിഭജിക്കാൻ രണ്ട് വഴികളുണ്ട്. ഓരോ സെർവറിനുമായി നിങ്ങൾക്ക് വ്യത്യസ്ത മൌണ്ട് പോയിന്റുകൾ സൃഷ്ടിക്കാം, അല്ലെങ്കിൽ ഒരേ മൗണ്ട് പോയിന്റിനുള്ളിൽ വ്യത്യസ്ത പാതകൾ ഉപയോഗിക്കുക. ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് ഇത് നന്നായി ചിത്രീകരിക്കുന്നു. അതിനാൽ നമുക്ക് ആദ്യം വ്യക്തിഗത മൗണ്ട് പോയിന്റുകൾ നോക്കാം:

--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 = (...)

സെർവർ1, സെർവർ2 എന്നിവ വ്യത്യസ്ത മൗണ്ട് പോയിന്റുകൾ ഉപയോഗിക്കുന്നത് ഇവിടെ കാണാം. പാതകൾ വിഭജിക്കുമ്പോൾ, കോൺഫിഗറേഷൻ ഇതുപോലെ കാണപ്പെടും:

--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 = (...)

ഈ സാഹചര്യത്തിൽ, രണ്ട് സെർവറുകളും ഒരേ മൗണ്ട് പോയിന്റ് "മൌണ്ട്_പോയിന്റ്" ഉപയോഗിക്കുന്നു, എന്നാൽ വ്യത്യസ്ത പാതകൾ. ഈ പാത്ത് ഉപയോഗിച്ച് സെർവർ1-ൽ നിങ്ങൾ ആദ്യ രഹസ്യം സൃഷ്ടിക്കുമ്പോൾ, വോൾട്ട് സെർവർ സ്വയമേവ ഒരു "സെർവർ1" ഡയറക്ടറി സൃഷ്ടിക്കുന്നു. സെർവർ 2 ന് എല്ലാം സമാനമാണ്. 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) കോൺഫിഗറേഷൻ ഫയലിന്റെ പാരാമീറ്ററുകളുമായി പൊരുത്തപ്പെടുന്നു. തീർച്ചയായും, നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ വോൾട്ട് യൂട്ടിലിറ്റികൾ ഉപയോഗിക്കാം. എന്നാൽ ഒരു മൗണ്ട് പോയിന്റ് സൃഷ്ടിക്കുന്നത് ഓട്ടോമേറ്റ് ചെയ്യുന്നത് എളുപ്പമാണ്. ഈ വിവരങ്ങൾ നിങ്ങൾക്ക് ഉപയോഗപ്രദമാണെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു, ഈ പരമ്പരയിലെ അടുത്ത ലേഖനങ്ങളിൽ ഞങ്ങൾ നിങ്ങളെ കാണും.

കൂടുതൽ വായിക്കുക:

• സിസ്‌ബെഞ്ചും റാൻഡം വേരിയബിളുകളുടെ വിതരണവും

അവലംബം: www.habr.com