Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Optionale Funktionen auf der verwalteten Steuerungsebene aktivieren

Auf dieser Seite wird beschrieben, wie Sie optionale Features in verwaltetem Cloud Service Mesh aktivieren. Informationen zur Steuerungsebene im Cluster finden Sie unter Optionale Features auf der Steuerungsebene im Cluster aktivieren.

Wenn Sie verwaltetes Cloud Service Mesh bereitstellen, unterscheiden sich die unterstützten Funktionen je nach Implementierung der Steuerungsebene. Bestimmte Funktionen sind nur über eine Zulassungsliste verfügbar. Weitere Informationen finden Sie unter Unterstützte Funktionen. Wenn Sie heute eine IstioOperator-basierte Konfiguration verwenden, kann das Tool zur

Distroless-Proxy-Image

Wenn Sie direkt in Cloud Service Mesh mit einer verwalteten TRAFFIC_DIRECTOR Implementierung der Steuerungsebene eingearbeitet wurden, wird nur der Distroless-Bildtyp unterstützt. Sie kann nicht geändert werden.
Wenn in Ihrer Flotte ursprünglich die ISTIOD-Steuerungsebene verwendet wurde und sie zur TRAFFIC_DIRECTOR-Implementierung migriert wurde, wurde der Image-Typ während der Migration nicht geändert. Sie können den Image-Typ selbst in „distroless“ ändern.

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 sitzungsspezifische 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.

sidecar.istio.io/proxyImageType: debug

Nachdem Sie den Image-Typ einer Bereitstellung über die Annotation geändert haben, sollte die Bereitstellung neu gestartet werden.

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.

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

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
```

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

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

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 die TLS-Mindestversion für Arbeitslasten auf 1.3 festgelegt:ConfigMap

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