Azure Kubernetes Nginx -Возможность авторизации сертификата клиента - PullRequest
0 голосов
/ 26 апреля 2020

Я боролся с этим все выходные, и теперь я на коленях, надеясь, что один из вас, гениев, может решить мою проблему. nginx / nginx -ingress: 1.5.8), с которым я пытаюсь добиться самоподписанной взаимной аутентификации.

Аспект https работает нормально, но проблема у меня возникла (я думаю, ), входной контроллер перенаправляет запрос с сертификатом по умолчанию, а вход проверяет с помощью CA по умолчанию (потому что он не может найти мой CA).

Итак .. Помогите!

Шаги, которые я прошел в этом кластере-f *** путешествия (каламбур):

Я проверял это в местном Minikube-кластере, и все это работает как очарование. Когда я выполнил c - это во входном модуле контроллера и увидел nginx .conf для обоих моих кластеров (Minikube и Azure), я обнаружил большие различия; следовательно, я только что узнал, что я работаю с яблоками и грушами с точки зрения мини-кубов - azure -k8s nginx -адрес кластер (вход, который я использую, является более или менее дубликатом файла, который вы найдете в ссылке): https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/

Кроме того, я нашел это, что в длинном Способ описывает проблему, которая у меня возникла: https://success.docker.com/article/how-to-configure-a-default-tls-certificate-for-the-kubernetes-nginx-ingress-controller Из приведенной выше ссылки решение простое; уберите вход с орбиты и создайте новый. Ну, вот в чем дело, это производственный кластер, и мои боссы были бы очень довольны, если бы я сделал это.

Еще одно открытие, которое я сделал, пока "exe c -it bash" - роуминг Внутри Azure -ingress-controller не находится общедоступная папка c root cert (/ etc / ssl /), которую можно найти. Не знаю почему, но хотя я бы упомянул об этом.

Я также обнаружил параметр --default-ssl-certificate = default / foo-tls, но это значение по умолчанию. Поскольку в дальнейшем потребуются другие потребности для разных аутентификаций клиентов, я должен иметь возможность задавать динамические c CA-сертификаты для разных входов.

Я пропущу свой nginx .conf, который я считаю проблема ниже. Надеюсь получить ответ от некоторых из вас, потому что на данный момент я полностью потерян. Ударь меня, если нужна дополнительная информация.

user  nginx;
worker_processes  auto;
daemon off;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';


    access_log  /var/log/nginx/access.log  main;


    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout 65s;
    keepalive_requests 100;

    #gzip  on;

    server_names_hash_max_size 512;


    variables_hash_bucket_size 256;
    variables_hash_max_size 1024;

    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }





    server {
        listen 80 default_server;
        listen 443 ssl default_server;

        ssl_certificate /etc/nginx/secrets/default;
        ssl_certificate_key /etc/nginx/secrets/default;

        server_name _;
        server_tokens "on";
        access_log off;



        location / {
           return 404;
        }
    }
    # stub_status
    server {
        listen 8080;

        allow 127.0.0.1;
        deny all;
        location /stub_status {
            stub_status;
        }
    }
    server {
        listen unix:/var/run/nginx-status.sock;
        access_log off;

        location /stub_status {
            stub_status;
        }
    }

    include /etc/nginx/config-version.conf;
    include /etc/nginx/conf.d/*.conf;

    server {
        listen unix:/var/run/nginx-502-server.sock;
        access_log off;

        location / {
            return 502;
        }
    }
}

stream {
    log_format  stream-main  '$remote_addr [$time_local] '
                      '$protocol $status $bytes_sent $bytes_received '
                      '$session_time';

    access_log  /var/log/nginx/stream-access.log  stream-main;

1 Ответ

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

Таким образом, проблема сводилась к тому, что входной контроллер был старым и устаревшим. У меня не было оригинальной таблицы рулевого управления, на которой он был развернут, поэтому я, естественно, беспокоился о вариантах отката. Anyhoo -> совершил прыжок веры среди ночи по местному времени и уничтожил пространство имен; воссоздал пространство имен; helm install stable / nginx -ingress.

Было минимальное время простоя - не более 1 минуты, но будьте осторожны, чтобы заблокировать IP-адрес publi c, подключенный к балансировщику нагрузки, прежде чем переходить на все 3. Первая мировая война за ваши сервисы.

Пришлось добавить аргумент в стандартную команду azure helm install для обязательной установки общедоступного c IP для ресурса; вставьте его ниже, если какая-то бедная душа окажется в неудачной ситуации с новым шлемом и потерянными картами.

Вот и все; обновляйте свои услуги и сохраняйте свои графики!

helm install nginx stable/nginx-ingress --namespace ingress-basic \
                                           --set controller.replicaCount=2 \
                                           --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \
                                           --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux \
                                           --set controller.service.loadBalancerIP=*YourVeryPreciousPublicIP*
...