Dans notre configuration, nous exécutons Discourse dans un cluster AWS EKS et prévoyons d’utiliser un compartiment S3 dans le même compte AWS pour le stockage des médias. Le pod EKS exécutant Discourse est fourni avec le compte de service Kubernetes et le rôle IAM. Le compartiment S3 a tout accès public bloqué, avec une ACL accordant uniquement au propriétaire du compartiment (compte AWS) un accès en lecture/écriture.
Avec les paramètres du site Discourse « activer les téléchargements S3 », « utiliser le profil IAM S3 » et « sécuriser les téléchargements de médias » activés, nous sommes en mesure d’utiliser notre configuration pour télécharger des médias vers les sujets Discourse. Cependant, en raison des vérifications dans le module UploadCreator, tous les téléchargements liés aux paramètres du site, par exemple le logo, etc., échouent car ils tentent de télécharger les médias avec le paramètre private_acl de l’API S3 défini sur « false ». Ne serait-il pas logique que lorsque « sécuriser les téléchargements de médias » est activé, tout le contenu soit téléchargé avec private_acl défini sur « true » ?
Même dans une instance complètement privée, les téléchargements de paramètres tels que le logo et le favicon sont présentés sur la page de connexion et sont considérés comme publics. Ceux-ci sont également fréquemment téléchargés par des outils qui n’authentifient pas, tels que les sites Web qui intègrent OpenGraph, les installations PWA, les résultats Google, etc.
Dans ce cas, serait-il plus judicieux de rendre cela dépendant de l’activation ou non du drapeau « utilisation du profil IAM pour S3 » ? Si l’utilisation du profil IAM est activée, nous confirmons en quelque sorte que le compartiment n’a pas d’accès public et devra donc être accédé avec un ACL privé. Je pourrais me tromper, mais je ne vois aucune raison pour laquelle on utiliserait ce paramètre dans Discourse, à moins qu’ils ne puissent rendre leur compartiment public.
Ce site utilise s3 use iam profile et possède également un compartiment public. Il n’y a aucune corrélation entre les deux.
s3 use iam profile signifie simplement « Je ne veux pas passer une paire clé/secret, allez-y et obtenez-la automatiquement pour moi à partir de l’API interne d’AWS ».
Soit. Alors je suppose que la seule solution pour nous serait d’avoir un autre indicateur de réglage pour spécifier que l’ACL du compartiment s3 est privée, ou cela semble-t-il illogique ?
Cela répondrait à vos besoins, mais ce n’est pas quelque chose que nous prévoyons de faire dans notre feuille de route, car avoir des buckets publics avec la liste des fichiers désactivée et les fichiers réels ayant des ACL privées individuelles fonctionne bien pour nous jusqu’à présent.
Pourquoi un bucket public avec des fichiers privés n’est-il pas possible pour votre cas d’utilisation ?
Eh bien, c’est une décision de niveau entreprise dans notre cas. Tous les actifs, y compris le Bucket, sont censés être privés et doivent être accessibles par des rôles IAM. Pour livrer les objets du Bucket au frontend Discourse, nous avons construit une application S3 Proxy fonctionnant dans le même cluster EKS, et l’avons configurée comme un CDN dans les paramètres Discourse. Il ne reste plus qu’à pouvoir télécharger les actifs des paramètres du site comme le logo, etc., en privé, pour lesquels nous avons besoin de ce drapeau. Par défaut, Discourse essaie de télécharger de tels actifs comme publics, ce que j’aimerais remplacer par ce nouveau drapeau.
Nous utilisons l’excellente fonctionnalité de téléchargements sécurisés pour notre instance Discourse. Elle fonctionne bien, mais il serait formidable de pouvoir bloquer tout accès public au bucket.
Récemment, j’ai essayé de résoudre tous les problèmes de « Bonnes pratiques fondamentales de sécurité AWS » soulevés par AWS Security Hub. L’un d’eux est que « les buckets à usage général S3 doivent bloquer l’accès public ».
J’imagine que pas mal d’entreprises sont en train de suivre le même processus pour appliquer les « Bonnes pratiques fondamentales de sécurité AWS » et rencontrent ce problème.
Je ne m’attends pas à ce que ce soit une priorité de sitôt, mais j’ai trouvé ce fil de discussion et j’ai pensé y ajouter un +1.