Transportsicherheit konfigurieren

In Anthos Service Mesh 1.5 und höher ist die automatische gegenseitige TLS-Authentifizierung (automatisches mTLS) standardmäßig aktiviert. Bei automatischem mTLS 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 Nur-Text-Traffic. Dienste akzeptieren sowohl Nur-Text- als auch mTLS-Traffic. Wenn Sie Sidecar-Proxys in Ihre Pods einfügen, empfehlen wir Ihnen, Ihre Dienste auch so zu konfigurieren, dass nur mTLS-Traffic akzeptiert wird.

Gegenseitiges mTLS

Mit Anthos Service Mesh können Sie mTLS außerhalb Ihres Anwendungscodes durch Anwenden einer einzelnen YAML-Datei erzwingen. Anthos Service Mesh bietet Ihnen die Flexibilität, eine Authentifizierungsrichtlinie auf das gesamte Service Mesh, auf einen Namespace oder auf eine einzelne Arbeitslast anzuwenden.

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

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. Die Spezifikation der Richtlinie entspricht der Richtlinie für eine Mesh-weite Richtlinie, aber Sie geben den Namespace an, für den sie 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. Anthos 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

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