„Vault თავად ილუქება“ — არა, ის უბრალოდ არასოდეს იხსნება

Optimacros-ში self-managed Kubernetes კლასტერში HashiCorp Vault მუშაობს — სამკვანძიანი HA raft კლასტერი. ერთ დილას Vault-ის ერთი პოდი Ready 0/1-ს აჩვენებდა და ასე უკვე დიდი ხანი იყო. vault status ამბობდა Sealed: true, Unseal Progress: 0/3. ჩემთვის ეს ასე აღწერეს: „Vault თავად ილუქება“.

რატომ ვერავინ შენიშნა

Raft-ს უმრავლესობა სჭირდება. სამი პირის შემთხვევაში ორი საკმარისია, ამიტომ საიდუმლოებები გაიცემოდა და Vault-იდან მკითხველი ყველა აპლიკაცია მუშაობდა. სწორედ ესაა საშიში: „დალუქულია, მაგრამ კვორუმი დგას“ — ჩუმი მდგომარეობაა, საიდანაც ავარიამდე ერთი რესტარტია. თუ მეორე პირი გადაიტვირთება, კლასტერი კვორუმს დაკარგავს და საიდუმლოების ყოველი წაკითხვა ჩავარდება.

მას არავინ ლუქავდა

ფრაზა „თავად ილუქება“ აქტიურ პროცესს გულისხმობს — ბაგს, პოლიტიკას, კონფიგურაციის შეცდომას, რომელიც Vault-ს ხელახლა ლუქავს. არაფერი ასეთი არ ყოფილა.

Seal-ის ტიპი იყო Shamir auto-unseal-ის გარეშე. Shamir-ის დროს Vault პროცესის ყოველი გადატვირთვის შემდეგ დალუქული იწყება და ელოდება, სანამ ადამიანი გასაღების წილების ზღვრულ რაოდენობას შეიყვანს. მას ხელახლა არავინ ლუქავს: ყოველი რესტარტი უბრალოდ დალუქულს ტოვებს და მას არაფერი აბრუნებს.

მინიშნება თავად პოდში იყო: restartCount=0 და საკმაოდ დიდი ასაკი. ის ერთხელ დაილუქა — (ხელახლა) შექმნისას — და უბრალოდ არავინ გახსნა. ამის უკან არასტაბილური ნოდის გამო რესტარტები იდგა: ყოველ ჯერზე, როცა Vault-ის პოდი მასზე ხვდებოდა და ნოდა ციმციმებდა, პოდი დალუქული ბრუნდებოდა.

გახსნა

კლასტერის შიგნით listener TLS-ის გარეშე მუშაობდა, VAULT_ADDR კი პოდში იყო მითითებული, ამიტომ CLI პირდაპირ kubectl exec-ით მუშაობდა — HTTP API-ით შემოვლითი გზა არ დაგვჭირდა:

kubectl -n <ns> exec <vault-pod> -- vault operator unseal   # სამჯერ, სამი სხვადასხვა წილი
kubectl -n <ns> exec <vault-pod> -- vault status | grep -iE 'Sealed|HA Mode|Raft Applied'

მესამე წილის შემდეგ კვანძი გაიხსნა, retry-join-ით raft-ში დაბრუნდა და ლიდერის applied index დაეწია.

ნამდვილი გამოსავალი

ხელით გახსნა მუშაობას აღადგენს, მაგრამ არაფერს ასწორებს. ნამდვილი გამოსავალია auto-unseal (transit ან ღრუბლოვანი KMS) Vault-ის Helm values-ში, რომ გადატვირთული პოდი თავად გაიხსნას. ამის შემდეგ მალევე transit auto-unseal-ზე გადავედით. მანამდე კი — Vault-ის პოდები არასტაბილური ნოდებიდან შორს და იმის შემოწმება, რომ VaultSealed ალერტი მართლაც მუშაობს.

გასაღებების შესახებ

Unseal-ის წილები არასოდეს ხვდება ჩატებში, ტიკეტებში, ლოგებსა და კომიტებში. თუ ისინი გამჟღავნდა, vault operator rekey სავალდებულოა და ის ადამიანმა დაცულ ტერმინალში უნდა შეასრულოს: rekey ახალ წილებს ბეჭდავს და მათი იმავე კომპრომეტირებულ არხში გატარება აზრს უკარგავს. ასევე გახსოვდეთ, რომ ბრძანების არგუმენტებად გადაცემული წილები წამიერად ჩანს პროცესების სიაში; საერთო მანქანებზე stdin უფრო უსაფრთხოა.

დასკვნები

• „თავად ილუქება“ ჩვეულებრივ ნიშნავს „არავინ გახსნა“. დალუქვის მექანიზმის ძებნამდე შეამოწმეთ restartCount და პოდის ასაკი.
• Shamir auto-unseal-ის გარეშე ნოდის ყოველ ციმციმს ხელით სამუშაოდ და რეზერვის ფარულ დაკარგვად აქცევს.
• „დალუქულია, მაგრამ კვორუმი დგას“ მომხმარებლებისთვის უხილავია და მონიტორინგისთვის ხილული უნდა იყოს.
• გამოსავალი auto-unseal-ია; გახსნის გასაღებები break-glass-ია და არა სამუშაო პროცედურა.