Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Attivazione di funzionalità facoltative sul control plane gestito

Questa pagina descrive come attivare le funzionalità facoltative su Cloud Service Mesh gestito. Per informazioni sul control plane in-cluster, consulta Attivare le funzionalità facoltative sul control plane in-cluster.

Quando esegui il provisioning di Cloud Service Mesh gestito, le funzionalità supportate variano in base all'implementazione del control plane e alcune funzionalità sono disponibili solo tramite la lista consentita. Per maggiori dettagli, consulta le funzionalità supportate. Se oggi utilizzi una configurazione basata su IstioOperator, il

Immagine proxy senza distribuzione

Cluster di cui è stato eseguito l'onboarding diretto (cluster di cui è stato eseguito l'onboarding diretto al TRAFFIC_DIRECTOR control plane gestito): è supportato solo il tipo di immagine distroless. Non puoi modificarlo. L'immagine default non è supportata.
Cluster di cui è stata eseguita la migrazione (cluster di cui è stata eseguita la migrazione dal control plane ISTIOD a TRAFFIC_DIRECTOR): per impostazione predefinita, il tipo di immagine è l'immagine default (che contiene i file binari di debug). Puoi attivare esplicitamente le immagini distroless per migliorare la sicurezza.

Distroless è il tipo di immagine consigliato per una maggiore sicurezza. Come best practice, devi limitare i contenuti di un runtime container solo ai pacchetti necessari. Questo approccio migliora la sicurezza e il rapporto segnale/rumore degli scanner di vulnerabilità ed esposizioni comuni (CVE). Istio fornisce immagini proxy basate su immagini di base senza distribuzione.

L'immagine proxy senza distribuzione non contiene file binari diversi dal proxy. Pertanto, non è possibile eseguire exec di una shell o utilizzare curl, ping o altre utilità di debug all'interno del container. Tuttavia, puoi utilizzare i container temporanei per collegarti a un pod di workload in esecuzione per poterlo ispezionare ed eseguire comandi personalizzati. Ad esempio, consulta Raccogliere i log di Cloud Service Mesh.

La seguente configurazione attiva le immagini senza distribuzione per l'intero Cloud Service Mesh. Una modifica del tipo di immagine richiede il riavvio e la reiniezione di ogni pod per avere effetto.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

Puoi sostituire imageType utilizzando la seguente annotazione del pod. Tieni presente che per i cluster con il control plane TRAFFIC_DIRECTOR gestito, come valore di override esplicito è supportato solo distroless (non sono consentiti debug o altri tipi di immagini non senza distribuzione).

sidecar.istio.io/proxyImageType: distroless

Dopo aver modificato il tipo di immagine di un deployment utilizzando l'annotazione, il deployment deve essere riavviato. Per ripristinare l'immagine predefinita, rimuovi l'annotazione sidecar.istio.io/proxyImageType o il campo imageType da MeshConfig, quindi riavvia il deployment.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Poiché non richiede un'immagine di base di debug, la maggior parte dei tipi di debug proxy deve utilizzare gcloud beta container fleet mesh debug proxy-status / proxy-config (dettagli).

Policy del traffico in uscita

Per impostazione predefinita, outboundTrafficPolicy è impostato su ALLOW_ANY. In questa modalità, tutto il traffico verso qualsiasi servizio esterno è consentito. Per controllare e limitare il traffico solo ai servizi esterni per i quali sono definite le voci di servizio , puoi modificare il comportamento predefinito di ALLOW_ANY in REGISTRY_ONLY.

La seguente configurazione configura outboundTrafficPolicy su REGISTRY_ONLY:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY

dove release-channel è il tuo canale di rilascio (asm-managed, asm-managed-stable, o asm-managed-rapid).

Puoi apportare le modifiche di configurazione necessarie precedenti nel configmap utilizzando il seguente comando:
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

Esegui il comando seguente per visualizzare il configmap:

kubectl get configmap istio-release-channel -n istio-system -o yaml

Per verificare che outboundTrafficPolicy sia abilitato con REGISTRY_ONLY, assicurati che le seguenti righe vengano visualizzate nella sezione mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...
```

Autenticazione degli utenti finali

Puoi configurare l'autenticazione utente di Cloud Service Mesh gestito per eseguire l'autenticazione e il controllo dell'accesso degli utenti finali basati su browser ai workload di cui è stato eseguito il deployment. Per saperne di più, consulta Configurare l'autenticazione utente di Cloud Service Mesh.

Configurare la versione TLS minima per i workload

Se hai eseguito l'onboarding diretto a Cloud Service Mesh con un'implementazione del TRAFFIC_DIRECTOR control plane gestito, non puoi modificare questa impostazione.

Puoi utilizzare il campo minProtocolVersion per specificare la versione TLS minima per le connessioni TLS tra i workload. Per saperne di più su come impostare la versione TLS minima e controllare la configurazione TLS dei workload, consulta Configurazione della versione TLS minima del workload Istio.

L'esempio seguente mostra un ConfigMap che imposta la versione TLS minima per i workload su 1.3:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    meshMTLS:
      minProtocolVersion: TLSV1_3