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

Diese Seite wurde von der Cloud Translation API übersetzt.

Optionale Features in der verwalteten Steuerungsebene aktivieren

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

Wenn Sie ein verwaltetes Cloud Service Mesh bereitstellen, unterscheiden sich die unterstützten Features basierend auf der Implementierung der Steuerungsebene. Bestimmte Funktionen über die Zulassungsliste verfügbar. Weitere Informationen finden Sie unter Unterstützte Funktionen. Wenn Sie heute eine IstioOperator-basierte Konfiguration verwenden, kann das Tool zur Migration von IstioOperator bei der Konvertierung in eine Konfiguration hilfreich sein, die von der verwalteten Steuerungsebene unterstützt wird.

Proxy-Image löschen

Wenn Sie Cloud Service Mesh direkt mit einer verwalteten TRAFFIC_DIRECTORSteuerungsebene eingerichtet haben, wird nur der Imagetyp ohne Distribution unterstützt. Sie können ihn nicht ändern.
Wenn Ihre Flotte ursprünglich die Implementierung der ISTIOD-Steuerungsebene verwendet hat und zur TRAFFIC_DIRECTOR-Implementierung migriert wurde, wurde Ihr Image-Typ nicht geändert während der Migration und Sie können den Image-Typ so ändern, dass Sie sich selbst distrolos machen.

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, exec eine Shell zu verwenden oder curl, ping oder andere Debugging-Dienstprogrammen im Container. Sie können jedoch sitzungsspezifische Container verwenden, an einen laufenden Arbeitslast-Pod anhängen, um ihn zu prüfen . Weitere Informationen finden Sie beispielsweise unter Cloud Service Mesh-Protokolle erfassen.

Die folgende Konfiguration aktiviert Distributions-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 imageType mit der folgenden Pod-Anmerkung überschreiben.

sidecar.istio.io/proxyImageType: debug

Nachdem Sie den Image-Typ einer Bereitstellung mithilfe der Annotation geändert haben, sollte neu gestartet werden.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

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

Richtlinie für ausgehenden Traffic

Standardmäßig ist outboundTrafficPolicy auf ALLOW_ANY festgelegt. In diesem Modus werden alle zu jedem externen Dienst erlaubt ist. Wenn Sie den Traffic nur 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 outboundTrafficPolicy mit REGISTRY_ONLY aktiviert ist, indem Sie darauf achten, dass die folgenden Zeilen im Abschnitt mesh: angezeigt werden.
```
...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...
```

Endnutzerauthentifizierung

Sie können die Nutzerauthentifizierung für das verwaltete Cloud Service Mesh konfigurieren für browserbasierte Endnutzer-Authentifizierung und Zugriffssteuerung für Ihr bereitgestelltes Arbeitsbelastungen. Weitere Informationen finden Sie unter Cloud Service Mesh-Nutzerauthentifizierung konfigurieren.

TLS-Mindestversion für Ihre Arbeitslasten konfigurieren

Wenn Sie Cloud Service Mesh direkt mit einer verwalteten TRAFFIC_DIRECTORSteuerungsebene eingerichtet haben, 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 eine ConfigMap-Datei gezeigt, in der die TLS-Mindestversion für Arbeitslasten auf 1.3 festgelegt ist:

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