Panoramica dei criteri di autorizzazione

Nota: questa guida supporta solo Cloud Service Mesh con le API Istio non supportano le API Google Cloud. Per ulteriori informazioni, vedi Panoramica di Cloud Service Mesh.

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 controllo dell'accesso 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.

Consulta la sezione Funzionalità supportate per maggiori dettagli delle RP AuthorizationPolicy sono supportati dalla piattaforma.

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 campo metadata: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 essere ALLOW o DENY. Se non specifichi un'azione, per impostazione predefinita l'azione è impostata su ALLOW. Per chiarezza, ti consigliamo di specificare sempre l'azione. (Autorizzazione le norme supportano anche AUDIT e CUSTOM azioni. L'azione AUDIT è supportata solo su alcune piattaforme. Consulta Funzionalità supportate per maggiori dettagli.

• La rules specificare quando attivare l'azione.

  • Il campo from in rules specifica fonti della richiesta.

  • Il campo to in rules specifica operations della richiesta.

  • Il campo when specifica ulteriori conditions necessarie per applicare la regola.

Nell'esempio seguente:

• Il criterio viene applicato alle richieste al servizio frontend in demo.

• 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 operations 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 o notPrincipal per controllare l'accesso a a livello di carico di lavoro.

• Utilizza il campo namespaces o notNamespaces 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, principals deve essere nel seguente formato:

principals: ["PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT_NAME"]

Se utilizzi Cloud Service Mesh nel cluster con Citadel CA: cluster.local è il dominio attendibile. In tutti gli altri casi, PROJECT_ID.svc.id.googè il dominio attendibile per il mesh.

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 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 sezione when
• ipBlocks nella sezione source
• Il campo ports nella sezione to

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, mTLS automatico è abilitato per impostazione predefinita. Con mTLS automatico, il proxy sidecar client rileva automaticamente se il server ha un file collaterale. La il lato client invia mTLS ai carichi di lavoro con file collaterali e invia il testo non crittografato a carichi di lavoro senza sidecar. Per la migliore sicurezza, ti consigliamo di abilita 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 o principals non vuoto oppure
• rifiuta il traffico con valori namespaces o principals 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

È buona prassi di sicurezza iniziare con il criterio "Consenti niente" e aggiungere 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 disattivare temporaneamente del tutto l'accesso 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

1. 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
       ...
   

2. Inizia con un criterio "Non consentire nulla" e aumenta aggiungi altri criteri ALLOW per ottenere un maggiore accesso ai carichi di lavoro.

3. Se utilizzi JWT per il tuo servizio:

   1. 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: ["*"]
      

   2. Applicare un criterio di tipo allow-nothing.

   3. 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:

• Esempi di criteri di autorizzazione
• Risoluzione dei problemi relativi ai criteri di autorizzazione