Точки доступу для налагодження
Istiod надає точки доступу для налагодження (наприклад, /debug/syncz, /debug/registryz, /debug/config_dump) на кількох портах, які надають інформацію про моніторинг і статус, корисну для інтеграцій.
Порти та протоколи
- Порт 15010: точки доступу налагодження XDS через незашифрований gRPC (
syncz,config_dump) - Порт 15012: точки доступу налагодження XDS через TLS/mTLS gRPC (
syncz,config_dump) — рекомендовано для промислового використання - Порт 15014: HTTP точки доступу налагодження (незашифровані)
Вимоги до автентифікації
Точки доступу налагодження вимагають автентифікації за допомогою токенів службових облікових записів Kubernetes або дійсних облікових даних JWT. Токен повинен мати аудиторію istio-ca (налаштовується через змінну середовища TOKEN_AUDIENCES на istiod).
Порт 15010 (незашифрований gRPC): Коли ENABLE_DEBUG_ENDPOINT_AUTH=true, точки доступу налагодження вимагають автентифікації. Оскільки цей порт незашифрований (без TLS), перевірка автентифікації фактично блокує доступ, якщо її не вимкнути. Натомість використовуйте порт 15012 для автентифікованого доступу до налагодження XDS.
Порт 15012 (TLS gRPC): точки доступу налагодження XDS доступні через захищений TLS-порт. Автентифікація виконується автоматично через перевірку mTLS-сертифікатів.
Порт 15014 (HTTP): Автентифікація через токен на предʼявника у заголовку Authorization або обхід через localhost.
Автентифікація контролюється змінною ENABLE_DEBUG_ENDPOINT_AUTH (увімкнена за замовчуванням). Щоб повністю вимкнути автентифікацію та відновити застарілу поведінку з незашифрованим доступом, встановіть ENABLE_DEBUG_ENDPOINT_AUTH=false на istiod. Зауважте, що вимкнення автентифікації може розкрити чутливу інформацію про кластер.
Контроль доступу на основі просторів імен
Коли автентифікацію увімкнено:
- Службові облікові записи з системного простору імен (зазвичай
istio-system) мають повний доступ до всіх точок доступу для налагодження для всіх проксі в усіх просторах імен. - Службові облікові записи з несистемних просторів імен обмежені:
- Лише певними точками доступу:
/debug/config_dump,/debug/ndsz,/debug/edsz - Лише проксі з того самого простору імен (не можна переглядати проксі з інших просторів імен)
- Лише певними точками доступу:
- Щоб надати додатковим просторам імен такий самий повний доступ, як системному простору імен, встановіть змінну середовища
DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACESна istiod у вигляді списку просторів імен, розділених комами.
Способи доступу
Через localhost (рекомендовано):
Переадресація портів до istiod обходить автентифікацію, оскільки запити надходять з localhost. Саме так працює istioctl, і це рекомендований підхід для більшості інтеграцій:
$ kubectl port-forward -n istio-system deploy/istiod 15014:15014
$ curl http://localhost:15014/debug/synczПрямий мережевий доступ (для інструментів у кластері):
Для інструментів, що працюють усередині кластера (наприклад, Kiali, власний моніторинг), які звертаються до istiod безпосередньо через сервісну мережу Kubernetes, токен службового облікового запису повинен:
- Мати аудиторію
istio-ca(стандартно) - Походити з авторизованого простору імен (
istio-systemабо вказаного вDEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES) - Бути включеним як bearer-токен у заголовок Authorization
$ TOKEN=$(kubectl create token my-sa --audience istio-ca -n my-namespace)
$ curl -H "Authorization: Bearer $TOKEN" https://istiod.istio-system:15014/debug/synczПриклад: налаштування доступу до простору імен
Щоб дозволити інструменту моніторингу, що працює в просторі імен monitoring, доступ до точок доступу для налагодження, додайте цей простір імен до конфігурації istiod:
apiVersion: apps/v1
kind: Deployment
metadata:
name: istiod
namespace: istio-system
spec:
template:
spec:
containers:
- name: discovery
env:
- name: DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES
value: "monitoring,kiali-operator"Після застосування цієї зміни службові облікові записи з просторів імен monitoring та kiali-operator матимуть такий самий рівень доступу, як службові облікові записи istio-system.