per ora è un scope fisso → ai4y0

service mesh è un addon a openshift, reverse proxy, pod applicativo e centralizza la gestione, con regole layer 4 o 7, permette di gestire

• autenticazione oauth
• traffic shaping
• throttling
• ogni app ha il suo, ha una control plane che permette di inserire delle regole di comunicazione
• gloomesh è una implementazione di service mesh che permette una più agile configurazione multi cluster, quindi ho un mesh distribuito → puoi metterli in comunicazione

service mesh: autorizzatore, anche nella soluzione non target

come lo istruiamo?

• opa server? dalle conf di opa server forse è possibile
• altro

ora

• la comunicazione è garantita all’interno del perimetro arancione, le policy mtls in atto consentono il trust all’interno del perimetro arancione
• se sei fuori dal perimetro arancione, col token, chiami i servizi solo con gli url di cui sopra
• non devo fare continui scambi di token, etc
• se in futuro ad esempio volessi fare chiamare il dispatcher solo product, cambi trust mtls per farlo
• mtls garantisce sicurezza se non è possibile movimento laterale da un servizio interno (scambio di certificati che dice: posso parlare con te?), ogni microservizio ha il trust → mtls è la soluzione per comunicazione service to service
• service mesh fa enforcing su workspace openshift, che possono spannare più cluster (gcp e azure ad esempio) → il trust è automatico se crei un altro servizio all’interno del perimetro con policy già creata
• jwt si usa su layer di frontiera!
• il token non viene verificato all’interno della frontiera, possiamo passarlo per questioni di uso ma non viene verificato dal service mesh

a target vogliamo

• sapere quale acronimo ci ha chiamato
• rendere automatica assegnazione degli scope all’acronimo chiamante (requisito di architetture, no scope unico per tutti)
  • esempio: servizio ai non più sicuro, se non hai una tracciatura automatica, se vuoi inibire uno sope o una applicazione devi tracciare → requisito di sicurezza