In DoiT International collaboriamo con numerose aziende software in tutto il mondo e ci capita spesso di ricevere richieste analoghe da clienti diversi. Di recente mi sono imbattuto in più casi in cui le organizzazioni avevano la necessità di convogliare i log da più progetti Google Cloud Platform (GCP) in un unico progetto, così da accedervi e monitorarli in modo centralizzato.
Molte aziende inviano i log a provider di terze parti come Datadog, Splunk e altri; in questo articolo, invece, mostrerò come unificare i file di log con tanto di controllo degli accessi sfruttando esclusivamente il servizio Cloud Logging di GCP (in precedenza Stackdriver). Il risultato è una soluzione semplice ed elegante a un'esigenza sempre più diffusa.
Architettura
Panoramica dell'architettura della demo
TL;DR
Per questo esempio creerò due progetti di test e configurerò i relativi log per inviarli a un progetto centrale. Come bonus, mostrerò anche come centralizzare monitoring e metriche (un altro caso d'uso ricorrente).
- Creare tre progetti di test su GCP: mike-test-log-view, mike-test-log-a e mike-test-log-b
- Creare un logs bucket nel progetto mike-test-log-view e copiare il percorso del bucket
- Creare un log sink di tipo Cloud Logging bucket che punti al percorso copiato al passaggio 2, sia per il progetto mike-test-log-a sia per mike-test-log-b
- Aprire i dettagli di ciascun log sink e copiare l'indirizzo email del Service Account writer entity (creato dinamicamente per ognuno)
- Modificare i ruoli IAM nel progetto mike-test-log-view e aggiungere ciascun Service Account copiato dai log sink, assegnando a ognuno il ruolo Logs Bucket Writer
- Modificare i ruoli IAM nel progetto mike-test-log-view e aggiungere il ruolo Logs View Accessor con una condizione che punti al percorso del logs bucket (per limitare l'accesso a livello di utente)
- Aprire la pagina Logs Explorer, fare clic su "Refine Scope" in alto, selezionare "Scope by storage" e quindi il proprio logs bucket
Procedura passo passo
I passaggi che seguono mostrano come convogliare i log da più progetti Google Cloud Platform in un unico progetto centralizzato.
Passo 1: creare i progetti di test
Questo passaggio si commenta da solo. Ho creato tre progetti come descritto sopra a scopo dimostrativo.
Passo 2: creare il logs bucket nel progetto view
Aprire Logs Storage, fare clic su "Create Logs Bucket" e copiare il percorso del bucket
Passo 3: creare i log sink nei progetti di test
Creare i log sink rispettivamente nei progetti di test a e b.
Impostare la destinazione del sink su "Cloud Logging Bucket"
Selezionare l'opzione "Use a logs bucket in another project"
Log sink per il progetto di test "a": alla destinazione si aggiunge il percorso del logs bucket (dopo il dominio)
Log sink per il progetto di test "b": alla destinazione si aggiunge il percorso del logs bucket (dopo il dominio)
Passo 4: aprire i dettagli dei log sink e prendere nota della writer identity IAM
Per ciascun progetto di test, nella vista a elenco della pagina "Log Router Sinks" fare clic sui "…" (3 puntini) all'estrema destra della riga corrispondente al nuovo log sink e selezionare "View Details".
Copiare la "Writer identity", ovvero il service account creato dinamicamente insieme al log sink. Lo aggiungerà al progetto view per consentirgli di scrivere le voci di log nel logs bucket centrale.
Passo 5: modificare i ruoli IAM nel progetto view per i writer dei log sink
Per ciascun log sink, nel progetto view centrale, aprire la pagina di amministrazione IAM e aggiungere un membro con ruolo Logs Bucket Writer utilizzando il service account "Writer identity" copiato al passaggio 4, come mostrato.
Aggiunta dei ruoli IAM per consentire ai log sink di scrivere voci di log nel progetto view
Passo 6: modificare i ruoli IAM nel progetto view per chi consulta i log
Affinché gli utenti possano visualizzare i log in Logs Explorer, occorre permettere loro di modificare la view (o scope) assegnando il ruolo Logs View Accessor.
Concedere agli utenti la possibilità di modificare la view (scope) di Logs Explorer
È possibile (e consigliabile) affinare ulteriormente il ruolo IAM dell'utente aggiungendo una condizione che limiti l'accesso alle sole risorse desiderate. In questo caso, al percorso del logs bucket appena creato. In questo modo si circoscrive la visualizzazione degli utenti ai soli log e bucket previsti, utile ai fini dei controlli di compliance.
Passo 7: visualizzare i log
Una volta impostate le autorizzazioni, nel giro di pochi minuti dovrebbero iniziare a comparire le voci di log nel progetto view. Per prima cosa occorre fare clic su "Refine Scope" e selezionare la sorgente di log desiderata, come mostrato.
Affinamento dello scope della view di Logs Explorer per esplorare i log inviati al Logs Bucket dai sink
Fatto! Dal progetto view è ora possibile consultare i log provenienti dagli altri progetti, come mostrato.
I log del progetto di test "a" sono visibili nel progetto "view"
Bonus \#1: ridurre i costi con i filtri di esclusione
È possibile disabilitare il log sink "_Default" nei propri progetti per evitare di pagare il logging in più punti.
Nei log sink si possono inoltre aggiungere filtri di esclusione (o di inclusione) per stabilire quali servizi inviare e quali scartare.
- Managing logs exclusions
- Suggerimento: il campo "rate" è una percentuale di campionamento: impostarlo su 100(%)
Bonus \#2: centralizzare Cloud Monitoring
Google Cloud Operations (in precedenza Stackdriver) è una piattaforma di osservabilità completa che, oltre al logging, comprende un altro strumento chiamato Cloud Monitoring.
Con pochi clic si può creare un "Workspace" nel progetto view e selezionare gli altri progetti per centralizzare monitoring e dashboard, se lo si desidera.
Mi auguro che questo articolo possa aiutarvi a organizzare e gestire meglio logging e osservabilità all'interno della vostra organizzazione. Seguitemi oppure consultate il DoiT Blog per altri articoli su consigli e tecniche, nuove funzionalità, best practice e molto altro sul cloud pubblico.