Übersicht über Autorisierungsrichtlinien
Im Gegensatz zu einer monolithischen Anwendung, die an einem Ort ausgeführt werden kann, senden global verteilte Mikrodienstanwendungen Aufrufe über Netzwerkgrenzen hinweg. Dies bedeutet mehr Einstiegspunkte in Ihre Anwendungen und mehr Möglichkeiten für böswillige Angriffe. Da Kubernetes-Pods temporäre IP-Adressen haben, sind herkömmliche IP-basierte Firewallregeln nicht für den sicheren Zugriff zwischen Arbeitslasten geeignet. In einer Mikrodienstarchitektur ist ein neuer Sicherheitsansatz erforderlich. Aufbauend auf Sicherheitsfunktionen wie Kubernetes-Dienstkonten und Istio-Sicherheitsrichtlinien, Cloud Service Mesh bietet noch mehr Funktionen, mit denen Sie Ihre Anwendungen.
Auf dieser Seite erhalten Anwendungsoperatoren eine Übersicht über die benutzerdefinierte Ressource AuthorizationPolicy
(CR). Mit Autorisierungsrichtlinien können Sie die Zugriffssteuerung für Arbeitslasten auf den Anwendungs- (L7) und Transport-Ebenen (L3/4) aktivieren. Sie konfigurieren Autorisierungsrichtlinien, um Berechtigungen festzulegen. Was darf dieser Dienst oder Nutzer tun?
Autorisierungsrichtlinien
Anfragen zwischen Diensten in Ihrem Mesh (und zwischen Endnutzern und Diensten) sind standardmäßig zulässig. Mit der AuthorizationPolicy
-CR definieren Sie detaillierte Richtlinien für Ihre Arbeitslasten. Nachdem Sie die Autorisierungsrichtlinien angewendet haben,
Cloud Service Mesh verteilt sie an die Sidecar-Proxys. Wenn Anfragen bei einer Arbeitslast eintreffen, prüft der Sidecar-Proxy die Autorisierungsrichtlinien, um festzustellen, ob die Anfrage zugelassen oder abgelehnt werden soll.
Richtlinienbereich
Eine Richtlinie kann auf das gesamte Service Mesh, auf einen Namespace oder auf eine einzelne Arbeitslast angewendet werden.
Geben Sie den Stamm-Namespace
istio-system
im Feldmetadata:namespace
an, um eine Mesh-netzwerkweite Richtlinie anzuwenden:apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "mesh-wide" namespace: istio-system spec: ...
Geben Sie den Namespace im Feld
metadata:namespace
an, um eine Richtlinie auf einen Namespace anzuwenden:apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "currencyservice" namespace: currencyservice spec: ...
Wenn Sie eine Richtlinie auf eine bestimmte Arbeitslast beschränken möchten, fügen Sie das Feld
selector
ein.apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "frontend" namespace: demo spec: selector: matchLabels: app: frontend ...
Grundstruktur
Eine Autorisierungsrichtlinie enthält den Richtlinienbereich, einen action
und eine Liste von rules
:
Wie im vorherigen Abschnitt beschrieben, kann der Richtlinienbereich das gesamte Mesh-Netzwerk, ein Namespace oder eine bestimmte Arbeitslast sein. Wenn Sie ihn angeben, gibt das Feld
selector
das Ziel der Richtlinie an.Das Feld
action
gibt an, ob die Anfrage den StatusALLOW
oderDENY
hat. Wenn Sie keine Aktion angeben, wird die Aktion standardmäßig aufALLOW
gesetzt. Aus Gründen der Übersichtlichkeit empfehlen wir, immer die Aktion anzugeben. (Autorisierung unterstützen die Richtlinien auchAUDIT
undCUSTOM
actions.)Die
rules
geben an, wann die Aktion ausgelöst werden soll.Das Feld
from
in derrules
gibt die Quellen der Anfrage.Das Feld
to
in derrules
gibt die Betrieb der Anfrage.Im Feld
when
werden zusätzliche Bedingungen um die Regel anzuwenden.
Im folgenden Beispiel gilt:
Die Richtlinie wird auf Anfragen an den Dienst
frontend
im Namespacedemo
angewendet.Anfragen werden zugelassen, wenn sich „hello:world“ im Anfrage-Header befindet. Andernfalls werden Anfragen abgelehnt.
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "hello-world"
namespace: demo
spec:
selector:
matchLabels:
app: frontend
action: ALLOW
rules:
- when:
- key: request.headers[hello]
values: ["world"]
Zugriffssteuerung für Anfragevorgang
Sie können den Zugriff auf bestimmte Anfragen steuern.
Betrieb
wie HTTP-Methoden oder TCP-Ports, indem Sie unter rules
einen to
-Abschnitt hinzufügen.
Im folgenden Beispiel sind nur die HTTP-Methoden GET
und POST
für currencyservice
im Namespace demo
zulässig.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: currencyservice
namespace: demo
spec:
selector:
matchLabels:
app: currencyservice
action: ALLOW
rules:
- to:
- operation:
methods: ["GET", "POST"]
Zugriffssteuerung für authentifizierte Identität
In den vorherigen Beispielen lassen die Richtlinien Anfragen von nicht authentifizierten Arbeitslasten zu. Wenn Sie
Gegenseitige TLS-Authentifizierung (STRICT
) (mTLS) aktiviert,
Sie können den Zugriff anhand der Identität der Arbeitslast oder des Namespace einschränken,
die Anfrage aus dem
source
.
Verwenden Sie das Feld
principals
odernotPrincipal
, um den Zugriff auf Arbeitslastebene zu steuern.Verwenden Sie das Feld
namespaces
odernotNamespaces
, um den Zugriff auf Namespcae-Ebene zu steuern.
Für alle obigen Felder muss STRICT
mTLS aktiviert sein. Wenn Sie STRICT
mTLS nicht festlegen können, finden Sie unter Klartextanfragen ablehnen eine alternative Lösung.
Identifizierte Arbeitslast
Im folgenden Beispiel sind Anfragen an currencyservice
nur vom Dienst frontend
zulässig. Anfragen an currencyservice
von anderen Arbeitslasten werden abgelehnt.
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "currencyservice"
namespace: demo
spec:
selector:
matchLabels:
app: currencyservice
action: ALLOW
rules:
- from:
- source:
principals: ["example-project-1234.svc.id.goog/ns/demo/sa/frontend-sa"]
Zum Angeben eines Dienstkontos wird die principals
für
Zertifizierungsstelle von Cloud Service Mesh (Mesh CA)
und Certificate Authority Service
(CA-Dienst) muss das folgende Format haben:
principals: ["PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT_NAME"]
PROJECT_ID.svc.id.goog
ist die Vertrauensdomain für Mesh CA. Wenn Sie die Istio-Zertifizierungsstelle (ehemals Citadel) verwenden, lautet die Standardvertrauensdomain cluster.local
.
Identifizierter Namespace
Das folgende Beispiel zeigt eine Richtlinie, die Anfragen ablehnt, wenn die Quelle nicht der Namespace foo
ist:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin-deny
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
version: v1
action: DENY
rules:
- from:
- source:
notNamespaces: ["foo"]
Werteabgleich
Die meisten Felder in Autorisierungsrichtlinien unterstützen alle folgenden Abgleichschemen:
- Exakte Übereinstimmung: Exakte Übereinstimmung des Strings.
- Platzhalterübereinstimmung mit dem Platzhalterzeichen
"*"
:- Präfixübereinstimmung: Ein String mit der abschließenden Zeichenfolge
"*"
. Beispielsweise führt"test.example.*"
zu Übereinstimmungen mit"test.example.com"
oder"test.example.com.cn"
. - Suffix-Übereinstimmung: Ein String mit einer anfänglichen Zeichenfolge
"*"
. Beispielsweise führt"*.example.com"
zu Übereinstimmungen mit"eng.example.com"
oder"test.eng.example.com"
.
- Präfixübereinstimmung: Ein String mit der abschließenden Zeichenfolge
- Präsenzübereinstimmung: Verwenden Sie das Format
fieldname: ["*"]
, um anzugeben, dass ein Feld vorhanden sein muss und nicht leer sein darf. Dies unterscheidet sich davon, ein Feld unspezifiziert zu lassen, was bedeutet, dass es mit allem übereinstimmt, einschließlich „leer“.
Es gibt jedoch einige Ausnahmen. Die folgenden Felder unterstützen beispielsweise nur die genaue Übereinstimmung:
- Das Feld
key
im Abschnittwhen
- Das Feld
ipBlocks
im Abschnittsource
- Das Feld
ports
im Abschnittto
Die folgende Beispielrichtlinie lässt den Zugriff auf Pfade mit dem Präfix /test/*
oder dem Suffix */info
zu:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: tester
namespace: default
spec:
selector:
matchLabels:
app: products
action: ALLOW
rules:
- to:
- operation:
paths: ["/test/*", "*/info"]
Ausschlussabgleich
Um negative Bedingungen wie notValues
im Feld when
abzugleichen,
notIpBlocks
im Feld source
, notPorts
im Feld to
, Cloud Service Mesh
unterstützt den Ausschlussabgleich. Im folgenden Beispiel ist eine gültige Anfrage principals
erforderlich, die von der JWT-Authentifizierung abgeleitet wurde, wenn der Anfragepfad nicht /healthz
ist. Daher schließt die Richtlinie Anfragen an den Pfad /healthz
von der JWT-Authentifizierung aus:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: disable-jwt-for-healthz
namespace: default
spec:
selector:
matchLabels:
app: products
action: ALLOW
rules:
- to:
- operation:
notPaths: ["/healthz"]
from:
- source:
requestPrincipals: ["*"]
Klartext-Anfragen ablehnen
In Cloud Service Mesh 1.5 und höher ist automatisches mTLS standardmäßig aktiviert. Bei „automTLS“ erkennt ein Client-Sidecar-Proxy automatisch, ob der Server einen Sidecar hat. An Arbeitslasten mit Sidecars sendet der Client-Sidecar-Proxy mTLS und an Arbeitslasten ohne Sidecars sendet er Nur-Text-Traffic. Für die beste Sicherheit wird empfohlen, STRICT mTLS zu aktivieren.
Wenn Sie mTLS nicht mit dem Modus STRICT
für eine Arbeitslast oder einen Namespace aktivieren können, haben Sie folgende Möglichkeiten:
- Erstellen Sie eine Autorisierungsrichtlinie, um Traffic mit nicht leeren
namespaces
oder nicht leerenprincipals
explizit zuzulassen, oder - lehnen Sie Traffic mit leeren
namespaces
oderprincipals
ab.
Da namespaces
und principals
nur mit einer mTLS-Anfrage extrahiert werden können, wird Klartext-Traffic durch diese Richtlinien quasi abgelehnt.
Die folgende Richtlinie lehnt die Anfrage ab, wenn das Hauptkonto in der Anfrage leer ist (trifft auf Klartext-Anfragen zu). Die Richtlinie lässt Anfragen zu, wenn das Hauptkonto nicht leer ist. ["*"]
bedeutet, dass es sich um eine nicht leere Übereinstimmung handelt. Die Verwendung von notPrincipals
bedeutet eine Übereinstimmung auf leerem Hauptkonto.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-mtls
namespace: NAMESPACE
spec:
action: DENY
rules:
- from:
- source:
notPrincipals: ["*"]
Vorrang der Autorisierungsrichtlinie
Sie können separate ALLOW
- und DENY
-Autorisierungsrichtlinien konfigurieren. Dazu müssen Sie jedoch die Richtlinienpriorität und das Standardverhalten verstehen, damit die Richtlinien das tun, was Sie möchten. Im folgenden Diagramm wird die Priorisierung der Richtlinien beschrieben.
Die Beispielrichtlinien in den folgenden Abschnitten veranschaulichen einige Standardverhalten und die Situationen, in denen sie für Sie nützlich sein könnten.
Nichts zulassen
Das folgende Beispiel zeigt eine ALLOW
-Richtlinie, die nichts zulässt. Wenn keine anderen ALLOW
-Richtlinien vorhanden sind, werden Anfragen grundsätzlich abgelehnt.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
spec:
action: ALLOW
Es empfiehlt sich, mit der Richtlinie „Allow-Nothing“ zu beginnen und schrittweise weitere ALLOW
-Richtlinien hinzuzufügen, um zusätzlichen Zugriff auf eine Arbeitslast zu ermöglichen.
Gesamten Zugriff verweigern
Das folgende Beispiel zeigt eine DENY
-Richtlinie, die alles ablehnt. Da DENY
-Richtlinien vor ALLOW
-Richtlinien ausgewertet werden, werden alle Anfragen auch dann abgelehnt, wenn eine ALLOW
-Richtlinie die Anfrage zulässt.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
spec:
action: DENY
rules:
- {}
Eine Deny-All-Richtlinie ist nützlich, wenn Sie den gesamten Zugriff auf eine Arbeitslast vorübergehend deaktivieren möchten.
Gesamten Zugriff zulassen
Das folgende Beispiel zeigt eine ALLOW
-Richtlinie, die alles abgleicht und den vollständigen Zugriff auf eine Arbeitslast ermöglicht. Die Richtlinie "Allow-All" macht andere ALLOW
-Richtlinien nutzlos, da die Anfrage immer zugelassen wird.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-all
spec:
action: ALLOW
rules:
- {}
Eine Richtlinie "Alles zulassen" ist nützlich, wenn Sie vorübergehend den vollständigen Zugriff auf eine Arbeitslast verfügbar machen möchten. Wenn DENY
-Richtlinien vorhanden sind, können Anfragen weiterhin abgelehnt werden, da DENY
-Richtlinien vor ALLOW
-Richtlinien ausgewertet werden.
Best Practices
Erstellen Sie ein Kubernetes-Dienstkonto für jeden Dienst und geben Sie das Dienstkonto im Deployment an. Beispiel:
apiVersion: v1 kind: ServiceAccount metadata: name: frontend-sa namespace: demo --- apiVersion: apps/v1 kind: Deployment metadata: name: frontend namespace:demo spec: selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: serviceAccountName: frontend-sa ...
Beginnen Sie mit einer Richtlinie, die nichts zulässt, und fügen Sie schrittweise weitere
ALLOW
-Richtlinien hinzu, um den Zugriff auf Arbeitslasten zu erweitern.Wenn Sie JWTs für Ihren Dienst verwenden:
Erstellen Sie eine
DENY
-Richtlinie, um nicht authentifizierte Anfragen zu blockieren. Beispiel:apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: requireJWT namespace: admin spec: action: DENY rules: - from: - source: notRequestPrincipals: ["*"]
Wenden Sie eine "Allow-Nothing"-Richtlinie an.
Definieren Sie
ALLOW
-Richtlinien für jede Arbeitslast. Beispiele finden Sie unter JWT-Token.
Nächste Schritte
Weitere Informationen zu den Sicherheitsfeatures von Cloud Service Mesh:
- Cloud Service Mesh-Nutzerauthentifizierung konfigurieren
- Audit-Richtlinien für Ihre Dienste konfigurieren
- Transportsicherheit konfigurieren
- Identity-Aware Proxy in das Cloud Service Mesh einbinden
- Best Practices für die Verwendung von Cloud Service Mesh-Gateways für ausgehenden Traffic in GKE-Clustern
Weitere Informationen zu Autorisierungsrichtlinien finden Sie in der Istio-Dokumentation: