Optionale Funktionen auf der verwalteten Steuerungsebene aktivieren

Mit verwaltetem Cloud Service Mesh können Sie optionale Mesh-Funktionen aktivieren, indem Sie ConfigMap-Ressourcen in Ihrem Cluster anpassen. Sie können die Sicherheit erhöhen, z. B. durch die Verwendung von Distroless-Proxy-Images, den eingeschränkten externen Ausgang mit Richtlinien für ausgehenden Traffic und die Anpassung der Trace-Stichprobenerhebung. Google übernimmt die Wartung und Upgrades der Steuerungsebene.

Die Verfügbarkeit der Funktionen variiert je nach Implementierung der Steuerungsebene und Release-Channel. Weitere Informationen finden Sie unter Mit Istio-APIs unterstützte Funktionen (verwaltete Steuerungsebene) und Optionale Funktionen auf einer Steuerungsebene im Cluster aktivieren.

Distroless-Proxy-Image

  • Direkt eingebundene Cluster (Cluster, die direkt in die verwaltete TRAFFIC_DIRECTOR-Steuerungsebene eingebunden wurden): Nur der distroless-Image-Typ wird unterstützt. Das können Sie nicht ändern. Das Bild default wird nicht unterstützt.

  • Migrierte Cluster (Cluster, die von der ISTIOD- zur TRAFFIC_DIRECTOR-Steuerungsebene migriert wurden): Der Standard-Image-Typ ist das default-Image (das Debug-Binärdateien enthält). Sie können distroless-Bilder explizit aktivieren, um die Sicherheit zu verbessern.

Distroless ist der empfohlene Bildtyp für verbesserte Sicherheit. Als Best Practice sollten Sie den Inhalt einer Containerlaufzeit auf die erforderlichen Pakete beschränken. Dieser Ansatz verbessert die Sicherheit und das Signal-Rausch-Verhältnis von CVE-Scannen (Common Vulnerabilities and Exposures). Istio stellt Proxy-Images bereit, die auf Distroless-Basis-Images basieren.

Das Distroless-Proxy-Image enthält keine anderen Binärdateien als den Proxy. Daher ist es nicht möglich, eine Shell mit exec zu versehen oder curl, ping oder andere Fehlerbehebungsfunktionen im Container zu verwenden. Sie können jedoch temporäre Container verwenden, um eine Verbindung zu einem laufenden Workload-Pod herzustellen, um ihn zu untersuchen und benutzerdefinierte Befehle auszuführen. Weitere Informationen finden Sie unter Cloud Service Mesh-Logs erfassen.

Die folgende Konfiguration aktiviert Distroless-Images für das gesamte Cloud Service Mesh. Bei einer Änderung des Image-Typs muss jeder Pod neu gestartet und neu eingefügt werden, um wirksam zu werden.

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

Sie können den imageType mit der folgenden Pod-Annotation überschreiben. Bei Clustern mit der verwalteten TRAFFIC_DIRECTOR-Steuerungsebene wird nur distroless als expliziter Überschreibungswert unterstützt. debug oder andere nicht distroless-basierte Bildtypen sind nicht zulässig.

sidecar.istio.io/proxyImageType: distroless

Nachdem Sie den Image-Typ einer Bereitstellung über die Annotation geändert haben, sollte die Bereitstellung neu gestartet werden. Wenn Sie zum Standardbild zurückkehren möchten, entfernen Sie die Annotation sidecar.istio.io/proxyImageType oder das Feld imageType aus Ihrem MeshConfig und starten Sie die Bereitstellung neu.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Da kein Debug-Basis-Image erforderlich ist, sollte für die meisten Arten von Proxy-Debugging gcloud beta container fleet mesh debug proxy-status / proxy-config verwendet werden (Details).

Richtlinie für ausgehenden Traffic

Standardmäßig ist outboundTrafficPolicy auf ALLOW_ANY festgelegt. In diesem Modus ist der gesamte Traffic zu externen Diensten zulässig. Wenn Sie den Traffic auf die externen Dienste beschränken möchten, für die Diensteinträge definiert sind, können Sie das Standardverhalten von ALLOW_ANY in REGISTRY_ONLY ändern.

  1. Mit der folgenden Konfiguration wird outboundTrafficPolicy auf REGISTRY_ONLY konfiguriert:

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

    Dabei ist release-channel Ihre Release-Version (asm-managed, asm-managed-stable oder asm-managed-rapid).

  2. Sie können die erforderlichen Konfigurationsänderungen in der ConfigMap mit dem folgenden Befehl vornehmen:

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

  3. Führen Sie den folgenden Befehl aus, um die ConfigMap aufzurufen:

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

  4. Prüfen Sie, ob die folgenden Zeilen im Abschnitt mesh: angezeigt werden, um sicher zu sein, dass outboundTrafficPolicy mit REGISTRY_ONLY aktiviert ist.

    ...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...

Endnutzerauthentifizierung

Sie können die verwaltete Cloud Service Mesh-Nutzerauthentifizierung für die browserbasierte Endnutzerauthentifizierung und Zugriffssteuerung für Ihre bereitgestellten Arbeitslasten konfigurieren. Weitere Informationen finden Sie unter Cloud Service Mesh-Nutzerauthentifizierung konfigurieren.

TLS-Mindestversion für Ihre Arbeitslasten konfigurieren

Wenn Sie direkt in Cloud Service Mesh mit einer verwalteten TRAFFIC_DIRECTOR Implementierung der Steuerungsebene eingearbeitet wurden, können Sie diese Einstellung nicht ändern.

Sie können das Feld minProtocolVersion verwenden, um die Mindest-TLS-Version für die TLS-Verbindungen Ihrer Arbeitslasten anzugeben. Weitere Informationen zum Festlegen der Mindest-TLS-Version und zum Prüfen der TLS-Konfiguration Ihrer Arbeitslasten finden Sie unter Konfiguration der Mindest-TLS-Version von Istio-Arbeitslasten.

Im folgenden Beispiel wird ConfigMap die TLS-Mindestversion für Arbeitslasten auf 1.3 festgelegt:

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