Optionale Features in verwaltetem Anthos Service Mesh aktivieren

Auf dieser Seite wird beschrieben, wie Sie optionale Features auf einer verwalteten Anthos Service Mesh-Steuerungsebene aktivieren. Informationen zur clusterinternen Steuerungsebene finden Sie unter Optionale Features auf der clusterinternen Steuerungsebene aktivieren.

Wenn Sie verwaltetes Anthos Service Mesh bereitstellen, unterscheiden sich die standardmäßig aktivierten Features je nach Plattform. Wenn Sie derzeit eine IstioOperator-basierte Konfiguration verwenden, können Sie das Tool Migrate from IstioOperator in die Konfiguration umwandeln, die von der verwalteten Steuerungsebene unterstützt wird.

Envoy-Zugriffslogs

Führen Sie die folgenden Befehle aus, um das Envoy-Zugriffs-Logging zu aktivieren:

  1. Führen Sie den folgenden Befehl aus, um accessLogFile: /dev/stdout hinzuzufügen:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      mesh: |-
        accessLogFile: /dev/stdout
    kind: ConfigMap
    metadata:
      name: istio-release-channel
      namespace: istio-system
    EOF
    

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

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

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. Prüfen Sie, ob das Zugriffs-Logging aktiviert ist. Achten Sie dabei darauf, dass im Abschnitt mesh: die Zeile accessLogFile: /dev/stdout angezeigt wird.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        accessLogFile: /dev/stdout
    ...
    

Cloud Tracing aktivieren

Führen Sie folgende Befehle aus, um Cloud Trace zu aktivieren:

  1. Führen Sie dazu diesen Befehl aus:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      mesh: |-
        defaultConfig:
          tracing:
            stackdriver: {}
    kind: ConfigMap
    metadata:
      name: istio-release-channel
      namespace: istio-system
    EOF
    

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

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

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. Achten Sie darauf, dass im Abschnitt mesh: die folgenden Zeilen angezeigt werden, um zu prüfen, ob Cloud Trace aktiviert ist.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        defaultConfig:
          tracing:
            stackdriver:{}
    ...
    
  4. Starten Sie die Proxys neu.

    Beachten Sie, dass die Tracer-Konfiguration derzeit Teil der Proxy-Bootstrap-Konfiguration ist. Daher muss jeder Pod neu gestartet und neu eingefügt werden, um die Tracer-Aktualisierung zu übernehmen. Mit dem folgenden Befehl können Sie beispielsweise Pods neu starten, die zu einem Deployment gehören:

    kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Weitere Informationen zu unterstützten Trace-Headern finden Sie unter Auf Traces zugreifen.

Proxy-Image löschen

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.

Die folgende Konfiguration aktiviert Distributions-Images für das gesamte Anthos 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

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. Wenn Sie für eine bestimmte Bereitstellung Zugriff auf diese Tools benötigen, können Sie 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

Für die meisten Arten von Proxy-Debugging sollte istioctl proxy-cmd verwendet werden, für das kein Debug-Basis-Image erforderlich ist.

Richtlinie für ausgehenden Traffic

Standardmäßig ist outboundTrafficPolicy auf ALLOW_ANY festgelegt. In diesem Modus ist der gesamte Traffic zu einem beliebigen externen Dienst zulässig. 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.

  1. Mit der folgenden Konfiguration wird outboundTrafficPolicy als 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. Mit dem Befehl unten können Sie die erforderlichen Konfigurationsänderungen in der configmap 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. Achten Sie darauf, dass im Abschnitt mesh: die folgenden Zeilen angezeigt werden, um zu prüfen, ob outboundTrafficPolicy mit REGISTRY_ONLY aktiviert ist.

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

Endnutzerauthentifizierung

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

TLS-Mindestversion für Ihre Arbeitslasten konfigurieren

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 TLS-Mindestversion und zum Prüfen der TLS-Konfiguration Ihrer Arbeitslasten finden Sie unter Konfiguration der minimalen TLS-Version von Istio-Arbeitslasten.

Das folgende Beispiel zeigt einen ConfigMap, mit dem die TLS-Mindestversion für Arbeitslasten auf 1.3 festgelegt wird:

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