En nuestra configuración, ejecutamos Discourse en un clúster AWS EKS y esperamos usar un Bucket S3 en la misma cuenta de AWS para el almacenamiento de medios. Al pod EKS que ejecuta Discourse se le proporciona la Cuenta de Servicio de Kubernetes y el Rol IAM. Al Bucket S3 se le ha bloqueado todo acceso público, con una ACL que otorga solo al propietario del Bucket (cuenta de AWS) acceso de lectura/escritura.
Con la Configuración del Sitio de Discourse de “activar subidas a S3”, “usar perfil IAM de S3” y “subidas de medios seguras” activadas, podemos usar nuestra configuración para subir medios a Temas de Discourse. Sin embargo, debido a las comprobaciones en el módulo UploadCreator, cualquier subida relacionada con la Configuración del Sitio, por ejemplo, el logo, etc., falla ya que intenta subir los medios con el parámetro private_acl de la API S3 establecido en “false”. ¿No tendría sentido que, una vez activado “subidas de medios seguras”, todo el contenido se suba con private_acl establecido en true?
Incluso en una instancia completamente privada, las cargas de configuración como el logotipo y el favicon se presentan en la página de inicio de sesión y se consideran públicas. Estas también son descargadas frecuentemente por herramientas que no se autentican, como sitios web que realizan incrustaciones de OpenGraph, instalaciones de PWA, resultados de Google, etc.
En ese caso, ¿tendría más sentido que esto dependiera de que la opción «usar perfil IAM de s3» esté habilitada o no? Si se habilita el uso del perfil IAM, entonces estamos confirmando de alguna manera que el bucket no tiene acceso público y, por lo tanto, necesitará ser accedido con una ACL privada. Puedo estar equivocado, pero no veo ninguna razón por la que uno usaría esta configuración en Discourse, a menos que no pueda hacer que su bucket sea público.
Suficiente. Entonces, supongo que la única solución para nosotros sería tener otra bandera de configuración para especificar que el ACL del bucket s3 es privado, ¿o esto suena ilógico?
Eso abordaría sus necesidades, pero no es algo que planeemos hacer en nuestra hoja de ruta, ya que tener buckets públicos con la lista de archivos deshabilitada y los archivos reales con ACLs privadas individuales está funcionando bien para nosotros hasta ahora.
¿Por qué no es posible un bucket público con archivos privados para su caso de uso?
Bueno, esta es una decisión a nivel corporativo en nuestro caso. Todos los activos, incluido el Bucket, deben ser privados y ser accesibles mediante roles de IAM. Para entregar los objetos del Bucket al frontend de Discourse, hemos creado una aplicación S3 Proxy que se ejecuta en el mismo clúster EKS y la hemos configurado como una CDN en la configuración de Discourse. Ahora, todo lo que queda es la capacidad de cargar activos de Configuración del sitio como el logo, etc., como privados, para lo cual necesitamos esta bandera. Por defecto, Discourse intenta cargar dichos activos como públicos, lo que me gustaría anular con esta nueva bandera.
Usamos la excelente función de subidas seguras para nuestra instancia de Discourse, funciona bien, pero sería genial si hubiera soporte para bloquear todo acceso público al bucket.
Recientemente, he estado intentando resolver todos los problemas de ‘AWS Foundational Security Best Practices’ planteados por AWS Security Hub. Uno de ellos es que ‘los buckets de propósito general de S3 deben bloquear el acceso público’.
Imagino que bastantes empresas están pasando por el mismo proceso de intentar aplicar las ‘AWS Foundational Security Best Practices’ y se encuentran con este problema.
No espero que esto sea priorizado en un futuro próximo, pero encontré este hilo y pensé en añadir un +1.