← ყველა სტატია

საბრძოლო სერტიფიკატს ვადა გაუვიდა და არავინ შეამჩნია: გარე პროქსიმ ავარია საკუთარი თავით დაფარა

ყველა საჯარო ჰოსტი 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 ტერმინაციის მქონე პროქსის შეუძლია მკვდარი სერტიფიკატი დამალოს. ყოველი შესასვლელი ცალკე შეამოწმე.
  • საიდუმლოებები იქ შეასწორე, სადაც მათი ჭეშმარიტების წყაროა, თორემ ოპერატორი შენს ცვლილებას დააბრუნებს.
  • ყოველთვის სრული ჯაჭვი ჩადე და შეამოწმე კლიენტით ზედმეტი შუალედური სერტიფიკატების გარეშე.