Два сертификата TLS для двух контроллеров Nginx Ingress в кластере Azure K8s

У меня есть два контроллера входа: один с классом по умолчанию nginx в пространстве имен default, а второй контроллер входа имеет nginx class: nginx-devices.

Cert-manager уже установлен с помощью Helm.

Мне удалось получить сертификат TLS от Lets Encrypt для первого контроллера, используя ClusterIssuer и правила ресурсов входа для маршрутизации Ingress.


apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  # name: letsencrypt-staging
  name: letsencrypt-prod
spec:
  acme:
    email: xx
    # server: https://acme-staging-v02.api.letsencrypt.org/directory
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # name: letsencrypt-staging
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Маршрутизация входящего трафика:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: serviceA-ingress-rules
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - FirstService.cloudapp.azure.com
    secretName: tls-secret
  rules:
  - host: FirstService.cloudapp.azure.com
    http:
      paths:
      - path: /serviceA
        backend:
          serviceName: serviceA
          servicePort: 80

Однако для создания второго сертификата TLS для второго контроллера входящего трафика секрет TLS не создается.

ClusterIssuer

# k8s/cluster-issuer.yaml

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  # name: letsencrypt-staging
  name: letsencrypt-prod-devices
  namespace: ingress-nginx-devices # namespace where the second ingress controller is installed
spec:
  acme:
    email: xxx
    # server: https://acme-staging-v02.api.letsencrypt.org/directory
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # name: letsencrypt-staging
      name: letsencrypt-prod-devices
    solvers:
    - http01:
        ingress:
          class: nginx-devices # ingress class of the second ingress controller

входящая маршрутизация

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: devices-ingress-rules
  namespace: default # since all the services are in default namespace
  annotations:
    kubernetes.io/ingress.class: nginx-devices # ingress class of the second ingress controller
    cert-manager.io/cluster-issuer: "letsencrypt-prod-devices" 
    ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - secondService.cloudapp.azure.com
    secretName: tls-secret
  rules:
  - host: secondService.cloudapp.azure.com
    http:
      paths:
      - path: /serviceB
        backend:
          serviceName: serviceB
          servicePort: 80

глядя на секрет, я вижу только: kubectl get secrets -n ingress-nginx-devices

NAME                                          TYPE                                  DATA   AGE
default-token-xzp95                           kubernetes.io/service-account-token   3      92m
nginx-ingress-devices-backend-token-pd4vf     kubernetes.io/service-account-token   3      64m
nginx-ingress-devices-token-qvvps             kubernetes.io/service-account-token   3      64m
sh.helm.release.v1.nginx-ingress-devices.v1   helm.sh/release.v1                    1      64m

в то время как в пространстве имен по умолчанию:

tls-secret                                          kubernetes.io/tls                     2      134m

Почему не генерируется второй tls-секрет? что здесь могло пойти не так?

Любая помощь приветствуется :)

ikenahim 20.04.2021 источник

comment

проверьте второй поставщик кластера с адресом сервера: server: acme-v02.api.letsencrypt.org/directory в то время как первый, если отличается. Промежуточный сертификат в основном не проверяется, поэтому вы можете получить ошибку сертификата SSL / TLS. - Harsh Manvar 20.04.2021

comment

Я не использую какой-либо промежуточный сертификат, и все адреса серверов одинаковы для обоих выпускающих кластеров;) - ikenahim 20.04.2021

comment

извините, прочитал закомментированный код - Harsh Manvar 20.04.2021

Ответы (1)

arrow_upward
2
arrow_downward

ваше второе пространство имен отправителя кластера: ingress-nginx-devices, в идеале оно должно находиться в пространстве имен по умолчанию, так как ваш входящий трафик находится в пространстве имен по умолчанию.

Сохраните эти три в одном пространстве имен:

Ingress
Clusterissuer
Услуга

если все будет работать хорошо, вы увидите секрет в пространстве имен по умолчанию

также в вашем YAML clusterissuer

privateKeySecretRef:
      # name: letsencrypt-staging
      name: letsencrypt-prod-devices

название вашего секрета: letsencrypt-prod-devices

но при входе это: tls-secret

оставь то же самое, иначе не сработает

здесь представлен полный пример того, как clusterissuer и ingress хранятся в одном пространстве имен. При необходимости вы можете изменить секретное имя, имя отправителя кластера. Clusterissuer создаст секрет автоматически, просто предоставив проверяющему имена секрета и отправителя кластера на входе (сопоставление).

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: cluster-issuer-name
  namespace: development
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: secret-name
    solvers:
    - http01:
        ingress:
          class: nginx-class-name
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx-class-name
    cert-manager.io/cluster-issuer: cluster-issuer-name
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: example-ingress
spec:
  rules:
  - host: sub.example.com
    http:
      paths:
      - path: /api
        backend:
          serviceName: service-name
          servicePort: 80
  tls:
  - hosts:
    - sub.example.com
    secretName: secret-name

Harsh Manvar 20.04.2021

comment

Я воспроизвел те же шаги, из браузера сертификат для второго входа генерируется «поддельным сертификатом контроллера Kubernetes Ingress», в то время как для первого контроллера входа все еще действующий сертификат от LetsEncrypt, что здесь может быть не так? - ikenahim; 20.04.2021

comment

это только когда вы использовали https://acme-staging-v02.api.letsencrypt.org/directory или сертификат все еще находится в процессе и обновляется внутри секрета. вы можете удалить секрет, clsuterissuer, ingress и попробовать применить снова - Harsh Manvar; 20.04.2021

comment

Я нигде не использую staging, где вы это видите? - ikenahim; 20.04.2021

comment

если вы использовали где-либо по ошибке или сертификат не сгенерирован из-за отсутствия конфигурации поставщика кластера и входа. - Harsh Manvar; 20.04.2021

comment

Нет, я его нигде не использую, я использую те же файлы, которыми поделился здесь, позвольте мне удалить секреты, clusterissuer и ingress и посмотреть, что может быть на выходе @thanks :) - ikenahim; 20.04.2021

Два сертификата TLS для двух контроллеров Nginx Ingress в кластере Azure K8s

Ответы (1)

Вопросы по теме