Compare languages | Модуль ingress-nginx: FAQ

Как разрешить доступ к приложению внутри кластера только от ingress controller’ов?

How do I limit access to the application in the cluster to ingress controllers only?

Если вы хотите ограничить доступ к вашему приложению внутри кластера ТОЛЬКО от подов ingress’а, необходимо в под с приложением добавить контейнер с kube-rbac-proxy:

Add the kube-rbac-proxy container to the application Pod to allow only ingress Pods to access your application in the cluster:

Пример Deployment для защищенного приложения

An example of the corresponding Kubernetes Deployment

yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: my-namespace spec: selector: matchLabels: app: my-app replicas: 1 template: metadata: labels: app: my-app spec: serviceAccountName: my-sa containers:

  • name: my-cool-app image: mycompany/my-app:v0.5.3 args:
  • ”–listen=127.0.0.1:8080” livenessProbe: httpGet: path: /healthz port: 443 scheme: HTTPS
  • name: kube-rbac-proxy image: flant/kube-rbac-proxy:v0.1.0 # Рекомендуется использовать прокси из нашего репозитория. args:
  • ”–secure-listen-address=0.0.0.0:443”
  • ”–config-file=/etc/kube-rbac-proxy/config-file.yaml”
  • ”–v=2”
  • ”–logtostderr=true” Если kube-apiserver недоступен, мы не сможем аутентифицировать и авторизовывать пользователей. Stale Cache хранит только результаты успешной авторизации и используется, только если apiserver недоступен.
  • ”–stale-cache-interval=1h30m” ports:
  • containerPort: 443 name: https volumeMounts:
  • name: kube-rbac-proxy mountPath: /etc/kube-rbac-proxy volumes:
  • name: kube-rbac-proxy configMap: name: kube-rbac-proxy

yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: my-namespace spec: selector: matchLabels: app: my-app replicas: 1 template: metadata: labels: app: my-app spec: serviceAccountName: my-sa containers:

  • name: my-cool-app image: mycompany/my-app:v0.5.3 args:
  • ”–listen=127.0.0.1:8080” livenessProbe: httpGet: path: /healthz port: 443 scheme: HTTPS
  • name: kube-rbac-proxy image: flant/kube-rbac-proxy:v0.1.0 # it is recommended to use a proxy from our repository args:
  • ”–secure-listen-address=0.0.0.0:443”
  • ”–config-file=/etc/kube-rbac-proxy/config-file.yaml”
  • ”–v=2”
  • ”–logtostderr=true” The user authentication and authorization are not possible if the kube-apiserver is not available. Stale Cache stores the results of successful authorization and is used only if the apiserver is not available.
  • ”–stale-cache-interval=1h30m” ports:
  • containerPort: 443 name: https volumeMounts:
  • name: kube-rbac-proxy mountPath: /etc/kube-rbac-proxy volumes:
  • name: kube-rbac-proxy configMap: name: kube-rbac-proxy

Приложение принимает запросы на адресе 127.0.0.1, это означает, что по незащищенному соединению к нему можно подключиться только изнутри пода. Прокси же слушает на адресе 0.0.0.0 и перехватывает весь внешний трафик к поду.

The application only accepts localhost (127.0.0.1) requests. That means that an unsecured connection can only be established to it from within the Pod. At the same time, the proxy listens on 0.0.0.0 and intercepts all external traffic to the Pod.

Как дать минимальные права для Service Account?

How do I provide minimum rights to the Service Account?

Чтобы аутентифицировать и авторизовывать пользователей с помощью kube-apiserver, у прокси должны быть права на создание TokenReview и SubjectAccessReview.

The proxy needs permissions to create TokenReview and SubjectAccessReview to authenticate and authorize users using the kube-apiserver.

В наших кластерах уже есть готовая ClusterRoled8-rbac-proxy. Создавать ее самостоятельно не нужно! Нужно только прикрепить ее к Service Account’у вашего Deployment’а.

Our clusters have a built-in ClusterRole called d8-rbac-proxy that is ideal for this kind of situation. You don’t need to create it yourself! Just attach it to the ServiceAccount of your Deployment.

yaml

apiVersion: v1 kind: ServiceAccount metadata: name: my-sa namespace: my-namespace — apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: my-namespace:my-sa:d8-rbac-proxy roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: d8:rbac-proxy subjects:

  • kind: ServiceAccount name: my-sa namespace: my-namespace

yaml

apiVersion: v1 kind: ServiceAccount metadata: name: my-sa namespace: my-namespace — apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: my-namespace:my-sa:d8-rbac-proxy roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: d8:rbac-proxy subjects:

  • kind: ServiceAccount name: my-sa namespace: my-namespace

Конфигурация Kube-RBAC-Proxy

The Kube-RBAC-Proxy configuration

yaml apiVersion: v1 kind: ConfigMap metadata: name: kube-rbac-proxy data: config-file.yaml: |+ excludePaths:

  • /healthz # Не требуем авторизацию для liveness пробы. upstreams:
  • upstream: http://127.0.0.1:8081/ # Куда проксируем. path: / # Location прокси, с которого запросы будут проксированы на upstream. authorization: resourceAttributes: namespace: my-namespace apiGroup: apps apiVersion: v1 resource: deployments subresource: http name: my-app

yaml apiVersion: v1 kind: ConfigMap metadata: name: kube-rbac-proxy data: config-file.yaml: |+ excludePaths:

  • /healthz # no authorization for liveness probes is required upstreams:
  • upstream: http://127.0.0.1:8081/ # the destination address path: / # the path to the proxy to forward requests to the upstream authorization: resourceAttributes: namespace: my-namespace apiGroup: apps apiVersion: v1 resource: deployments subresource: http name: my-app

Согласно конфигурации, у пользователя должны быть права на доступ к Deployment с именем my-app и его дополнительному ресурсу http в namespace my-namespace.

According to the configuration, the user must have access to the my-app Deployment and its http subresource in the my-namespace namespace.

Выглядят такие права в виде RBAC так:

Such permissions have the following RBAC form:

yaml

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kube-rbac-proxy:my-app namespace: my-namespace rules:

  • apiGroups: [“apps”] resources: [“deployments/http”] resourceNames: [“my-app”] verbs: [“get”, “create”, “update”, “patch”, “delete”] — apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kube-rbac-proxy:my-app namespace: my-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: kube-rbac-proxy:my-app subjects:

yaml

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: kube-rbac-proxy:my-app namespace: my-namespace rules:

  • apiGroups: [“apps”] resources: [“deployments/http”] resourceNames: [“my-app”] verbs: [“get”, “create”, “update”, “patch”, “delete”] — apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: kube-rbac-proxy:my-app namespace: my-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: kube-rbac-proxy:my-app subjects:

Все пользовательские сертификаты ingress-контроллеров выписаны для одной конкретной группы.

  • kind: Group name: ingress-nginx:auth

All user certificates of ingress-controllers are issued for one specific group

  • kind: Group name: ingress-nginx:auth

Для ingress’а ресурса необходимо добавить параметры:

You also need to add the following parameters to the ingress of the resource:

yaml nginx.ingress.kubernetes.io/backend-protocol: HTTPS nginx.ingress.kubernetes.io/configuration-snippet: | proxy_ssl_certificate /etc/nginx/ssl/client.crt; proxy_ssl_certificate_key /etc/nginx/ssl/client.key; proxy_ssl_protocols TLSv1.2; proxy_ssl_session_reuse on;

yaml nginx.ingress.kubernetes.io/backend-protocol: HTTPS nginx.ingress.kubernetes.io/configuration-snippet: | proxy_ssl_certificate /etc/nginx/ssl/client.crt; proxy_ssl_certificate_key /etc/nginx/ssl/client.key; proxy_ssl_protocols TLSv1.2; proxy_ssl_session_reuse on;

Подробнее о том, как работает аутентификация по сертификатам, можно прочитать в документации Kubernetes.

Here you can read more about how certificate authentication works.

Как сконфигурировать балансировщик нагрузки для проверки доступности IngressNginxController?

How do I configure an external load balancer to check if IngressNginxController is available?

В ситуации, когда IngressNginxController размещен за балансировщиком нагрузки, рекомендуется сконфигурировать балансировщик для проверки доступности узлов IngressNginxController с помощью HTTP-запросов или TCP-подключений. В то время как тестирование с помощью TCP-подключений представляет собой простой и универсальный механизм проверки доступности, мы рекомендуем использовать проверку на основе HTTP-запросов со следующими параметрами:

  • протокол: HTTP;
  • путь: /healthz;
  • порт: 80 (в случае использования inlet’а HostPort нужно указать номер порта, соответствующий параметру httpPort.

In case an IngressNginxController is deployed behind a load balancer, it is advisable to configure your load balancer so that it would check the availability of the IngressNginxController’s endpoints via a health check mechanism, periodically sending either HTTP-requests or TCP-packets. While it is possible to test the endpoints simply by checking if a relevant TCP port is open, we recommend implementing HTTP checks with the following parameters:

  • Protocol: HTTP
  • Path: /healthz
  • Port: 80 (or relevant httpPort value in case of using HostPort inlet).

Как настроить работу через MetalLB с доступом только из внутренней сети?

How do I configure MetalLB to be accessible from the internal network only?

Пример MetalLB с доступом только из внутренней сети.

Below is an example of a MetalLB config with access from the internal network only.

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: “nginx” inlet: “LoadBalancer” loadBalancer: sourceRanges:

  • 192.168.0.0/24

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: “nginx” inlet: “LoadBalancer” loadBalancer: sourceRanges:

  • 192.168.0.0/24

Как добавить дополнительные поля для логирования в nginx-controller?

How to add extra log fields to a nginx-controller?

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: “nginx” inlet: “LoadBalancer” additionalLogFields: my-cookie: “$cookie_MY_COOKIE”

yaml apiVersion: deckhouse.io/v1 kind: IngressNginxController metadata: name: main spec: ingressClass: “nginx” inlet: “LoadBalancer” additionalLogFields: my-cookie: “$cookie_MY_COOKIE”

Как включить HorizontalPodAutoscaling для IngressNginxController?

How to enable HorizontalPodAutoscaling for IngressNginxController?

Важно! Режим HPA возможен только для контроллеров с inlet’ом LoadBalancer или LoadBalancerWithProxyProtocol. Важно! Режим HPA возможен только при minReplicas != maxReplicas, в противном случае deployment hpa-scaler не создается.

Note! HPA mode is possible only for controllers with inlet: LoadBalancer or LoadBalancerWithProxyProtocol. Note! HPA mode is possible only for minReplicas != maxReplicas otherwise deployment hpa-scaler will not be created.

HPA выставляется с помощью аттрибутов minReplicas и maxReplicas в IngressNginxController CR.

HPA is set with attributes minReplicas and maxReplicas in a IngressNginxController CR.

IngressNginxController разверачивается с помощью DaemonSet. DaemonSet не предоставляет возможности горизонтального масштабирования, поэтому создается дополнительный deployment hpa-scaler и HPA resource, который следит за предварительно созданной метрикой prometheus-metrics-adapter-d8-ingress-nginx-cpu-utilization-for-hpa. Если CPU utilization превысит 50%, HPA закажет новую реплику для hpa-scaler (с учетом minReplicas и maxReplicas).

The IngressNginxController is deployed using Daemonset. Daemonset does not provide horizontal scaling capabilities, so hpa-scaler Deployment will be created with the HPA resource, which is observing custom metric prometheus-metrics-adapter-d8-ingress-nginx-cpu-utilization-for-hpa. If CPU utilization exceeds 50%, the HPA-controller scales hpa-scaler Deployment with a new replica (with respect to minReplicas and maxReplicas).

hpa-scaler deployment обладает HardPodAntiAffinity, поэтому он попытается заказать себе новый узел (если это возможно в рамках своей NodeGroup), куда автоматически будет размещен еще один Ingress-контроллер.

hpa-scaler Deployment has HardPodAntiAffinity, and it will order a new Node (inside its NodeGroup), where one more ingress-controller will be set.

Примечания:

  • Минимальное реальное количество реплик IngressNginxController не может быть меньше минимального количества узлов в NodeGroup, в которую разворачивается IngressNginxController.
  • Максимальное реальное количество реплик IngressNginxController не может быть больше максимального количества узлов в NodeGroup, в которую разворачивается IngressNginxController.

Notes:

  • The minimum actual number of ingressNginxController replicas cannot be less than the minimum number of nodes in the NodeGroup where ingressNginxController is deployed.
  • The maximum actual number of ingressNginxController replicas cannot be greater than the maximum number of nodes in the NodeGroup where ingressNginxController is deployed.

Как использовать IngressClass с установленными IngressClassParameters?

How to use IngressClass with IngressClassParameters?

Начиная с версии 1.1 IngressNginxController, Deckhouse создает объект IngressClass самостоятельно. Если вы хотите использовать свой IngressClass, например с установленными IngressClassParameters, достаточно добавить к нему label ingress-class.deckhouse.io/external: "true"

Since version 1.1 IngressNginxController Deckhouse creates an IngressClass object. If you want to use your own IngressClass with your customized IngressClassParameters, you need to add the label ingress-class.deckhouse.io/external: "true"

yaml apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: labels: ingress-class.deckhouse.io/external: “true” name: my-super-ingress spec: controller: ingress-nginx.deckhouse.io/my-super-ingress parameters: apiGroup: elbv2.k8s.aws kind: IngressClassParams name: awesome-class-cfg

yaml apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: labels: ingress-class.deckhouse.io/external: “true” name: my-super-ingress spec: controller: ingress-nginx.deckhouse.io/my-super-ingress parameters: apiGroup: elbv2.k8s.aws kind: IngressClassParams name: awesome-class-cfg

В таком случае, при указании данного IngressClass в CRD IngressNginxController, Deckhouse не будет создавать объект, а использует уже существующий.

In this case Deckhouse will not create an IngressClass object and will use your own.

Как отключить сборку детализированной статистики Ingress-ресурсов?

How to disable the collection of detailed Ingress resources statistics?

По умолчанию Deckhouse собирает подробную статистику со всех Ingress-ресурсов в кластере, что может генерировать высокую нагрузку на систему мониторинга.

By default, Deckhouse collects detailed statistics from all Ingress resources in the cluster. This behavior may generate high load on the monitoring system.

Для отключения сбора статистики добавьте label ingress.deckhouse.io/discard-metrics: "true" к соответствующему namespace или Ingress-ресурсу.

To disable statistics collection, add label ingress.deckhouse.io/discard-metrics: "true" to the corresponding Namespace or Ingress resource.

Пример отключения сбора статистики (метрик) для всех Ingress-ресурсов в пространстве имен review-1:

Example of disabling statistics (metrics) collection for all Ingress resources in the review-1 namespace:

shell kubectl label ns review-1 ingress.deckhouse.io/discard-metrics=true

shell kubectl label ns review-1 ingress.deckhouse.io/discard-metrics=true

Пример отключения сбора статистики (метрик) для всех Ingress-ресурсов test-site в пространстве имен development:

Example of disabling statistics (metrics) collection for all test-site Ingress resources in the development namespace:

shell kubectl label ingress test-site -n development ingress.deckhouse.io/discard-metrics=true

shell kubectl label ingress test-site -n development ingress.deckhouse.io/discard-metrics=true