საბრძოლო სერტიფიკატს ვადა გაუვიდა და არავინ შეამჩნია: გარე პროქსიმ ავარია საკუთარი თავით დაფარა
ყველა საჯარო ჰოსტი 200-ს აბრუნებდა, კლასტერი კი ვადაგასულ wildcard-ს აძლევდა. საკუთარი TLS-ის მქონე პროქსიმ ავარია დამალა; ნამდვილი მიგნება ვადის ალერტის არარსებობა იყო.
Optimacros-ში ამოცანა რუტინად მოვიდა: „ახალი სერტიფიკატები მარკეტინგული საიტების კლასტერისთვის“, არქივი სერტიფიკატით, გასაღებით და CA ჯაჭვით. ინვენტარიზაციისას აღმოჩნდა, რომ კლასტერში სერტიფიკატს ვადა 49 წუთის წინ გაუვიდა — და ამის შესახებ არავის არაფერი უთქვამს. არც ალერტს, არც მომხმარებლებს, არც მონიტორინგს. ხუთივე საჯარო ჰოსტი 200-ს აბრუნებდა.
რატომ არ გამოვლინდა ავარია
ტოპოლოგია ჰიბრიდულია. გარე პროქსი ცალკე VM-ზე თავად წყვეტს TLS-ს და კლასტერის origin-თან მიდის მისი სერტიფიკატის შემოწმების გარეშე. ახალი სერტიფიკატი ამ პროქსიზე ვიღაცამ ერთი კვირით ადრე გაშალა: ცოცხალი :443-ის სერიული ნომერი არქივის ფაილს ბაიტ-ბაიტ დაემთხვა. გარედან ყველაფერი გამართულად ჩანდა.
გატეხილი იყო სხვა გზა — კლასტერის gateway-ში პირდაპირი შესვლა SNI-ით. მას იყენებენ health-check-ები, მონიტორინგი და ყველაფერი, რაც პროქსის გვერდს უვლის. მათთვის სერვისი გათიშული იყო.
„საიტი 200-ს აბრუნებს“ TLS-ზე არაფერს ამტკიცებს, თუ მის წინ საკუთარი ტერმინაციის მქონე პროქსი დგას. შეამოწმე ის გზა, რომელსაც აკეთებ, და არა ის, რომლის შემოწმებაც მოსახერხებელია:
echo | openssl s_client -connect <gateway-ip>:443 -servername <host> \
| openssl x509 -noout -serial -enddate
შეაკეთე წყაროში
Kubernetes-ის საიდუმლოებებს Vault Secrets Operator მართავდა, ამიტომ kubectl apply ცვლილებას ხუთ წუთში წაშლიდა. სერტიფიკატი Vault-ში უნდა ჩაწერილიყო, გაშლას კი ოპერატორი იზამდა.
ჩაწერამდე მასალა შევამოწმე: გასაღების modulus სერტიფიკატს დაემთხვა, openssl verify CA ჯაჭვით გაიარა. შემდეგ Vault-ის მიმდინარე ვერსიების ბექაპი, შემდეგ ჩაწერა — სრული ჯაჭვის და არა მხოლოდ leaf-ის. ლოკალური openssl leaf-ზეც OK-ს ამბობს, რადგან შუალედური სერტიფიკატი სამუშაო სადგურის საცავში უკვე დევს, მობილური კლიენტები და მინიმალური იმიჯები კი unable to get local issuer certificate-ით ვარდებიან. მნიშვნელოვანი შემოწმებაა curl -w '%{ssl_verify_result}' სუფთა კლიენტიდან. სულ დაახლოებით 15 წუთი, დაუნთაიმის გარეშე.
დასკვნები
- ნამდვილი ძირეული მიზეზი გვიანი შეცვლა კი არა, სერტიფიკატის ვადის ალერტის არარსებობაა. Blackbox პრობა
probe_ssl_earliest_cert_expiry-ზე მთელ ფლოტს ერთბაშად ფარავს. - საკუთარი TLS ტერმინაციის მქონე პროქსის შეუძლია მკვდარი სერტიფიკატი დამალოს. ყოველი შესასვლელი ცალკე შეამოწმე.
- საიდუმლოებები იქ შეასწორე, სადაც მათი ჭეშმარიტების წყაროა, თორემ ოპერატორი შენს ცვლილებას დააბრუნებს.
- ყოველთვის სრული ჯაჭვი ჩადე და შეამოწმე კლიენტით ზედმეტი შუალედური სერტიფიკატების გარეშე.