Обеспечение определенного местоположения nginx-входа с проверкой сертификата клиента - PullRequest
Новая
       78

Обеспечение определенного местоположения nginx-входа с проверкой сертификата клиента

0 голосов
/ 23 октября 2018

Я настраиваю экземпляр ghost и пытаюсь защитить путь / ghost проверкой сертификата клиента.

У меня начальный вход и запуск, который довольно успешно обслуживает сайт по пути, указанному как /.

Я пытаюсь добавить второй вход (это в основном то же самое) для пути / ghost.Если я делаю это и добавляю аннотации для базовой аутентификации, кажется, все работает.То есть, если я перехожу к / ghost, меня просят ввести учетные данные в секрете basic-auth, если я перехожу на любой другой URL, он обслуживается без аутентификации.

Затем я переключился на проверку сертификата клиента на основе этого примера: https://github.com/kubernetes/ingress-nginx/tree/master/docs/examples/auth/client-certs

Когда я пытаюсь это сделать, либо весь сайт, либо ни один из сайтов не защищен, а не разделение по путиДобрался с basic-auth.Глядя на nginx.conf из запущенного модуля, элементы proxy_set_header ssl-client-verify, proxy_set_header ssl-client-subject-dn & proxy_set_header ssl-client-issuer-dn добавляются в корневой каталог / путь и / ghost путь.Я попытался удалить их (только из корня) и скопировать конфигурацию прямо обратно в модуль, но и не повезло.

Я вытащил nginx-ingress (версия Chart 0.23.0) какзависимость через Шлем

Определение входа для / местоположения - этот работает 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-staging
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
  labels:
    app: my-app
    chart: my-app-0.1.1
    heritage: Tiller
    release: my-app
  name: my-app
  namespace: default
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: my-app
          servicePort: http
        path: /
  tls:
  - hosts:
    - example.com
    secretName: mysite-tls

Определение входа для /ghost местоположения - этот не работает 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/auth-tls-chain"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.example.com/error-cert.html"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "false"
    kubernetes.io/ingress.class: "nginx"
  labels:
    app: my-app
    chart: my-app-0.1.1
    heritage: Tiller
    release: my-app
  name: my-app-secure
  namespace: default
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: my-app
          servicePort: http
        path: /ghost
  tls:
  - hosts:
    - example.com
    secretName: mysite-tls

1 Ответ

0 голосов
/ 25 октября 2018

Вам понадобится '*' на вашем пути на втором входе, если вы хотите безопасно обслуживать все страницы под /ghost, а если вы хотите просто /ghost, вам нужно другое правило.Примерно так: 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/auth-tls-chain"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.example.com/error-cert.html"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "false"
    kubernetes.io/ingress.class: "nginx"
  labels:
    app: my-app
    chart: my-app-0.1.1
    heritage: Tiller
    release: my-app
  name: my-app-secure
  namespace: default
spec:
  rules:
  - host: example.com
    http:
      paths:
      - backend:
          serviceName: my-app
          servicePort: http
        path: /ghost
      - backend:
          serviceName: my-app
          servicePort: http
        path: /ghost/*
  tls:
  - hosts:
    - example.com
    secretName: mysite-tls

Однако, если вы хотите что-то вроде / незащищенное и /ghost защищенное, я думаю, вы не сможете это сделать.Например, если вы используете nginx, это ограничение самого nginx, когда вы конфигурируете блок server {} с TLS в nginx, это выглядит примерно так: 

server {
    listen              443 ssl;
    server_name         example.com;
    ssl_certificate     example.com.crt;
    ssl_certificate_key example.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

Входной контроллер создает следующие пути: 

server {
    listen              443 ssl;
    server_name         example.com;
    ssl_certificate     example.com.crt;
    ssl_certificate_key example.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...

    location / {
       ...
    }

    location /ghost {
       ...
    }

}

Таким образом, когда вы настраиваете другой блок server {} с тем же именем хоста и без SSL, он будет переопределять первый.

Вы можете сделатьэто с другими - host: правилами в вашем входе, например ghost.example.com с TLS и main.example.com без TLS.Таким образом, в вашем nginx.conf у вас будут разные блоки server {}.

Вы всегда можете подключиться к модулю входного контроллера для проверки настроек, например: 

$ kubectl exec -it nginx-ingress-controller-xxxxxxxxx-xxxxx bash
www-data@nginx-ingress-controller-6bd7c597cb-8kzjh:/etc/nginx$ cat nginx.conf
...