GCP Google Managed SSL без HTTPS Load Balancer

Нельзя, приватный ключ гугл тебе не даст. Только в External HTTPS load balancers и SSL proxy load balancers.

печально это. при https lb и соотственно без legacy ingress внутри самого k8s , gke создает новый https lb под каждый сервис,и чтобы это обойти нужны неудобные велосипеды.

Делай как все, используй сертификаты от Let’s Encrypt через cert-manager :)

приватный ключ гугл тебе не даст.

технически он и не нужен по идее. я могу запросить сертификат, а затем гугл может каким-нить cert-manager внутри k8s проверить, что А запись корректа, сервис отвечает и запровиженить сертификат ( ну как делает letsencrypt)

используй сертификаты от Let’s Encrypt

куча команд , проекты на стадии миграции. один домен 2 уровня на все проекты. короче, лимит 50 сертификатов Let’s Encrypt в неделю набирается легко, если кто-то наичнает тестить что-то не на stage.

один домен 2 уровня на все проекты. короче, лимит 50 сертификатов Let’s Encrypt в неделю набирается легко, если кто-то наичнает тестить что-то не на stage.

А почему бы не выпустить wildcard-сертификат?

А почему бы не выпустить wildcard-сертификат?

куча gke, обычных vm и прочее, каждая команда работает над своими проектами. Нужно будет изобретать велосипед по деплою этого сертификата везде, и все равно будет костыль, да и небезопасно просрать приватный ключ от wildcard, человеческий фактор никто не отменял. Странно, что гугль сделал такую хрень. Интересно, как это решено на aws.

А сколько у вас production-доменов реально требуется выставлять наружу - для frontend и пр.?

В принципе, можно пропускать все транзитом через обычный Nginx-deployment (не путать с Nginx-балансировщиком), прикрученный непосредственно к TCP-балансировщику. Фронтовую production-часть деплоить прям в этот Nginx. Доступ к конфигурации Nginx ограничить с помощью RBAC так, чтобы разработчики вообще не имели туда доступа. Ну и wildcard-сертификат…

Я вот именно таким образом кластер спроектировал.

прикрученный непосредственно к TCP-балансировщику

так google managed SSL не получить

А сколько у вас production-доменов реально требуется выставлять наружу

кластеров много, еще всякие легаси виртуалки есть, у каждой команды свое. Общее только домен второго вровня domain.com , дальше используются домены вида *.project1.domain.com *.project2.domain.com

А сколько у вас production-доменов реально требуется выставлять наружу

Не думаю, что это можно подсчитать, но так как остальные команды используют в основном https lb (им нужны там сloud armor и прочие штуки, поэтому они фигачат как есть по балансеру на фронт), то нам (как команде) должно хватить 100 сертификатов от lets-encrypt.

так google managed SSL не получить

так и не надо получать - просто создаете в кластере ingress типа:

kind: Service
apiVersion: v1
metadata:
  name: "some_name"
spec:
  externalTrafficPolicy: Local
  type: LoadBalancer
  selector:
    
    # ПРИМЕЧАНИЕ: Pod-объекты Nginx имеют аналогичную метку 'ingress: nginx-prod'    
    ingress: nginx-prod

  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
  #
  #loadBalancerIP: x.x.x.x

и соответствующий Deployment c Nginx-репликами.

В Nginx-реплики засовываете wildcard-сертификат от Let’s Encrypt и конфигурации нужных доменов с проксированием на соответствующие backend-сервисы. Кучу GKE-шных кластеров в принципе можно трансформировать в кучу namespace-ов одного кластера, возможно, с выделенными пулами узлов, если это требуется.

Правда, судя по орг-структуре вашей деятельности, такой вариант может не подойти.

В Nginx-реплики засовываете wildcard-сертификат от Let’s Encrypt

вопрос-то был не о том, как мне запихать серт от let’s encrypt. с этим проблем нет, и велосипедов я могу тоже наизобретать кучу;)

Вопрос был , как бы заюзать сертификаты от гугл.

Ну извиняй - немного не понял ) Я просто подумал, что тебе схема «GKE + TCP LB + терминирование SSL на уровне ingress» нужна, чтобы немного денежек сэкономить отказавшись от лишних HTTP-балансировщиков. Но видимо здесь имеются какие-то другие соображения…

Ну а то, что гуглы не дают тебе секретные ключи SSL-сертификатов, так в этом нет ничего странного - они же деньги зарабатывают, поэтому навязывают в придачу всякие дорогие плюшки.

https://cloud.google.com/load-balancing/docs/ssl-certificates/self-managed-certs

может наведет на какие-то мысли… )

да, там они долго объясняют, как сгенерировать сертификат, ключ и реквест самому. А затем строчка о том, что надо послать реквест в CA центр(не в гуглевый) :)

Смысл этого раздела документации в том, что если тебе нужен полностью свой сертификат с секретным ключом, который ты можешь использовать и в гугловых HTTP-балансировщиках и еще где угодно - тебе ведь этого хочется? - то ты должен немного потрудиться и завести его самостоятельно, ну и пролонгировать потом тоже самостоятельно :)

то ты должен немного потрудиться и завести его самостоятельно

это все хорошо, но гугл не предлагает мне через свой серт-центр выпускать сертификат по моему реквесту ( без этой функции все бессмысленно). Он просто описывает создание этого реквеста. И все.

те гугл не собирается никаким образом подписывать мой сертификат

Про то, каким центром воспользоваться, в доке вообще ничего не сказано. Гуглу в общем-то по фигу, где ты получишь сертификат - главное, чтобы центр входил в список достаточно надежных. Полученный сертификат (не важно у кого) ты можешь зарегить у гугла (Step 2: Create a self-managed SSL certificate resource; Step 3: Associate an SSL certificate with a target proxy) и пользовать в других местах.

Перечитай еще внимательно рядом раздел «Overview».

Гуглу в общем-то по фигу, где ты получишь сертификат

но тогда мне пофиг на гугл. если у меня есть где-то серт центр с апи, за сертифаты которого я уже плачу, то мне не нужен гугл. я терминирую SSL на ingress. Мне не нужна вся эта дальнейшая песня о том, что я могу заснуть свой серт в HTTPS Lb.

Это почти тоже самое, как я получу сертификат от lets’ encrypt. Никакого отношения к google managed SSL это не имеет .

Подписать какой-то договор с каким-то серт центром в моих реалиях вообще невозможно. Никто жопу для этого не поднимет.

... Мне не нужна вся эта дальнейшая песня о том, что я могу заснуть свой серт в HTTPS Lb

Ну если в твоих проектах не нужен гугловый HTTP-балансировщик, то можешь не запихивать. Но ты вроде сказал, что у тебя используется в некоторых местах Cloud Armor.

Google managed SSL - это те же холявные сертификаты, что и от Let's Encrypt, просто меньше суеты с пролонгированием, но и жестко ограниченные варианты использования. Если тебе реально нужна работа через TCP-ingress (чтобы терминировать SSL внутри кластера), значит тебе нужен в этом конкретном случае self-managed сертификат - вот и все. Задействовать здесь google managed SSL не получится.

вот еще глянь:
https://cloud.google.com/kubernetes-engine/docs/concepts/ingress
https://cloud.google.com/kubernetes-engine/docs/how-to/managed-certs

Проблема-то в том, что:

When you create an Ingress object, the GKE Ingress controller creates a Google Cloud HTTP(S) Load Balancer and configures it according to the information in the Ingress and its associated Services.

Ну т.е. ты автоматом получаешь и платишь за Google Cloud HTTP(S) Load Balancer. Если тебе хочется терминировать SSL прям у себя в кубовских Pod-ах (типа, Nginx Deployment) без всяких лишних прокладок, то тебе такой вариант не подходит.

Я это все знаю.