Ambient та Kubernetes NetworkPolicy

Kubernetes NetworkPolicy дозволяє контролювати, як трафік рівня 4 досягає ваших podʼів.

NetworkPolicy зазвичай реалізується CNI, встановленою у вашому кластері. Istio не є CNI та не керує та не реалізує NetworkPolicy, а в усіх випадках дотримується його — ambient не обходить і ніколи не обходитиме виконання Kubernetes NetworkPolicy.

Одним із наслідків цього є те, що можливо створити Kubernetes NetworkPolicy, що заблокує трафік Istio або іншим чином завадить роботі Istio, тому під час спільного використання NetworkPolicy та ambient варто звернути увагу на кілька моментів.

Накладення трафіку Ambient та Kubernetes NetworkPolicy

Як тільки ви додали застосунки до ambient mesh, безпечне накладення L4 від ambient тунелюватиме трафік між вашими podʼами через порт 15008. Коли захищений трафік досягне цільового podʼа з портом призначення 15008, трафік буде проксійовано назад до початкового порту призначення.

Однак NetworkPolicy реалізується на хості, поза podʼом. Це означає, що якщо у вас є попередньо налаштований NetworkPolicy, який, наприклад, забороняє вхідний трафік до ambient podʼа на всіх портах, крім 443, вам потрібно додати виняток до цього NetworkPolicy для порту 15008. Робочим навантаженням sidecar, які отримують трафік, також потрібно дозволити вхідний трафік на порт 15008, щоб дозволити зовнішнім робочим навантаженням взаємодіяти з ними.

Наприклад, наступний NetworkPolicy блокуватиме вхідний трафік HBONE до my-app на порту 15008:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-app-allow-ingress-web
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: my-app
  ingress:
  - ports:
    - port: 8080
      protocol: TCP

і його слід змінити на

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-app-allow-ingress-web
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: my-app
  ingress:
  - ports:
    - port: 8080
      protocol: TCP
    - port: 15008
      protocol: TCP

якщо my-app доданий до ambient mesh.

Ambient, health probes та Kubernetes NetworkPolicy

Проби справності Kubernetes створюють проблему та створюють особливий випадок для політики трафіку Kubernetes загалом. Вони походять від kubelet, що працює як процес на вузлі, а не від якогось іншого podʼа в кластері. Вони є текстовими та незахищеними. Ні kubelet, ні вузол Kubernetes зазвичай не мають власної криптографічної ідентичності, тому контроль доступу неможливий. Недостатньо просто дозволити весь трафік через порт перевірки справності, оскільки шкідливий трафік може використовувати цей порт так само легко, як і kubelet. Крім того, багато застосунків використовують той самий порт для перевірки справності та для законного трафіку застосунку, тому прості дозволи на основі порту є неприйнятними.

Різні реалізації CNI розвʼязують цю проблему по-різному та намагаються або обійти проблему, тихо виключаючи проби справності kubelet з нормального виконання політики, або налаштовуючи для них виключення політики.

У Istio ambient ця проблема вирішується за допомогою комбінації правил iptables і перекладу мережних адрес джерела (SNAT) для переписування лише тих пакетів, які явно походять від локального вузла, на фіксовану локальну IP-адресу, щоб їх можна було явно ігнорувати правилами виконання політики Istio як незахищений трафік перевірки справності. Локальна IP-адреса була обрана типово, оскільки зазвичай їх ігнорують для контролю ingress-egress, і, за стандартом IETF, вони не маршрутизуються за межами локальної підмережі.

Ця поведінка прозоро вмикається, коли ви додаєте podʼи до ambient mesh, і стандартно ambient використовує локальні адреси 169.254.7.127 (IPv4) та fd16:9254:7127:1337:ffff:ffff:ffff:ffff (IPv6) для ідентифікації та правильного дозволу пакетів проб справності kubelet.

Примітка: якщо у вашому робочому навантаженні, просторі імен або кластері використовуються Kubernetes NetworkPolicy, ви маєте дозволити використання як адрес IPv4 так і IPv6 в режимі ambient. Залежно від того, який CNI ви використовуєте, пакети з цими адресами можуть бути заблоковані, що призведе до того, що перевірки справності podʼів вашого застосунку почнуть не виконуватися після додавання podʼів до ambient mesh.

Наприклад, застосування наступного NetworkPolicy в просторі імен заблокує весь трафік (Istio чи інший) до podʼа my-app, включаючи проби справності kubelet. Залежно від вашого CNI, проби kubelet і локальні адреси можуть бути проігноровані цією політикою або заблоковані нею:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ingress
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: my-app
  policyTypes:
  - Ingress

Після того, як pod буде зареєстровано в ambient mesh, пакети перевірки справності почнуть призначатися локальною адресою через SNAT, що означає, що проби справності можуть почати блокуватися вашим CNI при реалізації NetworkPolicy. Щоб дозволити пробам справності ambient обходити NetworkPolicy, явно дозвольте трафік від вузла до вашого podʼа, додавши до білого списку локальні адреси, які використовує ambient для цього трафіку:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ingress-allow-kubelet-healthprobes
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: my-app
  ingress:
    - from:
      - ipBlock:
          cidr: 169.254.7.127/32

Примітка: Якщо ви використовуєте кластер з подвійним стеком або кластер, що підтримує тільки IPv6, обовʼязково оновіть свою NetworkPolicy, додавши IPv6 ipBlock (fd16:9254:7127:1337:ffff:ffff:ffff:ffff/128) на додачу до запису IPv4 або замість нього.