Нет запроса на сертификат клиента при развертывании сервера nginx на k8s с сервисом балансировки нагрузки - PullRequest
Новая
       21

Нет запроса на сертификат клиента при развертывании сервера nginx на k8s с сервисом балансировки нагрузки

0 голосов
/ 06 февраля 2019

Мой серверный веб-сервер применяет сертификат на стороне клиента.Это прекрасно работало, пока я не перенес свое развертывание в кластер Kubernetes.Я предполагаю, что правила пересылки не передают запрос сертификата с сервера в браузер.

Я использую контейнер uwsgi-nginx-flask-docker .

Моя конфигурация Nginx выглядит следующим образом: 

server {
    listen 8000 ssl;
    location / {
        try_files $uri @app;
    }
    location @app {
        include uwsgi_params; uwsgi_param SSL_CLIENT_S_DN $ssl_client_s_dn;

        uwsgi_pass unix:///tmp/uwsgi.sock;
        uwsgi_read_timeout 300;

        ssl_certificate     /app/cert.pem;
        ssl_certificate_key /app/key.pem;
        ssl_password_file   /app/password.pass;

        ssl_client_certificate  /app/client-ca.crt;
        ssl_verify_client off;
        ssl_verify_depth 2;
    }
    location /static {
        alias /app/static;
    }
}

При развертывании этого сервера в локальном контейнере я получаю SSL_CLIENT_S_DN в flask.request.environ, как и ожидалось.

На моемКластер Kubernetes, переменная просто пуста, и в браузере не запрашивается никаких сертификатов.

Мой сервис и развертывание: 

apiVersion: v1
kind: Service
metadata:
  name: my-server
spec:
  selector:
    app: my-server
  type: LoadBalancer
  loadBalancerIP: XX.XX.XXX.XXX
  ports:

  - protocol: TCP
    port: 8000
    targetPort: 8000

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-server
  labels:
    app: my-server
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: my-server
  template:
    metadata:
      labels:
        app: my-server
    spec:
      restartPolicy: Always
      hostname: my-server
      containers:

      - name: my-server
        image: asia.gcr.io/my-project/my-server:latest
        imagePullPolicy: Always
        ports:
        - name: LISTEN_PORT
          value: "8000 ssl"

Ответы [ 2 ]

0 голосов
/ 07 марта 2019

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

0 голосов
/ 07 февраля 2019

Kubernetes поддерживает множественные средства аутентификации , а именно: X509 , Файл статических токенов , Bootstrap Tokens , Статический парольФайл , Токены учетной записи службы и Токены OpenID Connect .

Здесь - это ссылка на сообщение в блоге ФредерикаBranczyk , который объясняет, как настроить клиентские сертификаты X509.

Он создает ClusterRole с правами только для чтения для всех модулей и пространств имен: 

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: read-only-user
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - namespaces
  verbs:
  - get
  - list
  - watch

Затем предоставляет пользователю этиразрешения в ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: read-only-users
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: read-only-user
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: brancz

Выше ClusterRoleBinding дает пользователю с именем «brancz» роли, указанные в ClusterRole и называются «только для чтения»

Вы также можете взглянуть на скрипт автоматизации, который он использует для генерации клиентских сертификатов, подписывает их с помощью CA кластера и генерирует kubeconfig.

Надеюсь, это поможет вам.

...