Versione 1.14

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Panoramica dei criteri di autorizzazione

A differenza di un'applicazione monolitica che potrebbe essere in esecuzione in un unico posto, le app di microservizi distribuite a livello globale effettuano chiamate attraverso i confini della rete. Ciò significa più punti di accesso alle applicazioni e maggiori opportunità di attacchi dannosi. Inoltre, poiché i pod Kubernetes hanno IP temporanei, le regole firewall tradizionali basate su IP non sono sufficienti per proteggere l'accesso tra i carichi di lavoro. In un'architettura basata su microservizi, è necessario un nuovo approccio alla sicurezza. Sviluppato su funzionalità di sicurezza come gli account di servizio Kubernetes e i criteri di sicurezza di Istio, Anthos Service Mesh offre ancora più funzionalità per aiutarti a proteggere le tue applicazioni.

Questa pagina offre agli operatori dell'applicazione una panoramica della risorsa personalizzata AuthorizationPolicy. I criteri di autorizzazione consentono di abilitare il controllo dell'accesso sui carichi di lavoro a livello di applicazione (L7) e di trasporto (L3/4). Configura i criteri di autorizzazione per specificare le autorizzazioni: cosa può fare questo servizio o utente?

Criteri di autorizzazione

Le richieste tra servizi nel tuo mesh (e tra utenti finali e servizi) sono consentite per impostazione predefinita. Puoi utilizzare la risposta predefinita di AuthorizationPolicy per definire criteri granulari per i tuoi carichi di lavoro. Dopo aver applicato i criteri di autorizzazione, Anthos Service Mesh li distribuisce ai proxy sidecar. Quando le richieste vengono inviate in un 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 singolo carico di lavoro.

  • Per applicare un criterio a livello di mesh, specifica lo spazio dei nomi root, istio-system, 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 campo 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 del criterio può essere l'intero mesh, uno spazio dei nomi o un carico di lavoro specifico. Se lo includi, il campo selector specifica la destinazione del criterio.

  • Il campo action consente di specificare se ALLOW o DENY è la richiesta. Se non specifichi un'azione, per impostazione predefinita l'azione è impostata su ALLOW. Per maggiore chiarezza, ti consigliamo di specificare sempre l'azione. I criteri di autorizzazione supportano anche le azioni AUDIT e CUSTOM.

  • L'elemento rules specifica quando attivare l'azione.

    • Il campo from in rules specifica le origini della richiesta.

    • Il campo to in rules specifica le operazioni della richiesta.

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

Nel seguente esempio:

  • Il criterio viene applicato alle richieste al servizio frontend nello spazio dei nomi demo.

  • Le richieste sono consentite quando &hellot;hello:world" è nell'intestazione della richiesta; in caso contrario, 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"]

Controllo dell'accesso durante l'operazione di richiesta

Puoi controllare l'accesso a specifiche operazioni di richieste, come metodi HTTP o porte TCP, aggiungendo una sezione to in rules. Nell'esempio seguente, sono consentiti solo i metodi HTTP GET e POST per 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 degli accessi sull'identità autenticata

Negli esempi precedenti, i criteri consentono le richieste provenienti da carichi di lavoro non autenticati. Se hai abilitato STRICT TLS reciproco (mTLS), puoi limitare l'accesso in base all'identità del carico di lavoro o dello spazio dei nomi da cui effettua la richiesta nella sezione source.

  • Utilizza il campo principals o notPrincipal per controllare l'accesso a livello di carico di lavoro.

  • Utilizza il campo namespaces o notNamespaces per controllare l'accesso a livello di spazio dei nomi.

Tutti i campi precedenti richiedono l'attivazione di STRICT mTLS. Se non puoi impostare mTLS STRICT, consulta l'articolo Rifiutare le richieste di testo non crittografato per una soluzione alternativa.

Carico di lavoro identificato

Nell'esempio seguente, le richieste all'currencyservice sono consentite solo dal servizio frontend. Le richieste al currencyservice da altri carichi di lavoro sono state rifiutate.

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, le entità di principals per l'autorità di certificazione Anthos Service Mesh (Mesh CA) e per Certificate Authority Service (CA Service) devono essere nel seguente formato:

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

PROJECT_ID.svc.id.googè il dominio di attendibilità per Mesh CA. Se utilizzi CA CA (precedentemente nota come Cittadella), il dominio di attendibilità 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 nei criteri di autorizzazione supporta tutti i seguenti schemi corrispondenti:

  • Corrispondenza esatta: corrispondenza esatta della stringa.
  • Corrispondenza con carattere jolly utilizzando il carattere "*":
    • Corrispondenza prefisso: una stringa con un suffisso "*". Ad esempio, "test.abc.*" corrisponde a "test.abc.com" o "test.abc.com.cn".
    • Corrispondenza suffisso: una stringa con un "*" iniziale. Ad esempio, "*.abc.com" corrisponde a "eng.abc.com" o "test.eng.abc.com".
  • Corrispondenza presenza. Per specificare che un campo deve essere presente e non vuoto, utilizza il formato fieldname: ["*"]. Diverso è il modo in cui non viene specificato un campo, il che significa che deve corrispondere a qualsiasi valore, incluso vuoto.

Esistono alcune eccezioni. Ad esempio, i seguenti campi supportano solo la corrispondenza esatta:

  • Il campo key nella sezione when
  • L'elemento ipBlocks nella sezione source
  • Il campo ports nella sezione to

Il seguente criterio di esempio consente l'accesso ai 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 soddisfare le condizioni negative come notValues nel campo when, notIpBlocks nel campo source, notPorts nel campo to, Anthos Service Mesh supporta la corrispondenza di esclusione. L'esempio seguente richiede una richiesta valida principals, che deriva dall'autenticazione JWT, se il percorso della richiesta non è /healthz. Pertanto, il criterio esclude le richieste al percorso /healthz dall'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 normale

In Anthos Service Mesh 1.5 e versioni successive, il protocollo mTLS automatico è abilitato per impostazione predefinita. Con mTLS automatico, un proxy sidecar client rileva automaticamente se il server ha una sidecar. Il sidecar client invia mTLS ai carichi di lavoro con sidecar e invia testo non crittografato ai carichi di lavoro senza sidecar. Per una migliore sicurezza, ti consigliamo di attivare STRICT mTLS.

Se non riesci ad abilitare mTLS con la modalità STRICT per un carico di lavoro o uno spazio dei nomi, puoi:

  • Creare un criterio di autorizzazione per consentire esplicitamente il traffico con elementi namespaces non vuoti o principals non vuoti oppure
  • rifiuta il traffico con namespaces o principals vuoti.

Poiché namespaces e principals possono essere estratti solo con una richiesta mTLS, questi criteri rifiutano qualsiasi traffico di testo non crittografato.

Il seguente criterio rifiuta la richiesta se l'entità nella richiesta è vuota (come nel caso delle richieste di testo normale). Il criterio consente le richieste se l'entità non è vuota. ["*"] significa una corrispondenza non vuota, mentre con notPrincipals significa corrispondere su entità vuota.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-mtls
  namespace: NAMESPACE
spec:
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals: ["*"]

Priorità criteri di autorizzazione

Puoi configurare criteri di autorizzazione distinti per ALLOW e DENY, ma devi prima comprendere la precedenza dei criteri e il comportamento predefinito per assicurarti che rispettino i requisiti desiderati. Il seguente diagramma descrive la precedenza dei criteri.

precedenza criteri di autorizzazione

I criteri di esempio riportati nelle seguenti sezioni illustrano alcuni del comportamento predefinito e le situazioni in cui potrebbero essere utili.

Non consentire nulla

L'esempio seguente mostra un criterio ALLOW che non corrisponde a nulla. Per impostazione predefinita, se non esistono altri criteri ALLOW, le richieste vengono sempre rifiutate.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW

È buona norma iniziare con il criterio allow-nothing e aggiungere gradualmente altri criteri ALLOW per aprire un accesso aggiuntivo a un carico di lavoro.

Nega tutti gli accessi

L'esempio seguente mostra un criterio DENY che corrisponde a tutto. Poiché i criteri DENY vengono valutati prima dei criteri ALLOW, 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 rifiuto è utile se vuoi disabilitare temporaneamente 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 di autorizzazione consente di rendere inutili gli altri criteri ALLOW perché consente sempre la richiesta.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  rules:
  - {}

Un criterio di autorizzazione è utile se vuoi esporre temporaneamente l'accesso completo a un carico di lavoro. Se sono presenti criteri DENY, le richieste potrebbero comunque essere rifiutate dal momento che i criteri DENY vengono valutati prima dei criteri ALLOW.

Best practice

  1. crea un account di servizio Kubernetes per ogni servizio e specifica l'account di servizio 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 "allow-noth" e aggiungi in modo incrementale altri criteri ALLOW per aprire un accesso più ampio 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. Applica un criterio di non autorizzazione.

    3. Definisci i criteri ALLOW per ogni carico di lavoro. Ad esempio, consulta Token JWT.

Passaggi successivi

Scopri di più sulle funzionalità di sicurezza di Anthos Service Mesh:

Scopri di più sui criteri di autorizzazione nella documentazione di Istio: