Come impedire che i segreti di Home Assistant finiscano nei file Compose o nei backup

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Prevent Home Assistant Secrets From Leaking Into Compose Files or Backups - Zima Store Online

Previeni la divulgazione di segreti mantenendo i valori fuori dalle definizioni Compose condivisibili e trattando ogni backup o esportazione diagnostica come materiale sensibile finché non supera una scansione dei contenuti.

Home Assistant ha bisogno delle credenziali durante l’esecuzione, quindi nessuna configurazione locale può renderle invisibili a un amministratore con accesso completo all’host. L’obiettivo pratico è più circoscritto: impedire commit accidentali, caricamenti di supporto, copie di backup troppo ampie e accessi non necessari ai container. Fai un inventario dei punti in cui ogni valore entra nello stack, sostituisci i valori letterali con una fonte di segreti controllata e verifica gli artefatti esportati senza stampare i segreti.

Mappa ogni punto in cui un segreto può fuoriuscire

Elenca token API, password dei database, credenziali MQTT, URL dei webhook, chiavi di crittografia, certificati privati e chiavi di ripristino. Per ciascuno, annota il componente che lo usa durante l’esecuzione, il percorso di archiviazione, il proprietario del file, l’inclusione nei backup, lo stato nel repository, l’esposizione nei log e il metodo di rotazione. Non copiare i valori nell’inventario.

I file dei segreti organizzano i valori, ma restano in testo semplice per un account in grado di leggere l’host. Questo confine di accesso al testo semplice significa che la separazione riduce soprattutto la divulgazione accidentale, anziché contrastare un attaccante con privilegi completi.

È un errore qualsiasi valore letterale presente nel file YAML di Compose, un file di ambiente tracciato, una directory di configurazione leggibile da molti utenti o un’esportazione dal contenuto sconosciuto. Sospendi la condivisione e i push al repository finché ogni percorso di esposizione non ha un responsabile e una correzione.

Separa i segreti di runtime dalle definizioni di distribuzione

Sostituisci i valori letterali in Compose con segreti basati su file, concessi in modo mirato, o con un’altra fonte di segreti supportata dalla distribuzione. Fornisci a ogni servizio solo i valori che utilizza, montali in sola lettura quando possibile e limita i permessi dell’host all’identità di runtime e agli amministratori.

I valori d’ambiente possono emergere durante l’ispezione, nel contesto dei processi o nei log, mentre il montaggio dei segreti basato su file può limitare i container che ricevono una credenziale. Anche i file locali dei segreti richiedono un controllo dei permessi.

Convalida prima con segnaposto, ispeziona la configurazione Compose renderizzata per individuare eventuali valori letterali accidentali, quindi avvia un solo servizio e verifica che possa leggere esclusivamente il segreto assegnato. Esegui il rollback se la modifica induce l’applicazione a ripetere i valori o richiede l’accesso permissivo alla directory.

Controlla il contenuto dei backup e dei pacchetti di supporto

Classifica i backup come contenenti credenziali, a meno che non sia dimostrato il contrario. Cifra le copie che escono dal perimetro di archiviazione attendibile, conserva separatamente le chiavi di ripristino, limita conservazione e accesso e non allegare mai un archivio completo della configurazione quando un estratto di log redatto è sufficiente a rispondere alla richiesta di supporto.

Usa il flusso di lavoro per la protezione della configurazione per preservare la possibilità di ripristino, separando al contempo l’archiviazione sicura dai materiali di distribuzione condivisibili.

Prima del rilascio, analizza i nomi dei file e il testo estratto alla ricerca di nomi di chiavi noti, prefissi dei token, URL privati, indirizzi email, certificati e hash esatti dei marcatori di test controllati. Una scansione pulita è un requisito per il rilascio, non la prova che non possa esistere un formato di segreto sconosciuto.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Ruota le credenziali esposte e dimostra l’efficacia del percorso di prevenzione

Se un valore utilizzabile è entrato in un repository, ticket, chat, link pubblico o backup non attendibile, revocalo o ruotalo prima di tutto; eliminare la copia visibile non invalida le copie o la cronologia. Registra il servizio interessato e l’ora della rotazione senza conservare il vecchio valore.

Crea un segreto canarino innocuo, distribuiscilo attraverso il nuovo percorso, genera il normale rendering di Compose, il backup e il pacchetto diagnostico, quindi cerca quel valore negli artefatti. Il runtime dovrebbe ricevere il segreto canarino, mentre gli artefatti condivisibili non dovrebbero esporlo al di fuori del perimetro di backup intenzionalmente protetto.

Concludi quando i segreti reali sono assenti dalle definizioni di distribuzione e dai repository, i backup protetti hanno un percorso di ripristino separato, le scansioni degli artefatti hanno esito positivo e le credenziali esposte sono state ruotate. Escala il problema quando un’integrazione di terze parti registra nei log i valori segreti o non può utilizzare una fonte di segreti limitata senza un accesso più ampio all’host.