Nel nostro setup stiamo eseguendo Discourse in un cluster AWS EKS e ci aspettiamo di utilizzare un bucket S3 nello stesso account AWS per l’archiviazione dei media. Il pod EKS che esegue Discourse è dotato del Service Account Kubernetes e del Ruolo IAM. Il bucket S3 ha tutto l’accesso pubblico bloccato, con un ACL che concede solo al proprietario del bucket (account AWS) l’accesso in lettura/scrittura.
Con le impostazioni del sito di Discourse “enabled s3 uploads”, “s3 use iam profile” e “secure media uploads” abilitate, siamo in grado di utilizzare il nostro setup per caricare media negli argomenti di Discourse. Tuttavia, a causa dei controlli nel modulo UploadCreator, tutti i caricamenti relativi alle impostazioni del sito, ad esempio il logo, ecc., falliscono poiché tentano di caricare i media con il parametro S3 API private_acl impostato su “false”. Non avrebbe senso che, una volta abilitato “secure media uploads”, tutto il contenuto venga caricato con private_acl impostato su true?
Anche in un’istanza completamente privata, caricamenti di impostazioni come Logo e Favicon vengono presentati nella pagina di accesso e sono considerati pubblici. Questi vengono anche scaricati frequentemente da strumenti che non si autenticano, come siti Web che eseguono embedding OpenGraph, installazioni PWA, risultati di Google, ecc.
In tal caso, avrebbe più senso renderlo dipendente dall’abilitazione o meno dell’opzione “s3 use iam profile”? Se l’uso del profilo IAM è abilitato, stiamo in un certo senso confermando che il bucket non ha accesso pubblico e, quindi, dovrà essere accessibile con un ACL privato. Potrei sbagliarmi, ma non vedo alcun motivo per cui si dovrebbe utilizzare questa impostazione in Discourse, a meno che non si possa rendere pubblico il proprio bucket.
Questo sito utilizza s3 use iam profile e ha anche un bucket pubblico. Non c’è alcuna correlazione tra i due.
s3 use iam profile significa solo “Non voglio passare una coppia chiave/segreto, vai avanti e ottienila automaticamente per me dall’API interna di AWS”.
Abbastanza giusto. Allora immagino che l’unica soluzione per noi sarebbe avere un altro flag di impostazione per specificare che l’ACL del bucket s3 sia privato, o questo suona illogico?
Ciò risponderebbe alle tue esigenze, ma non è qualcosa che prevediamo di fare nella nostra roadmap, poiché avere bucket pubblici con l’elenco dei file disabilitato e i file effettivi con ACL privati individuali sta funzionando bene per noi finora.
Perché il bucket pubblico con file privati non è possibile per il tuo caso d’uso?
Beh, questa è una decisione a livello aziendale nel nostro caso. Tutte le risorse, incluso il Bucket, dovrebbero essere private e rese accessibili dai ruoli IAM. Per fornire gli oggetti del Bucket al frontend di Discourse, abbiamo creato un’applicazione S3 Proxy in esecuzione nello stesso cluster EKS e l’abbiamo configurata come CDN nelle impostazioni di Discourse. Ora tutto ciò che rimane è la possibilità di caricare asset delle impostazioni del sito come logo, ecc. come privati, per i quali abbiamo bisogno di questo flag. Per impostazione predefinita, Discourse tenta di caricare tali asset come pubblici, cosa che vorrei sovrascrivere con questo nuovo flag.
Utilizziamo l’eccellente funzionalità di caricamenti sicuri per la nostra istanza Discourse, funziona bene ma sarebbe fantastico se ci fosse il supporto per bloccare tutto l’accesso pubblico al bucket.
Recentemente ho cercato di risolvere tutti i problemi di “AWS Foundational Security Best Practices” sollevati da AWS Security Hub. Uno di questi è che “i bucket generici S3 dovrebbero bloccare l’accesso pubblico”.
Immagino che parecchie aziende stiano attraversando lo stesso processo di tentativo di applicare le “AWS Foundational Security Best Practices” e si stiano imbattendo in questo problema.
Non mi aspetto che venga dato priorità a breve termine, ma ho trovato questa discussione e ho pensato di aggiungere un +1.