Em nossa configuração, estamos executando o Discourse em um cluster AWS EKS e esperamos usar um Bucket S3 na mesma conta AWS para armazenamento de mídia. O pod EKS executando o Discourse é fornecido com a Conta de Serviço do Kubernetes e a Função IAM. O Bucket S3 tem todo o acesso público bloqueado, com uma ACL concedendo apenas ao proprietário do Bucket (conta AWS) acesso de leitura/gravação.
Com as Configurações do Site do Discourse de "habilitar uploads s3", "usar perfil iam s3" e "proteger uploads de mídia" habilitadas, conseguimos usar nossa configuração para fazer upload de mídia para Tópicos do Discourse. No entanto, devido às verificações no módulo UploadCreator, quaisquer uploads relacionados às Configurações do Site, por exemplo, logotipo, etc., estão falhando, pois tentam fazer o upload da mídia com o parâmetro private_acl da API S3 definido como "false". Não faria sentido que, com "proteger uploads de mídia" habilitado, todo o conteúdo fosse carregado com private_acl definido como true?
Mesmo em uma instância completamente privada, uploads de configurações como Logo e Favicon são apresentados na página de login e são considerados públicos. Estes também são frequentemente baixados por ferramentas que não autenticam, como sites que fazem embeds OpenGraph, instalações PWA, resultados do Google, etc.
Nesse caso, faria mais sentido tornar isso dependente da flag “s3 use iam profile” estar habilitada ou não? Se o uso do perfil IAM estiver habilitado, então estamos meio que confirmando que o bucket não tem acesso público e, portanto, precisará ser acessado com uma ACL privada. Posso estar enganado, mas não vejo motivo para usar essa configuração no Discourse, a menos que não se possa tornar o bucket público.
Este site aqui usa s3 use iam profile e também tem um bucket público. Não há correlação entre um e outro.
s3 use iam profile significa apenas “Não quero passar um par de chave/segredo, vá em frente e obtenha isso automaticamente para mim da API interna da AWS”.
Justo. Então, acho que a única solução para nós seria ter outra flag de configuração para especificar que o ACL do bucket s3 é privado, ou isso soa ilógico?
Isso atenderia às suas necessidades, mas não é algo que planejamos fazer em nosso roteiro, pois ter buckets públicos com listagem de arquivos desativada e os arquivos reais com ACLs privadas individuais tem funcionado bem para nós até agora.
Por que um bucket público com arquivos privados não é possível para o seu caso de uso?
Bem, esta é uma decisão em nível corporativo em nosso caso. Todos os ativos, incluindo o Bucket, devem ser privados e acessíveis por meio de funções IAM. Para entregar os objetos do Bucket ao frontend do Discourse, criamos um aplicativo S3 Proxy rodando no mesmo cluster EKS e o configuramos como uma CDN nas configurações do Discourse. Agora, tudo o que resta é a capacidade de fazer upload de ativos de Configurações do Site, como logotipo, etc., como privados, para os quais precisamos dessa flag. Por padrão, o Discourse tenta fazer o upload de tais ativos como públicos, o que eu gostaria de substituir com esta nova flag.
Usamos o excelente recurso de uploads seguros para nossa instância do Discourse, está funcionando bem, mas seria ótimo se houvesse suporte para bloquear todo o acesso público ao bucket.
Recentemente, tenho tentado resolver todos os problemas de ‘AWS Foundational Security Best Practices’ levantados pelo AWS Security Hub. Um deles é que ‘baldes de propósito geral S3 devem bloquear acesso público’.
Imagino que muitas empresas estejam passando pelo mesmo processo de tentar aplicar as ‘AWS Foundational Security Best Practices’ e encontrando esse problema.
Não espero que isso seja priorizado tão cedo, mas encontrei este tópico e pensei em adicionar um +1 a ele.