Включение SSL на конечных точках GKE работает некорректно - PullRequest
Новая
       97

Включение SSL на конечных точках GKE работает некорректно

1 голос
/ 09 мая 2020

Я создал API на GKE, используя конечные точки облака. Он отлично работает без Https Вы можете попробовать его здесь API без Https

Я выполнил инструкции, которые упоминаются здесь Включение SSL для конечной точки облака после настройки всего, что на этой странице упоминается, что я могу получить доступ к своим конечным точкам с помощью Https, но с предупреждением.

Ваше соединение не является частным - Back to Safety (Chrome)

Проверьте это здесь API с Https

Не могли бы вы сообщить мне, что мне не хватает

Обновление

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

Когда я go в своей облачной консоли, я вижу

Некоторые серверные службы находятся в НЕИЗВЕСТНОМ состоянии

Вот мои yaml разработки

deployment.yaml 

apiVersion: v1
kind: Service
metadata:
  name: quran-grpc
spec:
  ports:
  - port: 81
    targetPort: 9000
    protocol: TCP
    name: rpc
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  - port: 443
    protocol: TCP
    name: https
  selector:
    app: quran-grpc
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: quran-grpc
spec:
  replicas: 1
  selector:
    matchLabels:
      app: quran-grpc
  template:
    metadata:
      labels:
        app: quran-grpc
    spec:
      volumes:
        - name: nginx-ssl
          secret:
            secretName: nginx-ssl
      containers:
      - name: esp
        image: gcr.io/endpoints-release/endpoints-runtime:1
        args: [
          "--http_port=8080",
          "--ssl_port=443",
          "--http2_port=9000",
          "--backend=grpc://127.0.0.1:50051",
          "--service=quran.endpoints.utopian-button-227405.cloud.goog",
          "--rollout_strategy=managed",
        ]
        ports:
          - containerPort: 9000
          - containerPort: 8080
          - containerPort: 443
        volumeMounts:
          - mountPath: /etc/nginx/ssl
            name: nginx-ssl
            readOnly: true
      - name: python-grpc-quran
        image: gcr.io/utopian-button-227405/python-grpc-quran:5.0
        ports:
          - containerPort: 50051

ssl-cert.yaml 

apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: quran-ssl
spec:
  domains:
    - quran.endpoints.utopian-button-227405.cloud.goog
---
apiVersion: v1
kind: Service
metadata:
  name: quran-ingress-svc
spec:
  selector:
    name: quran-ingress-svc
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: quran-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: 34.71.56.199
    networking.gke.io/managed-certificates: quran-ssl
spec:
  backend:
    serviceName: quran-ingress-svc
    servicePort: 80

Не могли бы вы сообщить мне, что я м делаю неправильно.

1 Ответ

0 голосов
/ 11 мая 2020

Ваша конфигурация SSL работает нормально, и причина, по которой вы получаете эту ошибку, заключается в том, что вы используете самозаверяющий сертификат.

A самозаверяющий сертификат is сертификат , который не подписан центром сертификации (CA). Эти сертификаты легко изготовить и не стоят денег. Однако они не обеспечивают всех свойств безопасности, которые сертификаты, подписанные ЦС, стремятся обеспечить. Например, когда владелец веб-сайта использует самозаверяющий сертификат для предоставления услуг HTTPS , люди, посещающие этот веб-сайт, увидят предупреждение в своем браузере.

Кому решить эту проблему вы должны купить действующий сертификат от доверенного центра сертификации, или использовать Let's Encrypt , который даст сертификат, действительный в течение 90 дней, и по истечении этого периода вы можете продлить этот сертификат.

Если вы решите купить сертификат SSL, вы можете следовать описанному вами документу, чтобы создать секрет Kubernetes и использовать его при входе, просто вот так.

Но если вы не хотите покупать сертификат, вы можете установить cert-manager в своем кластере, это поможет вам сгенерировать действительные сертификаты с помощью Let's Encrypt.

Вот пример того, как использовать cert-manager + Let's Encrypt решение для генерации действительных SSL-сертификатов:

Использование cert-manager с Let's Encrypt

* 1 040 * cert-manager строится поверх Kubernetes, вводя центры сертификации и сертификаты в качестве первоклассных типов ресурсов в Kubernetes API. Это позволяет предоставлять «сертификаты как услугу» разработчикам, работающим в вашем кластере Kubernetes.

Let's Encrypt - это некоммерческий центр сертификации, управляемый Inte rnet Security Research Group который предоставляет сертификаты X.509 для шифрования Transport Layer Security бесплатно. Сертификат действителен в течение 90 дней, в течение которых продление может быть произведено в любое время. Я предполагаю, что у вас уже установлен и работает NGINX ingress.

Предварительные требования: - NGINX Ingress установлен и работает - HELM 3.0 установлен и работает

cert-manager install

Примечание : при работе на GKE (Google Kubernetes Engine), вы можете столкнуться с ошибкой «доступ запрещен» при создании некоторых из этих ресурсов. Это нюанс того, как GKE обрабатывает разрешения RBA C и IAM, и поэтому вы должны «повысить» свои собственные привилегии до уровня «cluster-admin» перед выполнением вышеуказанной команды. Если вы уже выполнили указанную выше команду, вам следует запустить их снова после повышения ваших разрешений:

Следуйте официальным документам для установки или просто используйте HELM 3.0 с следующей командой : 

$ kubectl create namespace cert-manager
$ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager-legacy.crds.yaml

Создать CLusterIssuer для Let's Encrypt: Сохраните содержимое ниже в новом файле с именем letsencrypt-production.yaml:

Примечание: Заменить <EMAIL-ADDRESS> с действующим адресом электронной почты. 

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  labels:
    name: letsencrypt-prod
  name: letsencrypt-prod
spec:
  acme:
    email: <EMAIL-ADDRESS>
    http01: {}
    privateKeySecretRef:
      name: letsencrypt-prod
    server: 'https://acme-v02.api.letsencrypt.org/directory'

Примените конфигурацию с помощью:

kubectl apply -f letsencrypt-production.yaml

Установите cert-manager с Let's Encrypt в качестве центра сертификации по умолчанию : 

helm install cert-manager \
--namespace cert-manager --version v0.8.1 jetstack/cert-manager \
--set ingressShim.defaultIssuerName=letsencrypt-prod \
--set ingressShim.defaultIssuerKind=ClusterIssuer
Проверьте установку: 
$ kubectl get pods --namespace cert-manager

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m

Используя cert-manager

Примените эту аннотацию к входящему SPE c: 

cert-manager.io/cluster-issuer: "letsencrypt-prod"

После применения сертификата -manager сгенерирует сертификат TLS для домена, настроенного в Host:, например: 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-app
  namespace: default
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  rules:
  - host: myapp.domain.com
    http:
      paths:
      - path: "/"
        backend:
          serviceName: my-app
          servicePort: 80
...