Deploy a Google-managed certificate with DNS authorization
На вихідних вирішив покрутити трохи GCP, бо давно не мав з ним справ, та і загалом T-shaped дуже добре будувати. Знайшов старий pet-project, і там заекспейрились SSL сертифікати, які б мали реньюватись Certificate Manager-ом, але щось пішло не так.
Знайшов фічу, якій не так багато часу DNS Auth для GCP Certificate Manager:
https://cloud.google.com/certificate-manager/docs/deploy-google-managed-dns-auth#terraform
Виглядає класно, підтикуємо кастомний домен звідки-завгодно, далі CNAME туди ж, з цим рекордом явно нічого не станеться + ще і wildcard можна прикрутити.
Власне, додалось легко, підтвердився овнершип домену швидко, тим паче вайлдкардовий, тільки сам сертифікат потрапив не в Classic Certificates, а в просто Certificates. Ну, думаю, це ж GCP, ладно вже.
Далі дока змусила мене створити certmap і map entry, ізі, і на цьому етапі виявилось що в мене немає кнопки "підтикнути його" в Load Balancer (це взагалі окрема тема, як виходить, в GCP зовсім не канонічні балансери, а набір ресурсів, які роблять щось схоже).
І тут виходить проблема, бо я наче молодець, сертифікат є, а підсунути його в балансер не можу. Покопав погуглив, знайшов що в ресурс google_compute_target_https_proxy передається параметр certificate_map, і має бути ок. Передав, еплайнулось.
І тут новий прикол: бачу, що юзається вже новий стек з domain + dns auth + wildcard cert + certmap + entry. Але, GCP мені в консолі показує чудовий приатачений старий сертифікат, і тільки в сетінгах самого target proxy типу так дуже обережно показує, що там ще є і Certificate Map. Чому так? Загадка.
Далі наступна штука: gce-ingress, який по суті і створював цей LB (точніше, як ми зрозуміли, набір ресурсів, який - є "типу" LB), ролбекнув certmap і залишив старий невалідний сертифікат. Топ.
Зрозуміло, що я пішов дивитись як засунути brand-new bundle в gce-ingress, а там така халепа:
https://github.com/kubernetes/ingress-gce/issues/1692
Тобто, ви НЕ можете передати через анотації, вельюси, вотевер certificate map в gce-ingress.
Ну і самарі, до чого ми прийшли:
➕ GCP зробив круту фічу, яка допоможе згенерити вайлдкардовий сертифікат, підтвердити овнершип домену через CNAME, і не паритись з рефрешем (всі http-based рефреші в мене рано чи пізно відвалювались)
➕ GCP зробив чудовий gce-ingress, який розуміє кастомну реалізацію LB в GCP, і збирає сетап всіх ресурсів в купу, на виході - робочий варіант
➖GCP не підтримує свою фічу 1 в своєму рішенні 2
А в іншому, GCP це мабуть класний клауд 😆
На вихідних вирішив покрутити трохи GCP, бо давно не мав з ним справ, та і загалом T-shaped дуже добре будувати. Знайшов старий pet-project, і там заекспейрились SSL сертифікати, які б мали реньюватись Certificate Manager-ом, але щось пішло не так.
Знайшов фічу, якій не так багато часу DNS Auth для GCP Certificate Manager:
https://cloud.google.com/certificate-manager/docs/deploy-google-managed-dns-auth#terraform
Виглядає класно, підтикуємо кастомний домен звідки-завгодно, далі CNAME туди ж, з цим рекордом явно нічого не станеться + ще і wildcard можна прикрутити.
Власне, додалось легко, підтвердився овнершип домену швидко, тим паче вайлдкардовий, тільки сам сертифікат потрапив не в Classic Certificates, а в просто Certificates. Ну, думаю, це ж GCP, ладно вже.
Далі дока змусила мене створити certmap і map entry, ізі, і на цьому етапі виявилось що в мене немає кнопки "підтикнути його" в Load Balancer (це взагалі окрема тема, як виходить, в GCP зовсім не канонічні балансери, а набір ресурсів, які роблять щось схоже).
І тут виходить проблема, бо я наче молодець, сертифікат є, а підсунути його в балансер не можу. Покопав погуглив, знайшов що в ресурс google_compute_target_https_proxy передається параметр certificate_map, і має бути ок. Передав, еплайнулось.
І тут новий прикол: бачу, що юзається вже новий стек з domain + dns auth + wildcard cert + certmap + entry. Але, GCP мені в консолі показує чудовий приатачений старий сертифікат, і тільки в сетінгах самого target proxy типу так дуже обережно показує, що там ще є і Certificate Map. Чому так? Загадка.
Далі наступна штука: gce-ingress, який по суті і створював цей LB (точніше, як ми зрозуміли, набір ресурсів, який - є "типу" LB), ролбекнув certmap і залишив старий невалідний сертифікат. Топ.
Зрозуміло, що я пішов дивитись як засунути brand-new bundle в gce-ingress, а там така халепа:
https://github.com/kubernetes/ingress-gce/issues/1692
Тобто, ви НЕ можете передати через анотації, вельюси, вотевер certificate map в gce-ingress.
Ну і самарі, до чого ми прийшли:
➕ GCP зробив круту фічу, яка допоможе згенерити вайлдкардовий сертифікат, підтвердити овнершип домену через CNAME, і не паритись з рефрешем (всі http-based рефреші в мене рано чи пізно відвалювались)
➕ GCP зробив чудовий gce-ingress, який розуміє кастомну реалізацію LB в GCP, і збирає сетап всіх ресурсів в купу, на виході - робочий варіант
➖GCP не підтримує свою фічу 1 в своєму рішенні 2
А в іншому, GCP це мабуть класний клауд 😆