Attivazione di funzionalità facoltative sul control plane gestito

Cloud Service Mesh gestito ti consente di abilitare funzionalità mesh facoltative personalizzando le risorse ConfigMap nel cluster. Puoi configurare il rafforzamento della sicurezza, ad esempio immagini proxy distroless, limitare l'uscita esterna con policy di traffico in uscita e personalizzare il campionamento delle tracce, mentre Google gestisce la manutenzione e gli upgrade del control plane.

La disponibilità delle funzionalità varia in base all'implementazione del control plane e al canale di rilascio. Per saperne di più, consulta Funzionalità supportate che utilizzano le API Istio (control plane gestito) e Attivare le funzionalità facoltative su un control plane in-cluster.

Immagine proxy Distroless

  • Cluster di cui è stato eseguito l'onboarding diretto (cluster di cui è stato eseguito l'onboarding diretto al control plane TRAFFIC_DIRECTOR gestito): è supportato solo il tipo di immagine distroless. Non puoi modificare questa impostazione. L'immagine default non è supportata.

  • Cluster di cui è stata eseguita la migrazione (cluster di cui è stata eseguita la migrazione dal piano di controllo ISTIOD a TRAFFIC_DIRECTOR): il tipo di immagine è impostato per impostazione predefinita sull'immagine default (che contiene i binari di debug). Per migliorare la sicurezza, puoi attivare esplicitamente le immagini distroless.

Distroless è il tipo di immagine consigliato per una maggiore sicurezza. Come best practice, devi limitare i contenuti di un runtime del container ai soli 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 distroless.

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

La seguente configurazione abilita le immagini distroless per l'intero Cloud Service Mesh. Una modifica del tipo di immagine richiede il riavvio di ogni pod e la sua reiniezione per diventare effettiva.

     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, solo distroless è supportato come valore di override esplicito (debug o altri tipi di immagini non distroless non sono consentiti).

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 dal MeshConfig e 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 del 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 voci di servizio, puoi modificare il comportamento predefinito di ALLOW_ANY in REGISTRY_ONLY.

  1. 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).

  2. Puoi apportare le modifiche di configurazione necessarie in precedenza in configmap utilizzando il seguente comando:

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

  3. Esegui questo comando per visualizzare la configmap:

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

  4. 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 l'autenticazione e controllo dell'accesso dell'accesso degli utenti finali basati su browser ai workload di cui è stato eseguito il deployment. Per saperne di più, consulta Configurazione dell'autenticazione utente di Cloud Service Mesh.

Configura la versione TLS minima per i tuoi workload

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

Puoi utilizzare il campo minProtocolVersion per specificare la versione TLS minima per le connessioni TLS tra i tuoi workload. Per saperne di più sull'impostazione della versione TLS minima e sul controllo della configurazione TLS dei tuoi workload, consulta Configurazione della versione TLS minima del workload Istio.

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

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