Optionale Features 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 Features je nach Implementierung der Steuerungsebene. Bestimmte Features sind nur über eine Zulassungsliste verfügbar. Weitere Informationen finden Sie unter Unterstützte Features. Wenn Sie derzeit eine IstioOperator-basierte Konfiguration verwenden, ist

Proxy-Image löschen

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

  • Migrierte Cluster (Cluster, die von der ISTIOD- zur TRAFFIC_DIRECTOR-Steuerungsebene migriert wurden): Der Image-Typ ist standardmäßig das default-Image (das Debug-Binärdateien enthält). Sie können sich explizit für distroless-Images entscheiden, um die Sicherheit zu verbessern.

`distroless` ist der empfohlene Image-Typ für mehr 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 kurzlebige Container verwenden, um sie an einen ausgeführten Arbeitslast-Pod anzuhängen, damit Sie ihn untersuchen und benutzerdefinierte Befehle ausführen können. 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 imageType mit der folgenden Pod-Annotation überschreiben. Beachten Sie, dass für Cluster mit der verwalteten TRAFFIC_DIRECTOR-Steuerungsebene nur distroless als expliziter Überschreibungswert unterstützt wird (debug oder andere Nicht-Distroless-Image-Typen 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 Standard-Image zurückkehren möchten, entfernen Sie die Annotation sidecar.istio.io/proxyImageType oder das Feld imageType aus Ihrer 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 verwendet werden gcloud beta container fleet mesh debug proxy-status / proxy-config (Details).

Richtlinie für ausgehenden Traffic

Standardmäßig ist outboundTrafficPolicy auf ALLOW_ANY festgelegt. In diesem Modus ist der gesamte Traffic zu jedem externen Dienst 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. Die folgende Konfiguration legt outboundTrafficPolicy auf REGISTRY_ONLY fest:

    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 outboundTrafficPolicy mit REGISTRY_ONLY aktiviert ist. Dazu müssen die folgenden Zeilen im Abschnitt mesh: angezeigt werden.

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

Endnutzerauthentifizierung

Sie können die Nutzerauthentifizierung für verwaltetes Cloud Service Mesh 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 Steuerungsebene eingebunden 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 in einer ConfigMap die Mindest-TLS-Version 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