Como você está autenticando o Discourse com a AWS? Ajude-nos a melhorar as configurações!

[ducks]

Olá a todos,

Estamos pensando em melhorar como o Discourse lida com a autenticação AWS ^[1], e gostaríamos de entender como vocês estão configurados atualmente antes de fazer qualquer alteração.

A Situação Atual

Atualmente, existem algumas maneiras de configurar a autenticação AWS no Discourse:

Opção 1: Credenciais Explícitas (via configurações do site)

• Defina s3_access_key_id e s3_secret_access_key nas configurações do seu site
• A autenticação é por site

Opção 2: Credenciais Explícitas (via variáveis de ambiente)

• Defina as variáveis de ambiente:
  DISCOURSE_S3_ACCESS_KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY
• A autenticação é a mesma para todos os sites em um cluster multissite

Opção 3: Configuração “Usar Perfil IAM”

• Ative a configuração do site s3_use_iam_profile ou defina a variável de ambiente DISCOURSE_S3_USE_IAM_PROFILE=true
• Isso informa ao Discourse para deixar o SDK da AWS encontrar as credenciais automaticamente
• Originalmente projetado para instâncias EC2 e para obter credenciais via IMDS, mas funciona em outros ambientes

Por que queremos mudar

1. Nome da Configuração Confuso

A configuração s3_use_iam_profile tem um nome enganoso. Sugere que funciona apenas com perfis de instância EC2, mas na verdade ativa qualquer fonte de credenciais do SDK da AWS:

• Perfis de instância EC2
• Funções de tarefa ECS
• Variáveis de ambiente
• Arquivos de credenciais da AWS
• Assunção de função IAM
• E mais…

2. Segurança: Chaves Estáticas vs. Assunção de Função

Em nossa plataforma de hospedagem dedicada, atualmente usamos chaves de acesso que são rotacionadas regularmente. Nosso objetivo é mudar para a assunção de função para melhor isolamento, melhores oportunidades de controle de acesso e para apoiar um processo interno melhor.

Desvantagens da abordagem atual:

• As chaves de acesso não expiram (até serem rotacionadas)
• Têm escopos de permissão amplos
• Podem ser comprometidas se vazadas
• Requerem procedimentos manuais de rotação

Vantagens de usar assunção de função em vez disso:

• Credenciais persistentes podem ser restritas por endereço IP
• As operações são feitas usando credenciais temporárias que expiram automaticamente (geralmente em 1 hora)
• Acesso just-in-time, pois as credenciais só existem quando necessárias
• Raio de explosão reduzido, pois credenciais temporárias comprometidas expiram rapidamente
• Sem rotação de chaves - o processo de assunção de função lida com a atualização
• Melhores trilhas de auditoria - cada sessão é rastreada separadamente

O que estamos considerando

Estamos pensando em:

1. Renomear a configuração para algo mais claro, como aws_credentials_from_environment
2. Remover a configuração completamente e detectar automaticamente quando as credenciais devem vir do ambiente em vez das configurações do site

Precisamos da sua opinião!

Por favor, nos diga:

1. Como você se autentica com o S3?

   • Chaves de acesso explícitas nas configurações do site
   • Perfil de instância EC2 (com s3_use_iam_profile ativado)
   • Função de tarefa ECS (com s3_use_iam_profile ativado)
   • Variáveis de ambiente (com s3_use_iam_profile ativado)
   • … algo mais?

2. Se você usa s3_use_iam_profile:

   • Em qual ambiente você está executando? (EC2, ECS, Docker, bare metal, etc.)
   • O nome/descrição atual causou alguma confusão?
   • Um nome diferente seria mais claro?

3. Alguma preocupação sobre alterações nesta configuração?

   • Preocupado em quebrar sua configuração atual?
   • Precisa de tempo para testar as alterações?
   • Outras considerações?

Por que isso importa

Uma melhor autenticação S3 significa:

• Mais seguro - sem chaves estáticas para gerenciar
• Configuração mais fácil - especialmente para implantações na nuvem
• Menos confusão - configurações e documentação mais claras
• Melhor suporte para padrões modernos de autenticação AWS

Seu feedback nos ajudará a fazer melhorias que funcionem para todos. Obrigado por dedicar seu tempo para compartilhar sua configuração!

---

1. aqui leia: qualquer provedor de armazenamento de objetos compatível com S3 que você esteja usando ↩︎

[Jagster (Jakke Lehtonen)]

Mais fácil de responder desta forma:

DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: eu-north-1
  DISCOURSE_S3_ACCESS_KEY_ID: <algo>
  DISCOURSE_S3_SECRET_ACCESS_KEY: <algo>
  DISCOURSE_S3_CDN_URL: https://cdnfoorumi.katiska.eu
  DISCOURSE_S3_BUCKET: <algo>
  DISCOURSE_S3_BACKUP_BUCKET: <algo>
  DISCOURSE_BACKUP_LOCATION: s3
  S3_ORIGIN_ASSETS: https://foorumi.katiska.eu

A minha é uma operação de um homem, um administrador. Portanto, não preciso de nada sofisticado, mas a facilidade tem um alto valor.

[nathank (Nathan Kershaw)]

Eu também uso a abordagem ENV.
A principal vantagem é a resiliência / agilidade - desde que eu tenha o app.yml, posso relançar meu site em um novo servidor com o mínimo de aborrecimento.
Além disso, isso tende a ser algo que você resolve uma vez, quando estabelece um site. Ou talvez realize como uma atualização única. Portanto, combina bem com ENV.
Dito isso, também é útil ter as configurações disponíveis para solução de problemas sem a necessidade de reconstruir; uma vez que as configurações estejam estáveis, elas podem ser migradas para as configurações de ENV.

[RGJ (Richard - Communiteq)]

@ducks

quando as credenciais devem vir do ambiente vs. configurações do site

Isso pode parecer detalhismo, mas acho que há algumas nuances importantes aqui.
As opções que você fornece são uma mistura de COMO as configurações estão sendo passadas e QUAIS configurações estão sendo passadas.

Com relação a COMO as configurações estão sendo passadas, duas coisas se aplicam:

1. a forma como as variáveis de ambiente estão sendo usadas atualmente
   As variáveis de ambiente DISCOURSE_WHATEVER são atualmente usadas durante o processo de build do Docker para criar entradas em discourse.conf que estão disponíveis como GlobalSetting ou SiteSetting de dentro do Discourse. O Discourse não percebe essas variáveis de ambiente como tal.

2. as limitações das entradas de discourse.conf
   Embora as GlobalSettings tenham o recurso interessante de poderem suprimir e substituir as SiteSettings, elas também impõem a limitação de que em ambientes multisite elas se aplicam a todos os sites no multisite.

Esses dois combinados significam que, de dentro do Discourse, SiteSetting é o mais flexível. Elas podem ser SiteSettings reais, podem vir de discourse.conf e essas entradas podem vir de variáveis de ambiente DISCOURSE_. Na minha opinião, não há escolha real aí, SiteSetting é o mais flexível e não tem desvantagens, pois são um superconjunto funcional. Você pode usar GlobalSettings em vez disso e elas podem ser preenchidas usando variáveis de ambiente.

Isso implica que a única escolha real é se deve usar a descoberta automática de credenciais ou não. Na minha percepção pessoal, a descoberta automática é sempre muito propensa a erros, então eu preferiria ter algo explícito.

Ou seja, ter uma SiteSetting que de alguma forma aponte para credenciais reais e concretas.