Vault: come funziona l'autenticazione di AppRole?

Naviga le tue risposte
19

Ho un'applicazione server (su infrastruttura dinamica) che deve recuperare un segreto da Hashicorp Vault durante l'avvio.

Supponiamo che dobbiamo renderlo il più sicuro possibile. Dai documenti e dagli esempi sull'autenticazione di AppRole Capisco che, dopo che un amministratore di Vault ha creato l'approle e il segreto, l'applicazione deve essere configurata con

  • Il nome del ruolo dell'app
  • Un token che consente di recuperare l'ID del ruolo dell'app e creare un nuovo identificatore segreto con quel ruolo
  • Il nome host / porta e del server Vault + certificati SSL

Quindi l'applicazione recupera l'id del ruolo e crea un nuovo ID segreto (modalità pull). Con questi due id l'applicazione può ora eseguire un login sul server Vault per recuperare il token finale che viene utilizzato per recuperare il segreto. Durante questo flusso potremmo anche avvolgere e scartare ogni risposta (avvolgimento di risposta cubbyhole impostando X-Vault-Wrap-TTL e usare sys/wrapping/unwrap endpoint da scartare.

Prima domanda: La modalità pull e / o il wrapping della risposta ha davvero senso qui? Non riesco a vedere il valore della creazione di un ID segreto solo per utilizzarlo in seguito per il login. Non riesco nemmeno a capire perché voglio avvolgere le mie risposte solo per scartarle.

Se quanto sopra è corretto, mi sembra che ogni persona / macchina che conosce il nome del ruolo e abbia un token per recuperare l'ID di ruolo e creare un segreto sia in grado di recuperare il segreto.

Seconda domanda: il nome del ruolo dell'app e il token iniziale nel mio file di configurazione non li rendono molto più sicuri perché tutti quelli che hanno accesso al server di Vault puoi solo leggere il segreto con quello. Sembra che abbia senso suddividere la configurazione: avere il nome del ruolo dell'app nel file di configurazione e nel token da qualche altra parte (in una variabile env, ecc.).

Terza domanda: l'ID app deprecato (basato su push) sembra avere più senso per me (perché) posso inserire l'ID app nel configfile e l'uso un ID utente specifico per macchina (come l'indirizzo mac, l'indirizzo IP, il nome host, ecc.) come secondo segreto. Quindi, perché la modalità pull dell'autenticazione AppRole è preferibile rispetto alla modalità push o all'ID app?

    
posta Mitchell Stevenson 16.04.2017 - 20:55
fonte

1 risposta

1

Se non si dispone già di un altro servizio autenticato in esecuzione (come uno schedulatore), non penso che ci sia molta differenza nella sicurezza tra la modalità push e pull. Se comprendo correttamente il flusso di lavoro, un utente malintenzionato dovrebbe avere il token nel file di configurazione e il nome di AppRole e rispettare le restrizioni impostate rispetto al ruolo (indirizzo IP, ecc.) Per accedere a tutti i segreti a cui l'applicazione avrebbe accesso (presumendo che i certificati SSL siano solo per verificare il server del vault e non per l'autenticazione ad esso).

  1. Il wrapping delle risposte è utile per garantire che l'ID segreto sia preso dall'app corretta e non venga rilevato da un utente malintenzionato. Se uno schedulatore avvia un'app e la risposta racchiude l'ID segreto per esso, l'app può inviare una sorta di avviso se non può leggerlo, perché significa che qualcun altro lo ha già letto (e potrebbe usarlo per autenticare) . Se l'app stessa sta richiamando direttamente l'ID segreto, non penso che il suo involucro avrebbe senso.

  2. Suddividere dove sono localizzati i componenti necessari per l'autenticazione è probabilmente una buona idea.

  3. Non credo che la modalità push o pull sia fondamentalmente più sicura dell'altro con il flusso di lavoro di autenticazione che stai descrivendo.

risposta data 10.08.2017 - 15:41
fonte

Leggi altre domande sui tag

Cosa c'era dietro l'aumento delle vulnerabilità / patch di Adobe Flash Player nel 2015? Qualcuno potrebbe spiegare parti dell'FBI Firefox 0-day?