Come state autenticando Discourse ad AWS? Aiutateci a migliorare le impostazioni!

[ducks]

Ciao a tutti,

Stiamo cercando di migliorare il modo in cui Discourse gestisce l’autenticazione AWS ^[1], e ci piacerebbe capire come è attualmente configurato prima di apportare qualsiasi modifica.

La Situazione Attuale

Al momento, ci sono alcuni modi per configurare l’autenticazione AWS in Discourse:

Opzione 1: Credenziali Esplicite (tramite impostazioni del sito)

• imposta s3_access_key_id e s3_secret_access_key nelle impostazioni del tuo sito
• l’autenticazione è per sito

Opzione 2: Credenziali Esplicite (tramite variabili d’ambiente)

• imposta le variabili d’ambiente:
  DISCOURSE_S3_ACCESS_KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY
• l’autenticazione è la stessa per tutti i siti in un cluster multisito

Opzione 3: Impostazione “Usa Profilo IAM”

• abilita l’impostazione del sito s3_use_iam_profile o imposta la variabile d’ambiente DISCOURSE_S3_USE_IAM_PROFILE=true
• dice a Discourse di lasciare che l’SDK AWS trovi automaticamente le credenziali
• originariamente progettato per istanze EC2 e per ottenere credenziali tramite IMDS, ma funziona anche in altri ambienti

Perché Vogliamo Cambiare

1. Nome Impostazione Confuso

Il nome dell’impostazione s3_use_iam_profile è fuorviante. Suggerisce che funzioni solo con i profili di istanza EC2, ma in realtà abilita qualsiasi sorgente di credenziali dell’SDK AWS:

• Profili di istanza EC2
• Ruoli di attività ECS
• Variabili d’ambiente
• File di credenziali AWS
• Assunzione di ruoli IAM
• E altro ancora…

2. Sicurezza: Chiavi Statiche vs. Assunzione di Ruoli

Sulla nostra piattaforma di hosting dedicata utilizziamo attualmente chiavi di accesso che vengono ruotate regolarmente. Stiamo puntando a passare all’assunzione di ruoli per un migliore isolamento, migliori opportunità di controllo degli accessi e per supportare un processo interno migliore.

Svantaggi dell’approccio attuale:

• le chiavi di accesso non scadono (fino alla rotazione)
• hanno ampi ambiti di autorizzazione
• possono essere compromesse se trapelano
• richiedono procedure di rotazione manuale

Vantaggi dell’utilizzo dell’assunzione di ruoli invece:

• le credenziali persistenti possono essere limitate tramite indirizzo IP
• le operazioni vengono eseguite utilizzando credenziali temporanee che scadono automaticamente (solitamente 1 ora)
• accesso just-in-time poiché le credenziali esistono solo quando necessarie
• raggio d’azione ridotto poiché le credenziali temporanee compromesse scadono rapidamente
• nessuna rotazione delle chiavi: il processo di assunzione dei ruoli gestisce l’aggiornamento
• migliori tracce di controllo: ogni sessione viene tracciata separatamente

Cosa Stiamo Considerando

Stiamo pensando di:

1. Rinominare l’impostazione in qualcosa di più chiaro come aws_credentials_from_environment
2. Rimuovere completamente l’impostazione e rilevare automaticamente quando le credenziali dovrebbero provenire dall’ambiente anziché dalle impostazioni del sito

Abbiamo Bisogno del Tuo Contributo!

Per favore, faccelo sapere:

1. Come ti autentichi con S3?

   • Chiavi di accesso esplicite nelle impostazioni del sito
   • Profilo di istanza EC2 (con s3_use_iam_profile abilitato)
   • Ruolo di attività ECS (con s3_use_iam_profile abilitato)
   • Variabili d’ambiente (con s3_use_iam_profile abilitato)
   • … qualcos’altro?

2. Se utilizzi s3_use_iam_profile:

   • In quale ambiente stai operando? (EC2, ECS, Docker, bare metal, ecc.)
   • Il nome/descrizione attuale ha causato confusione?
   • Un nome diverso sarebbe più chiaro?

3. Preoccupazioni riguardo alle modifiche a questa impostazione?

   • Preoccupato di interrompere la tua configurazione attuale?
   • Hai bisogno di tempo per testare le modifiche?
   • Altre considerazioni?

Perché È Importante

Una migliore autenticazione S3 significa:

• Più sicuro: nessuna chiave statica da gestire
• Configurazione più semplice: specialmente per le distribuzioni cloud
• Meno confusione: impostazioni e documentazione più chiare
• Miglior supporto per i moderni pattern di autenticazione AWS

Il tuo feedback ci aiuterà a apportare miglioramenti che funzionino per tutti. Grazie per aver dedicato del tempo a condividere la tua configurazione!

---

1. qui leggi: qualsiasi provider di storage di oggetti compatibile con S3 che stai utilizzando ↩︎

[Jagster (Jakke Lehtonen)]

Più facile rispondere in questo modo:

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

La mia è un’operazione un uomo, un amministratore. Quindi non ho bisogno di niente di complicato, ma la facilità ha un alto valore.

[nathank (Nathan Kershaw)]

Uso anche l’approccio ENV.
Il vantaggio principale è la resilienza / agilità: finché ho app.yml, posso rilanciare il mio sito su un nuovo server con il minimo sforzo.
Inoltre, questa è una cosa che si risolve una volta, quando si imposta un sito. O magari si esegue come un aggiornamento una tantum. Quindi si adatta bene a ENV.
Detto questo, è anche utile avere le impostazioni disponibili per la risoluzione dei problemi senza la necessità di ricostruire; una volta che le impostazioni sono stabili, possono quindi essere migrate nelle impostazioni ENV.

[RGJ (Richard - Communiteq)]

@ducks

quando le credenziali dovrebbero provenire dall’ambiente anziché dalle impostazioni del sito

Questa potrebbe sembrare una pignoleria, ma penso che ci siano alcune sfumature importanti qui.
Le opzioni che fornisci sono un misto di COME vengono passate le impostazioni e COSA impostazioni vengono passate.

Per quanto riguarda COME vengono passate le impostazioni, si applicano due cose:

1. il modo in cui le variabili d’ambiente vengono attualmente utilizzate
   Le variabili d’ambiente DISCOURSE_WHATEVER vengono attualmente utilizzate durante il processo di build di Docker per creare voci in discourse.conf che sono disponibili come GlobalSetting o SiteSetting da Discourse. Discourse non percepisce queste variabili d’ambiente come tali.

2. i limiti delle voci di discourse.conf
   Sebbene le GlobalSettings abbiano il piacevole vantaggio di poter sopprimere e sovrascrivere le SiteSettings, impongono anche il limite che negli ambienti multisito si applicano a tutti i siti del multisito.

Questi due combinati significano che da Discourse, SiteSetting è la più flessibile. Possono essere SiteSettings effettive, possono provenire da discourse.conf e tali voci possono provenire da variabili d’ambiente DISCOURSE_. Secondo me non c’è alcuna scelta effettiva lì, SiteSetting è la più flessibile e non ha svantaggi poiché è un superset funzionale. Puoi usare GlobalSettings invece e quelle possono essere popolate tramite variabili d’ambiente.

Ciò implica che l’unica scelta effettiva è se utilizzare o meno il rilevamento automatico delle credenziali. Nella mia percezione personale, il rilevamento automatico è sempre molto incline agli errori, quindi preferirei avere qualcosa di esplicito.

Cioè, avere una SiteSetting che in qualche modo punta a credenziali effettive e concrete.