Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Abilita funzionalità facoltative sul piano di controllo gestito

In questa pagina viene descritto come abilitare le funzionalità facoltative sui dispositivi Cloud Service Mesh. Per informazioni sul piano di controllo nel cluster, consulta Abilitazione di funzionalità facoltative sul piano di controllo nel cluster.

Quando esegui il provisioning di Cloud Service Mesh gestito, le funzionalità supportate sono diverse basate sull'implementazione del piano di controllo, e alcune disponibili tramite la lista consentita. Consulta funzionalità supportate per maggiori dettagli. Se oggi utilizzi una configurazione basata su IstioOperator, il valore La migrazione dallo strumento IstioOperator può aiutarti alla configurazione supportata dal piano di controllo gestito.

Immagine proxy senza distro

Se hai eseguito l'onboarding direttamente in Cloud Service Mesh con un TRAFFIC_DIRECTOR gestito l'implementazione del piano di controllo, solo il tipo di immagine senza distroless è supportato. Non puoi modificarlo.
Se inizialmente il parco risorse utilizzava l'implementazione del piano di controllo ISTIOD ed era è stata eseguita la migrazione all'implementazione TRAFFIC_DIRECTOR, il tipo di immagine è rimasto invariato durante la migrazione e puoi cambiare il tipo di immagine in distroless autonomamente.

Come best practice, dovresti limitare i contenuti del runtime di un container a solo i pacchetti necessari. Questo approccio migliora la sicurezza rapporto segnale-rumore degli scanner di vulnerabilità ed esposizioni comuni (CVE). Istio fornisce immagini proxy basate su immagini di base senza distroless.

L'immagine proxy senza distroless non contiene file binari diversi dal proxy. Di conseguenza non è possibile exec una shell o utilizzare curl, ping o un altro tipo di debug all'interno del container. ma puoi usare container temporanei da collegare a un pod del carico di lavoro in esecuzione per ispezionarlo ed eseguire tramite comandi SQL. Ad esempio, vedi Raccolta dei log di Cloud Service Mesh.

La seguente configurazione abilita le immagini senza distrografia per l'intero Cloud Service Mesh. Una modifica al tipo di immagine richiede il riavvio di ogni pod e il reinserimento per avere effetto.

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

Puoi eseguire l'override di imageType utilizzando la seguente annotazione pod.

sidecar.istio.io/proxyImageType: debug

Dopo aver modificato il tipo di immagine di un deployment utilizzando l'annotazione, e il deployment dell'app.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Poiché non è necessaria un'immagine di base di debug, la maggior parte dei tipi di debug del proxy dovrebbe usare gcloud beta container fleet mesh debug proxy-status / proxy-config (dettagli).

Criterio del traffico in uscita

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

La seguente configurazione configura outboundTrafficPolicy in 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 precedenti modifiche alla configurazione necessarie nella configmap utilizzando seguente comando:
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

Esegui questo comando per visualizzare il file configmap:

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

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

Autenticazione degli utenti finali

Puoi configurare l'autenticazione utente gestita di Cloud Service Mesh per l'autenticazione degli utenti finali e il controllo dell'accesso basati su browser carichi di lavoro con scale out impegnativi. Per ulteriori informazioni, vedi Configurare l'autenticazione utente di Cloud Service Mesh.

Configura la versione TLS minima per i carichi di lavoro

Se hai eseguito l'onboarding direttamente in Cloud Service Mesh con un TRAFFIC_DIRECTOR gestito l'implementazione del piano di controllo, non potrai modificare questa impostazione.

Puoi utilizzare il campo minProtocolVersion per specificare la versione TLS minima per le connessioni TLS tra i carichi di lavoro. Per ulteriori informazioni sull'impostazione la versione TLS minima e controllare la configurazione TLS dei carichi di lavoro, consulta Configurazione della versione TLS minima del carico di lavoro Istio.

L'esempio seguente mostra un'impostazione ConfigMap che imposta la versione TLS minima per carichi di lavoro con la versione 1.3:

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