Симуляція дій

Ця задача показує, як налаштувати політику авторизації Istio, використовуючи нову експериментальну анотацію istio.io/dry-run для симуляції політики без фактичного її застосування.

Анотація dry-run дозволяє краще зрозуміти вплив політики авторизації перед її застосуванням до операційного трафіку. Це допомагає зменшити ризик порушення операційного трафіку, викликаного некоректною політикою авторизації.

Перед початком

Перед початком цієї задачі виконайте наступні кроки:

• Ознайомтесь з поняттями авторизації Istio.

• Дотримуйтесь інструкції з встановлення Istio для встановлення.

• Розгорніть Zipkin для перевірки результатів симуляції. Дотримуйтесь завдання Zipkin для встановлення Zipkin у кластер.

• Розгорніть Prometheus для перевірки результатів симуляції метрик. Дотримуйтесь завдання Prometheus для встановлення Prometheus у кластер.

• Розгорніть тестові робочі навантаження:

  Ця задача використовує два робочих навантаження, httpbin та curl, обидва розгорнуті в просторі імен foo. Обидва робочих навантаження працюють з sidecar проксі Envoy. Створіть простір імен foo і розгорніть робочі навантаження за допомогою наступної команди:

  ZipZip

  $ kubectl create ns foo
  $ kubectl label ns foo istio-injection=enabled
  $ kubectl apply -f @samples/httpbin/httpbin.yaml@ -n foo
  $ kubectl apply -f @samples/curl/curl.yaml@ -n foo

• Увімкніть рівень журналів налагодження проксі для перевірки результатів симуляції журналювання:

  $ istioctl proxy-config log deploy/httpbin.foo --level "rbac:debug" | grep rbac
  rbac: debug

• Перевірте, чи може curl отримати доступ до httpbin за допомогою наступної команди:

  $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
  200

Створення політики симуляції

1. Створіть політику авторизації з анотацією симуляції "istio.io/dry-run": "true" за допомогою наступної команди:

   $ kubectl apply -n foo -f - <<EOF
   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata:
     name: deny-path-headers
     annotations:
       "istio.io/dry-run": "true"
   spec:
     selector:
       matchLabels:
         app: httpbin
     action: DENY
     rules:
     - to:
       - operation:
           paths: ["/headers"]
   EOF

   Ви також можете використовувати наступну команду для швидкої зміни наявної політики авторизації в режим симуляції:

   $ kubectl annotate --overwrite authorizationpolicies deny-path-headers -n foo istio.io/dry-run='true'

2. Перевірте, що запити до шляху /headers дозволені, оскільки політика створена в режимі симуляції, запустіть наступну команду для надсилання 20 запитів від curl до httpbin, запит включає заголовок X-B3-Sampled: 1, щоб завжди активувати трасування Zipkin:

   $ for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/headers -H "X-B3-Sampled: 1" -s -o /dev/null -w "%{http_code}\n"; done
   200
   200
   200
   ...

Перевірка результатів симуляції в журналі проксі

Результати симуляції можна знайти в журналі налагодження проксі у форматі shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]. Запустіть наступну команду для перевірки журналу:

$ kubectl logs "$(kubectl -n foo -l app=httpbin get pods -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo | grep "shadow denied"
2021-11-19T20:20:48.733099Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
2021-11-19T20:21:45.502199Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
2021-11-19T20:22:33.065348Z debug envoy rbac shadow denied, matched policy ns[foo]-policy[deny-path-headers]-rule[0]
...

Також дивіться посібник з усунення неполадок для отримання додаткових відомостей про журналювання.

Перевірка результатів симуляції в метриках за допомогою Prometheus

1. Відкрийте дашборд Prometheus за допомогою наступної команди:

   $ istioctl dashboard prometheus

2. В Prometheus знайдіть наступну метрику:

   envoy_http_inbound_0_0_0_0_80_rbac{authz_dry_run_action="deny",authz_dry_run_result="denied"}

3. Перевірте результат запиту метрики наступним чином:

   envoy_http_inbound_0_0_0_0_80_rbac{app="httpbin",authz_dry_run_action="deny",authz_dry_run_result="denied",instance="10.44.1.11:15020",istio_io_rev="default",job="kubernetes-pods",kubernetes_namespace="foo",kubernetes_pod_name="httpbin-74fb669cc6-95qm8",pod_template_hash="74fb669cc6",security_istio_io_tlsMode="istio",service_istio_io_canonical_name="httpbin",service_istio_io_canonical_revision="v1",version="v1"}  20

4. Запитана метрика має значення 20 (можливо, ви знайдете інше значення залежно від кількості надісланих запитів. Це очікується, якщо значення більше за 0). Це означає, що політика симуляції застосована до робочого навантаження httpbin на порту 80 і відповідала одному запиту. Політика б відхилила запит, якби він не був у режимі симуляції.

5. Наступний знімок з екрана Prometheus:

   

Перевірка результатів симуляції в трасуванні за допомогою Zipkin

1. Відкрийте Zipkin за допомогою наступної команди:

   $ istioctl dashboard zipkin

2. Знайдіть результат трасування для запиту від curl до httpbin. Спробуйте надіслати ще кілька запитів, якщо ви не бачите результат трасування через затримку в Zipkin.

3. У результаті трасування ви повинні знайти наступні власні теґи, що вказують на те, що запит відхилено політикою симуляції deny-path-headers у просторі імен foo:

   istio.authorization.dry_run.deny_policy.name: ns[foo]-policy[deny-path-headers]-rule[0]
   istio.authorization.dry_run.deny_policy.result: denied

4. Наступний знімок з екрана Zipkin:

   

Підсумок

Журнал налагодження проксі, метрика Prometheus та результати трасування Zipkin вказують на те, що політика симуляції відхилить запит. Ви можете далі змінювати політику, якщо результат симуляції не відповідає очікуванням.

Рекомендується зберігати політику симуляції деякий додатковий час, щоб вона могла бути перевірена з більшим обсягом операційного трафіку.

Коли ви будете впевнені у результаті симуляції, ви можете вимкнути режим симуляції, щоб політика почала фактично відхиляти запити. Це можна зробити одним з наступних способів:

• Повністю видалити анотацію симуляції; або

• Змінити значення анотації симуляції на false.

Обмеження

Анотація симуляції наразі є експериментальною і має наступні обмеження:

• Анотація симуляції наразі підтримує лише політики ALLOW і DENY;

• Будуть два окремі результати симуляції (тобто журнал, метрика і теґ трасування) для політик ALLOW і DENY через те, що політики ALLOW і DENY виконуються окремо в проксі. Ви повинні враховувати обидва результати симуляції, оскільки запит може бути дозволений політикою ALLOW, але все ще відхилений іншою політикою DENY;

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

Очищення

1. Видаліть простір імен foo з вашої конфігурації:

   $ kubectl delete namespace foo

2. Видаліть Prometheus і Zipkin, якщо вони більше не потрібні.