Segurança do Istio
O que é Segurança do Istio?
Segurança do IstioConjunto de funcionalidades de segurança do Istio: identidade de workload via SPIFFE, mTLS automático e AuthorizationPolicy/RequestAuthentication para controlo de acesso fino.
A Segurança do Istio é o subsistema de segurança do service mesh Istio. O control plane (istiod) emite identidades X.509 baseadas em SPIFFE para cada workload e configura os sidecars Envoy para estabelecer mTLS entre pods, eliminando tráfego este-oeste em claro. As políticas PeerAuthentication aplicam mTLS STRICT ou PERMISSIVE ao nível de namespace ou workload. AuthorizationPolicy fornece regras allow/deny sobre identidades de origem, hosts, caminhos, métodos e condições; RequestAuthentication valida JWTs contra emissores. Os riscos operacionais incluem PERMISSIVE mal configurado que permite tráfego em claro, políticas demasiado amplas e CVEs do istiod sem patch (como CVE-2024-3727). A boa prática combina mTLS STRICT, AuthorizationPolicy default-deny e auditoria de alterações.
● Exemplos
- 01
PeerAuthentication mtls.mode=STRICT no namespace prod para exigir mTLS em todos os pods.
- 02
AuthorizationPolicy default-deny que permite reviews-service chamar ratings-service.
● Perguntas frequentes
O que é Segurança do Istio?
Conjunto de funcionalidades de segurança do Istio: identidade de workload via SPIFFE, mTLS automático e AuthorizationPolicy/RequestAuthentication para controlo de acesso fino. Pertence à categoria Segurança em nuvem da cibersegurança.
O que significa Segurança do Istio?
Conjunto de funcionalidades de segurança do Istio: identidade de workload via SPIFFE, mTLS automático e AuthorizationPolicy/RequestAuthentication para controlo de acesso fino.
Como funciona Segurança do Istio?
A Segurança do Istio é o subsistema de segurança do service mesh Istio. O control plane (istiod) emite identidades X.509 baseadas em SPIFFE para cada workload e configura os sidecars Envoy para estabelecer mTLS entre pods, eliminando tráfego este-oeste em claro. As políticas PeerAuthentication aplicam mTLS STRICT ou PERMISSIVE ao nível de namespace ou workload. AuthorizationPolicy fornece regras allow/deny sobre identidades de origem, hosts, caminhos, métodos e condições; RequestAuthentication valida JWTs contra emissores. Os riscos operacionais incluem PERMISSIVE mal configurado que permite tráfego em claro, políticas demasiado amplas e CVEs do istiod sem patch (como CVE-2024-3727). A boa prática combina mTLS STRICT, AuthorizationPolicy default-deny e auditoria de alterações.
Como se defender contra Segurança do Istio?
As defesas contra Segurança do Istio costumam combinar controles técnicos e práticas operacionais, conforme detalhado na definição acima.
Quais são outros nomes para Segurança do Istio?
Nomes alternativos comuns: mTLS do Istio, AuthorizationPolicy do Istio.
● Termos relacionados
- cloud-security№ 1014
Segurança de Service Mesh
Conjunto de controlos de identidade, cifragem e autorização que um service mesh fornece para proteger tráfego serviço-a-serviço em ambientes cloud-native.
- cloud-security№ 1078
SPIFFE
Padrão aberto para atribuir identidades criptográficas portáveis a workloads usando SPIFFE IDs baseados em URI e SVIDs X.509 ou JWT de curta duração.
- cloud-security№ 1248
Identidade de Workload
Identidade criptográfica atribuída a um serviço, contentor ou função para se autenticar perante outros sistemas sem segredos partilhados de longa duração.
- network-security№ 1262
Rede Zero Trust
Arquitetura de rede que nunca confia em utilizadores, dispositivos ou serviços por defeito e exige verificação contínua baseada em identidade para cada ligação.
- cloud-security№ 600
Segurança do Kubernetes
Proteção de um cluster Kubernetes — API server, plano de controlo, nós, workloads e rede — contra configurações incorretas, comprometimento e movimentação lateral.
● Veja também
- № 1079Runtime SPIRE