Transportsicherheit konfigurieren

In Cloud Service Mesh mit Istio-APIs für Kubernetes-Arbeitslasten ist automatisches Mutual TLS (automTLS) standardmäßig aktiviert. Bei automTLS erkennt ein Client-Sidecar-Proxy automatisch, ob der Server einen Sidecar hat. Der Client-Sidecar-Proxy sendet an Arbeitslasten mit Sidecars mTLS und an Arbeitslasten ohne Sidecars Klartext-Traffic. Dienste akzeptieren jedoch sowohl Klartext- als auch mTLS-Traffic. Wenn Sie Sidecar-Proxys in Ihre Pods einfügen, empfehlen wir, Ihre Dienste so zu konfigurieren, dass sie nur mTLS-Traffic akzeptieren.

Mit Cloud Service Mesh können Sie Ihre Dienste so konfigurieren, dass sie mTLS nur durch Anwenden einer PeerAuthentication-Richtlinie akzeptieren. Cloud Service Mesh bietet Ihnen die Flexibilität, eine Authentifizierungsrichtlinie auf das gesamte Service Mesh, auf einen Namespace oder auf eine einzelne Arbeitslast anzuwenden. Wenn Sie eine Richtlinie für eine bestimmte Arbeitslast angeben, hat diese Richtlinie Vorrang. Beispielsweise hat eine arbeitslastspezifische Richtlinie Vorrang vor einer Namespace-spezifischen Richtlinie. Wenn für die Arbeitslast keine Richtlinie angegeben ist, wird die Richtlinie aus dem Namespace oder dem Mesh-Netzwerk übernommen.

Unter Unterstützte Features finden Sie Informationen dazu, welche Felder des der benutzerdefinierten Ressource PeerAuthentication von der Plattform unterstützt werden.

Gegenseitiges TLS pro Namespace aktivieren

Wenn Sie mTLS für alle Arbeitslasten in einem bestimmten Namespace aktivieren möchten, verwenden Sie eine Namespace-weite Authentifizierungsrichtlinie. Sie geben den Namespace an, für den es gilt (unter metadata).

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "NAMESPACE"
spec:
  mtls:
    mode: STRICT
EOF

Erwartete Ausgabe: 

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

Gegenseitiges TLS pro Arbeitslast aktivieren

Zum Festlegen einer PeerAuthentication-Richtlinie für eine bestimmte Arbeitslast müssen Sie den Abschnitt selector konfigurieren und die Labels angeben, die der gewünschten Arbeitslast entsprechen. Cloud Service Mesh kann jedoch keine Richtlinien für Arbeitslast für ausgehenden mTLS-Traffic zu einem Dienst zusammenfassen. Sie müssen eine Zielregel konfigurieren, um dieses Verhalten zu verwalten.

  1. Authentifizierungsrichtlinie auf eine bestimmte Arbeitslast in Ihrem Namespace anwenden:

    cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "NAMESPACE"
spec:
  selector:
    matchLabels:
      app: WORKLOAD
  mtls:
    mode: STRICT
EOF

    Erwartete Ausgabe:

    peerauthentication.security.istio.io/AUTH_POLICY_NAME created

  2. Konfigurieren Sie eine übereinstimmende Zielregel:

    cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "DEST_RULE_NAME"
spec:
  host: "WORKLOAD.NAMESPACE.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

    Erwartete Ausgabe:

    destinationrule.networking.istio.io/WORKLOAD created

Mesh-weites mTLS erzwingen

Wenn Sie verhindern möchten, dass alle Dienste im Mesh-Netzwerk Traffic in Form von Klartext akzeptieren, legen Sie ein Mesh-weite PeerAuthentication-Richtlinie, bei der der mTLS-Modus auf STRICT festgelegt ist. Die Standardeinstellung ist PERMISSIVE). Die Mesh-weite PeerAuthentication-Richtlinie sollte keinen Selektor haben und muss im Stamm-Namespace angewendet werden, istio-system. Wenn Sie die Richtlinie bereitstellen, stellt die Steuerungsebene automatisch TLS-Zertifikate bereit, sodass Arbeitslasten sich authentifizieren können.

So erzwingen Sie das Mesh-weite mTLS:

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

Erwartete Ausgabe: 

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

mTLS für Managed CSM deaktivieren

Cloud Service Mesh unterstützt den Wert mtls.mode: DISABLE in einer PeerAuthentication-Ressource nicht.

Damit mTLS in Cloud Service Mesh deaktiviert werden kann, müssen Sie das Verhalten des Clients in Bezug auf die Anforderungen des Servers explizit mit der DestinationRule API definieren.

Konzeptübersicht

  1. Serverseitig: Sie verwenden eine PeerAuthentication-Ressource, um den serverseitigen Proxy-Standardwert festzulegen.
  2. Clientseitiger Ansatz: Sie verwenden eine DestinationRule-Ressource, um den clientseitigen Proxys explizit mitzuteilen, dass sie bei der Kommunikation mit diesem bestimmten Server Nur-Text verwenden sollen.

Beispiele

Schritt 1: PeerAuthentication konfigurieren

In diesem Beispiel verwenden wir die Standardrichtlinie PERMISSIVE und müssen die Richtlinie daher nicht explizit definieren.

Schritt 2: Clientseitige DestinationRule konfigurieren

Diese Konfiguration weist Clients an, Klartext zu verwenden, wenn sie httpbin aufrufen.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: "DEST_RULE_NAME"
  namespace: sample-namespace
spec:
  host: "WORKLOAD.NAMESPACE.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: DISABLE

PeerAuthentication-Richtlinien suchen und löschen

Eine Liste aller PeerAuthentication-Richtlinien im Service Mesh:

kubectl get peerauthentication --all-namespaces

Wenn eine PeerAuthentication-Richtlinie in Kraft ist, können Sie diese mit kubectl delete löschen:

kubectl delete peerauthentication -n NAMESPACE AUTH_POLICY_NAME

Nächste Schritte