Panoramica dei criteri di autorizzazione
A differenza di un'applicazione monolitica eseguita in una singola posizione, le app di microservizi distribuite a livello globale effettuano chiamate oltre i confini della rete. Ciò significa più punti di ingresso nelle applicazioni e più opportunità contro gli attacchi dannosi. Inoltre, poiché i pod Kubernetes hanno IP temporanei, le regole firewall tradizionali basate su IP non sono adeguate per proteggere l'accesso carichi di lavoro con scale out impegnativi. In un'architettura di microservizi, un nuovo approccio alla sicurezza è necessaria. Sfruttando funzionalità di sicurezza come Account di servizio Kubernetes e i criteri di sicurezza Istio, Cloud Service Mesh offre ancora più funzionalità per aiutarti a proteggere diverse applicazioni.
Questa pagina offre agli operatori delle applicazioni una panoramica dell'AuthorizationPolicy
risorsa personalizzata (RP). I criteri di autorizzazione ti consentono di abilitare il controllo dell'accesso
carichi di lavoro a livello di applicazione (L7) e trasporto (L3/4). Configura
criteri di autorizzazione per specificare le autorizzazioni. Che cos'è questo servizio o utente
che possono eseguire?
Criteri di autorizzazione
Le richieste tra i servizi nel tuo mesh (e tra utenti finali e servizi) vengono
consentito per impostazione predefinita. Utilizzi la RP AuthorizationPolicy
per definire
per i tuoi carichi di lavoro. Dopo aver applicato i criteri di autorizzazione,
Cloud Service Mesh li distribuisce ai proxy sidecar. Quando le richieste entrano in
carico di lavoro, il proxy sidecar controlla i criteri di autorizzazione per determinare se
la richiesta deve essere consentita o rifiutata.
Ambito dei criteri
Puoi applicare un criterio all'intero mesh di servizi, a uno spazio dei nomi o a un per ogni carico di lavoro.
Per applicare un criterio a livello di mesh, specifica lo spazio dei nomi principale,
istio-system
, in Nel campometadata:namespace
:apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "mesh-wide" namespace: istio-system spec: ...
Per applicare un criterio a uno spazio dei nomi, specifica lo spazio dei nomi nel Campo
metadata:namespace
:apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "currencyservice" namespace: currencyservice spec: ...
Per limitare un criterio a un carico di lavoro specifico, includi un
selector
.apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "frontend" namespace: demo spec: selector: matchLabels: app: frontend ...
Struttura di base
Un criterio di autorizzazione include l'ambito del criterio, un action
e un elenco di
rules
:
Come descritto nella sezione precedente, l'ambito delle norme può essere l'intera rete mesh, uno spazio dei nomi o un carico di lavoro specifico. Se lo includi, Il campo
selector
consente di specificare la destinazione del criterio.Il campo
action
consente di specificare se la richiesta deve essereALLOW
oDENY
. Se non specifichi un'azione, per impostazione predefinita l'azione è impostata suALLOW
. Per chiarezza, ti consigliamo di specificare sempre l'azione. (Autorizzazione le norme supportano ancheAUDIT
eCUSTOM
actions.)La
rules
specificare quando attivare l'azione.Il campo
from
inrules
specifica fonti della richiesta.Il campo
to
inrules
specifica operazioni della richiesta.Il campo
when
specifica ulteriori condizioni necessarie per applicare la regola.
Nell'esempio seguente:
Il criterio viene applicato alle richieste al servizio
frontend
indemo
.Le richieste sono consentite quando "hello:world" è nell'intestazione della richiesta, altrimenti le richieste vengono rifiutate.
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"]
Operazione di controllo dell'accesso su richiesta
Puoi controllare l'accesso a una richiesta specifica
operazioni
come i metodi HTTP o le porte TCP, aggiungendo una sezione to
in rules
.
Nell'esempio seguente, sono consentiti solo i metodi HTTP GET
e POST
a currencyservice
nello spazio dei nomi demo
.
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"]
Controllo dell'accesso sull'identità autenticata
Negli esempi precedenti, i criteri consentono le richieste da parte di utenti
carichi di lavoro con scale out impegnativi. Se disponi
TLS reciproco (mTLS) (mTLS) abilitato per STRICT
,
puoi limitare l'accesso in base all'identità del carico di lavoro o dello spazio dei nomi che
la richiesta proviene dal
source
.
Utilizza il campo
principals
onotPrincipal
per controllare l'accesso a a livello di carico di lavoro.Utilizza il campo
namespaces
onotNamespaces
per controllare l'accesso a a livello di spazio dei nomi.
Per tutti i campi precedenti è necessario che STRICT
mTLS sia abilitato. Se
impossibile impostare STRICT
mTLS, vedi
Rifiutare le richieste di testo non crittografato per un'alternativa
soluzione.
Carico di lavoro identificato
Nell'esempio seguente, sono consentite solo richieste a currencyservice
dal servizio frontend
. Richieste a currencyservice
da altri
di carichi di lavoro negati.
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"]
Per specificare un account di servizio, il valore principals
per
Autorità di certificazione Cloud Service Mesh (Mesh CA)
e Certificate Authority Service
(CA Service) deve essere nel seguente formato:
principals: ["PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT_NAME"]
PROJECT_ID.svc.id.goog
è la
dominio attendibile per Mesh CA. Se
utilizzando Istio CA (precedentemente noto come Citadel), il dominio trust predefinito è
cluster.local
.
Spazio dei nomi identificato
L'esempio seguente mostra un criterio che nega le richieste se l'origine non è
lo spazio dei nomi foo
:
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"]
Corrispondenza dei valori
La maggior parte dei campi dei criteri di autorizzazione supporta tutte le seguenti schemi:
- Corrispondenza esatta: corrispondenza stringa esatta.
- Corrispondenza con caratteri jolly mediante il carattere jolly
"*"
:- Corrispondenza prefisso: una stringa con un suffisso
"*"
. Ad esempio:"test.example.*"
corrisponde a"test.example.com"
o"test.example.com.cn"
. - Corrispondenza suffisso: una stringa con un
"*"
iniziale. Ad esempio:"*.example.com"
corrisponde a"eng.example.com"
o"test.eng.example.com"
.
- Corrispondenza prefisso: una stringa con un suffisso
- Corrispondenza presenza: per specificare che un campo deve essere presente e non vuoto, utilizza
nel formato
fieldname: ["*"]
. Questo è diverso dall'abbandonare un campo non specificato, il che significa che corrisponde a qualsiasi elemento, anche vuoto.
Esistono però alcune eccezioni. Ad esempio, i seguenti campi supportano solo corrispondenza esatta:
- Il campo
key
nella sezionewhen
ipBlocks
nella sezionesource
- Il campo
ports
nella sezioneto
Il seguente criterio di esempio consente l'accesso nei percorsi con il prefisso /test/*
o il suffisso */info
:
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"]
Corrispondenza delle esclusioni
Per far corrispondere le condizioni escluse come notValues
nel campo when
,
notIpBlocks
nel campo source
, notPorts
nel campo to
, Cloud Service Mesh
supporta la corrispondenza delle esclusioni. L'esempio seguente richiede una richiesta valida
principals
, che deriva dall'autenticazione JWT, se il percorso di richiesta è
non /healthz
. Pertanto, il criterio esclude le richieste al percorso /healthz
da
l'autenticazione JWT:
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: ["*"]
Rifiuta richieste di testo non crittografato
In Cloud Service Mesh 1.5 e versioni successive, mTLS automatico è abilitato per impostazione predefinita. Con mTLS, un proxy sidecar client rileva automaticamente se il server ha un di terze parti. Il lato client invia mTLS ai carichi di lavoro con file collaterali e invia come testo non crittografato a carichi di lavoro senza file collaterali. Per la massima sicurezza, ti consigliamo di abilitare STRICT mTLS.
Se non riesci ad abilitare mTLS con la modalità STRICT
per un carico di lavoro o
dello spazio dei nomi, puoi:
- crea un criterio di autorizzazione per consentire esplicitamente il traffico con
namespaces
oprincipals
non vuoto oppure - rifiuta il traffico con valori
namespaces
oprincipals
vuoti.
Perché namespaces
e principals
possono essere estratti soltanto con un protocollo mTLS
, queste norme respingono in modo efficace qualsiasi traffico di testo non crittografato.
Il seguente criterio nega la richiesta se l'entità nella richiesta viene
vuoto (come nel caso delle richieste in testo non crittografato). Il criterio consente
richieste se l'entità non è vuota. ["*"]
significa una corrispondenza non vuota,
utilizzare con notPrincipals
significa trovare una corrispondenza su un'entità vuota.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-mtls
namespace: NAMESPACE
spec:
action: DENY
rules:
- from:
- source:
notPrincipals: ["*"]
Precedenza criterio di autorizzazione
Puoi configurare criteri di autorizzazione ALLOW
e DENY
separati,
la precedenza e il comportamento predefinito dei criteri,
i criteri fanno quello che vuoi. Il seguente diagramma descrive le norme
la precedenza.
I criteri di esempio nelle sezioni seguenti illustrano alcuni dei criteri predefiniti il loro comportamento e le situazioni in cui potrebbero esserle utili.
Non consentire nulla
L'esempio seguente mostra un criterio ALLOW
che non corrisponde ad alcun criterio. Di
per impostazione predefinita, se non esistono altri criteri ALLOW
, le richieste vengono sempre negate.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
spec:
action: ALLOW
È una buona prassi di sicurezza iniziare con il criterio "Consenti niente" e
aggiungi in modo incrementale altri criteri ALLOW
per aprire un maggiore accesso a un carico di lavoro.
Nega ogni accesso
L'esempio seguente mostra un criterio DENY
che corrisponde a tutto. Poiché
DENY
criteri vengono valutati prima di ALLOW
criteri. Tutte le richieste vengono rifiutate
anche se esiste un criterio ALLOW
che corrisponde alla richiesta.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
spec:
action: DENY
rules:
- {}
Un criterio di negazione di tutto è utile se vuoi disabilitare temporaneamente l'accesso completo a un carico di lavoro.
Consenti tutti gli accessi
L'esempio seguente mostra un criterio ALLOW
che corrisponde a tutto e
consente l'accesso completo a un carico di lavoro. Il criterio allow-all rende ALLOW
inutili perché consente sempre la richiesta.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-all
spec:
action: ALLOW
rules:
- {}
Un criterio allow-all è utile se vuoi esporre temporaneamente l'accesso completo
per un carico di lavoro. Se esistono criteri DENY
, le richieste potrebbero comunque essere rifiutate
poiché DENY
criteri vengono valutati prima di ALLOW
criteri.
Best practice
Creare un account di servizio Kubernetes per ogni servizio e specificare nel deployment. Ad esempio:
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 ...
Inizia con un criterio Non consentire nulla e aumenta aggiungi altri criteri
ALLOW
per ottenere un maggiore accesso ai carichi di lavoro.Se utilizzi JWT per il tuo servizio:
Crea un criterio
DENY
per bloccare le richieste non autenticate, ad esempio:apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: requireJWT namespace: admin spec: action: DENY rules: - from: - source: notRequestPrincipals: ["*"]
Applicare un criterio di tipo allow-nothing.
Definisci
ALLOW
criteri per ogni carico di lavoro. Per alcuni esempi, vedi Token JWT.
Passaggi successivi
Scopri di più sulle funzionalità di sicurezza di Cloud Service Mesh:
- Configurare l'autenticazione utente di Cloud Service Mesh
- Configurare i criteri di controllo per i servizi
- Configurare la sicurezza del trasporto
- Integrazione di Identity-Aware Proxy con Cloud Service Mesh
- Best practice per l'utilizzo dei gateway in uscita di Cloud Service Mesh sui cluster GKE
Scopri di più sui criteri di autorizzazione nella documentazione di Istio: