Kiali¶

Objetivo¶

O Kiali é a interface operacional do service mesh. Ele fornece visualização de topologia, saúde dos serviços, relações entre workloads e validação de configuração do Istio.

Fonte de verdade no pipeline¶

Os arquivos principais são:

infrastructure/modules/istio/main.tf
infrastructure/modules/istio/templates/kiali-values.tpl
infrastructure/modules/istio/templates/eso-kiali.tpl
config/hml/istio/config.hcl
config/nox/istio/config.hcl

Como o Kiali é instalado¶

O módulo istio instala o chart kiali-server via Helm:

terraform resource "helm_release" "kiali" { name = "kiali" namespace = var.namespace repository = "https://kiali.org/helm-charts" chart = "kiali-server" version = var.kiali_chart_version }

O namespace usado pelos ambientes atuais é istio-system.

Dependências operacionais¶

O Kiali não é instalado isoladamente. O módulo declara dependência de:

Istio base
secret OIDC vindo de ExternalSecret
addon Prometheus

Na prática, isso significa que o Kiali espera já existir:

control plane do Istio
coleta de métricas compatível
segredo de autenticação resolvido

Como ele é exposto¶

O Kiali é uma exceção em relação às aplicações tenant-scoped.

Ele não usa o Gateway wildcard principal¶

No template atual, o chart é publicado por NGINX Ingress:

yaml deployment: ingress: enabled: true class_name: "nginx"

O override aplica:

cert-manager.io/cluster-issuer
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
external-dns.enabled: "true"

URL de acesso¶

O host é derivado do template:

yaml host: kiali.${ENV}.${DOMAIN}

Com a configuração atual do pipeline, isso resulta em:

HML: kiali.hml.nox.app.br
NOX: kiali.nox.nox.app.br

Esse é o padrão efetivamente gerado pelo template atual. Se a operação decidir usar outro host público, o ajuste precisa ser feito no pipeline ou na configuração derivada usada pelo módulo.

TLS¶

O próprio Ingress do Kiali solicita certificado com secret dedicado:

yaml tls: - hosts: - kiali.${ENV}.${DOMAIN} secretName: kiali.${ENV}.${DOMAIN}-tls

Ou seja, o Kiali não reaproveita o certificado wildcard do Gateway principal; ele pede seu próprio certificado para o host do Ingress.

Autenticação¶

Estratégia usada pelo chart¶

O template configura:

yaml auth: strategy: "openid" openid: client_id: "${OPENID_CLIENT_ID}" issuer_uri: "${OPENID_ISSUER_URI}" username_claim: "email" scopes: - "openid" - "email" - "profile" - "groups" password: "secret:kiali:oidc-secret"

O Kiali também opera em view_only_mode: true, o que reduz risco operacional na interface.

Onde ficam os detalhes vivos da autenticação¶

O módulo não hardcode GitHub diretamente. Ele lê a configuração OIDC de um secret externo, decodificado em locals.tf a partir de ESO_KIALI_CONFIG.

O ExternalSecret criado pelo módulo materializa o client secret assim:

yaml spec: target: name: kiali data: - secretKey: oidc-secret remoteRef: key: ESO_KIALI_CONFIG property: openid.client_secret

Na prática, os detalhes a revisar são:

openid.client_id
openid.issuer_uri
openid.client_secret
signing_key

Pelo código do módulo, o Kiali usa OpenID Connect genérico. Portanto:

se o issuer_uri configurado em ESO_KIALI_CONFIG apontar para um provedor federado com GitHub, o login seguirá por esse fluxo
se apontar para outro IdP, o login seguirá por esse outro provedor

Ou seja, a integração com GitHub não está hardcoded no módulo do Kiali; ela depende da configuração OIDC entregue pelo secret ESO_KIALI_CONFIG.

Onde configurar¶

Versões e domínio por ambiente¶

config/hml/istio/config.hcl
config/nox/istio/config.hcl

Campos relevantes:

kiali_chart_version
ingress_domain
domain

Credenciais e issuer OIDC¶

secret externo ESO_KIALI_CONFIG
ExternalSecret eso-kiali

Operação diária¶

O Kiali é mais útil para:

verificar topologia da malha
identificar chamadas com erro entre serviços
analisar latência entre workloads
validar configuração do Istio aplicada no cluster

Para o funcionamento do Gateway, wildcard DNS e target publicado no ExternalDNS, veja Istio & Gateway API.