Nano Hash - криптовалюты, майнинг, программирование

Использовать HTTPS для Kubernetes nginx-ingress

Я хочу использовать HTTPS для своего Kubernetes в Azure (AKS). Для этого я использую nginx-ingress (https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md#azure). Все ресурсы, которые я создал в этом руководстве, используют пространство имен ingress-nginx. Вот почему я продолжаю использовать это пространство имен вместо пространства по умолчанию. Мой Ingress работает нормально. Теперь я хочу использовать HTTPS вместо HTTP.

Для этого я создал CSR:

openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out example.csr -subj "/CN=domain.com"

Я отправляю CSR поставщику подписи (QuoVadis), который отправляет мне обратно следующие файлы:

  • domain_com (цепочка) .crt
  • domain_com.crt
  • QuoVadis_Global_SSL_ICA_G2.crt
  • QuoVadis_Root_CA_2.crt

Я немного сбит с толку, потому что во всех уроках я обнаружил, что упоминается только один crt. Цепочка выглядит как комбинация всех трех других файлов. Вот почему я продолжил цепочку:

sudo kubectl create secret tls ssl-secret-test --cert domain_com(chain).crt --key private.key -n ingress-nginx

Я добавил секрет в свой вход:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: ingress-nginx
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
  - hosts:
    - domain.com
    secretName: ssl-secret-test
  rules:
  - host: domain.com
  - http:
      paths:
      - path: /app1(/|$)(.*)
        backend:
          serviceName: app1-service
          servicePort: 80
      - path: /app2(/|$)(.*)
        backend:
          serviceName: app2-service
          servicePort: 80

Мои развертывания app1 и app2 больше не доступны для домена. Если я использую IP-адрес, он все еще работает:

domain.com/app1:

404 Not Found - openresty / 1.15.8.1

52.xxx.xxx.xx / app1:

Привет, мир

В обоих случаях я все равно получаю предупреждение о незащищенном соединении. Вот обзор моих услуг:

$ sudo kubectl get svc --all-namespaces
NAMESPACE       NAME                             TYPE           CLUSTER-IP     EXTERNAL-IP                                  PORT(S)                      AGE
default         kubernetes                       ClusterIP      10.0.0.1       <none>                                       443/TCP                      57d
ingress-nginx   app1-service                     NodePort       10.0.229.109   <none>                                       80:31343/TCP                 22h
ingress-nginx   app2-service                     NodePort       10.0.175.201   <none>                                       80:31166/TCP                 22h
ingress-nginx   ingress-nginx                    LoadBalancer   10.0.40.172    52.xxx.xxx.xx                                80:32564/TCP,443:32124/TCP   22h
kube-system     healthmodel-replicaset-service   ClusterIP      10.0.233.181   <none>                                       25227/TCP                    5d10h
kube-system     heapster                         ClusterIP      10.0.214.146   <none>                                       80/TCP                       57d
kube-system     kube-dns                         ClusterIP      10.0.0.10      <none>                                       53/UDP,53/TCP                57d
kube-system     kubernetes-dashboard             ClusterIP      10.0.160.230   <none>                                       80/TCP                       57d
kube-system     metrics-server                   ClusterIP      10.0.170.103   <none>                                       443/TCP                      57d

$ sudo kubectl get ingress --all-namespaces
NAMESPACE       NAME            HOSTS              ADDRESS         PORTS     AGE
ingress-nginx   nginx-ingress   domain.com         52.xxx.xxx.xx   80, 443   37m

$ sudo kubectl get deployments --all-namespaces
NAMESPACE       NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
ingress-nginx   app1                       2         2         2            2           22h
ingress-nginx   app2                       2         2         2            2           22h
ingress-nginx   nginx-ingress-controller   1         1         1            1           57d
kube-system     coredns                    2         2         2            2           58d
kube-system     coredns-autoscaler         1         1         1            1           58d
kube-system     heapster                   1         1         1            1           5d10h
kube-system     kubernetes-dashboard       1         1         1            1           58d
kube-system     metrics-server             1         1         1            1           58d
kube-system     omsagent-rs                1         1         1            1           58d
kube-system     tunnelfront                1         1         1            1           58d

Что я делаю не так?

Обновление с помощью cert-manager

Я выполнил следующий урок:

https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html

и подтвердил все на примере test-resources.yaml.

Теперь я выполнил шаги по настройке CA ISSUER.

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: domain-com
  namespace: default
spec:
  secretName: domain-com-tls
  issuerRef:
    name: ca-issuer
    kind: ClusterIssuer
  commonName: domain.com
  organization:
  - QuoVadis
  dnsNames:
  - domain.com
  - www.domain.com
-----
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: ca-issuer
  namespace: default
spec:
  ca:
    secretName: ssl-secret-test

Но вроде не работает:

$ kubectl describe certificate domain-com
...
Status:
  Conditions:
    Last Transition Time:  2019-09-12T07:48:19Z
    Message:               Certificate does not exist
    Reason:                NotFound
    Status:                False
    Type:                  Ready
  Not After:               2021-09-11T07:46:00Z
Events:
  Type     Reason          Age                 From          Message
  ----     ------          ----                ----          -------
  Warning  IssuerNotReady  8s (x9 over 4h51m)  cert-manager  Issuer ca-issuer not ready

А на странице устранения неполадок я обнаружил дополнительную неопределенность:

$ kubectl --namespace cert-manager get secret cert-manager-webhook-webhook-tls
Error from server (NotFound): secrets "cert-manager-webhook-webhook-tls" not found

  • так что просто из любопытства это причина, по которой вы не пытаетесь использовать такое решение, как cert-manager, поскольку я верю, что m-manager сертификатов - это тот, который требует, чтобы вы в разделе tls установили хост docs.cert-manager.io/en/latest/getting-started/install/ , дайте мне знать, если это то, что вы ищете, и я напишу полный ответ 12.09.2019
  • Я также читал о cert-manager. Я думал, что это такой инструмент, как HELM / Tiller. Полезно, но не обязательно. Это первый созданный мной кластер. Вот почему я хотел сделать все с нуля без этих инструментов. Чтобы я получил глубокое понимание того, как все работает. Во всяком случае, я смотрю cert-manager. Благодарю за ваш ответ. 12.09.2019

Ответы:


1

Я ответил в комментариях, но просто добавлю здесь ответ:

Cert Manager - это самый простой способ обработки TLS с входящим потоком nginx, после его настройки здесь https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html когда вы определите свой входящий трафик, он будет выглядеть примерно так:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: ingress-nginx
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/ingress.class: "nginx" <-- This is very important to define which ingress controller to use
    certmanager.k8s.io/cluster-issuer: letsencrypt-staging <-- defines the cert manager issuer
spec:
  tls:
  - hosts:
    - domain.com
    secretName: ssl-secret-test
  rules:
  - host: domain.com
  - http:
      paths:
      - path: /app1(/|$)(.*)
        backend:
          serviceName: app1-service
          servicePort: 80
      - path: /app2(/|$)(.*)
        backend:
          serviceName: app2-service
          servicePort: 80

Затем диспетчер сертификатов настроит TLS для вашей службы.

12.09.2019
  • Редактирую свой вопрос. CA Issuer правильный или я ошибаюсь? И вы видите что-нибудь, что я делаю неправильно? 12.09.2019
  • вопрос, есть ли причина, по которой вы не пользуетесь функцией шифрования? 12.09.2019
  • Спецификация моей компании: / 12.09.2019
  • Просто спрашиваю, поскольку я еще не использовал подписанный сертификат с менеджером сертификатов. 12.09.2019
  • У вас, может быть, есть ответ на вопрос, почему я все еще могу получить доступ к входу через IP и получить не найденный доменом? 12.09.2019
  • Это могло быть связано с вашей DNS-маршрутизацией? 13.09.2019
  • Я думаю, что либо мы переместим это в чат, либо зададим другой вопрос о маршрутизации DNS, иначе это будет помечено \ 13.09.2019
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..