C'è un modo per garantire che il servizio A sia chiamato solo dal servizio B (o da una serie di servizi autorizzati)? Tutti i servizi sono indipendenti e non passano attraverso un gateway di servizio poiché sono completamente indipendenti.
Ci sono dei buoni modelli di microservizi da seguire su questo?
Qual è l'obiettivo dell'autenticazione?
Suppongo che tu lo stia facendo per sicurezza.
È ragionevole provare a proteggere i tuoi microservizi da accessi non autorizzati. Un approccio comune è progettare una rete con una DMZ:
---LAN------ --DMZ-- #: router/firewall
inner outer
+---+---+---#---+---#--- internet
| | | |
S S S G
services gateway,
web server
Tutte le connessioni esterne passano attraverso il gateway che può fornire l'autenticazione.
I router fungono da firewall e implementano le seguenti regole:
Ciò impedisce qualsiasi connessione diretta esterna ai servizi interni. Per consentire a un utente malintenzionato di connettersi ai servizi, è necessario che i servizi inizino la connessione oppure che il gateway / server Web debba essere prima compromesso o che i router debbano essere compromessi. Se il gateway è compromesso, l'utente malintenzionato può connettersi ai servizi ma non si troverà sulla stessa rete e ad es. essere in grado di annusare o spoofare i pacchetti sulla LAN.
In quanto tale, questo design di rete consente una difesa approfondita, specialmente contro gli attacchi che colpiscono i livelli più bassi dello stack (ad esempio sistemi operativi, server Web). Si consiglia inoltre di eseguire in pubblico software ad alto rischio come CMS popolari come Wordpress. Con topologie di rete più complesse puoi esercitare un controllo più dettagliato sulle possibili connessioni, ad es. è possibile impedire a due serie di servizi di connettersi l'un l'altro inserendoli in reti diverse e non configurando un percorso tra di loro. Anche se i servizi non si trovano sulla stessa rete fisica, puoi utilizzare tecniche come bridge di rete, VPN e VLAN per indirizzare il traffico tra di loro.
Una variante di questo modello è "esegui la tua app Web su localhost e usa Nginx come proxy inverso". Non ascoltando su un'interfaccia esterna / indirizzo IP, l'app Web non può essere raggiunta dall'esterno. Il server Nginx è esposto su un indirizzo IP pubblico e può connettersi all'app Web sullo stesso computer. Invece di ascoltare su localhost, vengono usati spesso socket Unix. Nginx può prendersi cura di alcuni potenziali problemi, come il rifiuto di richieste malformate prima che possano innescare un bug nell'app Web.
Come ulteriore livello è possibile aggiungere misure di sicurezza a livello di applicazione per impedire le connessioni a servizi arbitrari da parte di un utente malintenzionato all'interno della rete. Ad esempio, creare una chiave privata per il proprio sistema di distribuzione. Quando viene distribuito un servizio, ottiene la corrispondente chiave pubblica e i token firmati in stile JWT che consentono di chiamare altri servizi. Quando un servizio riceve una richiesta, controlla la firma sul token e il token consente questo tipo di richiesta. Ma è difficile farlo correttamente senza ad es. consentendo ai token di essere riutilizzati da un utente malintenzionato.
Perché faresti una cosa del genere?
Tecnicamente, è possibile semplicemente limitando l'utilizzo di un servizio A all'utente X che corrisponde al servizio B. Qualsiasi altro utente che tenta di accedere al servizio non sarà in grado di autenticare, cioè riceverà l'HTTP 401 Non autorizzato in risposta.
Gli indirizzi IP di whitelisting sarebbero un incubo da mantenere, dal momento che il servizio B verrebbe distribuito su più istanze e potrebbe essere dismesso su macchine vecchie che sarebbero poi riutilizzate per altri servizi. Non farlo.
Leggi altre domande sui tag microservices authentication