Comment authentifiez-vous Discourse auprès d'AWS ? Aidez-nous à améliorer les paramètres !

[ducks]

Salut à tous,

Nous cherchons à améliorer la façon dont Discourse gère l’authentification AWS ^[1], et nous aimerions comprendre comment vous êtes actuellement configurés avant d’apporter des modifications.

La situation actuelle

Actuellement, il existe plusieurs façons de configurer l’authentification AWS dans Discourse :

Option 1 : Identifiants explicites (via les paramètres du site)

• définir s3_access_key_id et s3_secret_access_key dans les paramètres de votre site
• l’authentification est par site

Option 2 : Identifiants explicites (via les variables d’environnement)

• définir les variables d’environnement :
  DISCOURSE_S3_ACCESS_KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY
• l’authentification est la même pour tous les sites d’un cluster multisite

Option 3 : Paramètre « Utiliser le profil IAM »

• activer le paramètre de site s3_use_iam_profile ou définir la variable d’environnement DISCOURSE_S3_USE_IAM_PROFILE=true
• indique à Discourse de laisser le SDK AWS trouver les identifiants automatiquement
• initialement conçu pour les instances EC2 et l’obtention d’identifiants via IMDS, mais fonctionne dans d’autres environnements

Pourquoi nous voulons changer

1. Nom de paramètre confus

Le paramètre s3_use_iam_profile a un nom trompeur. Il suggère qu’il ne fonctionne qu’avec les profils d’instance EC2, mais il active en fait toute source d’identifiants du SDK AWS source d’identifiants :

• profils d’instance EC2
• rôles de tâche ECS
• variables d’environnement
• fichiers d’identifiants AWS
• prise en charge de rôles IAM
• et plus encore…

2. Sécurité : Clés statiques vs. Prise en charge de rôles

Sur notre plateforme d’hébergement dédiée, nous utilisons actuellement des clés d’accès qui sont régulièrement mises à jour. Nous visons à passer à la prise en charge de rôles pour une meilleure isolation, de meilleures opportunités de contrôle d’accès et pour soutenir un meilleur processus interne.

Inconvénients de l’approche actuelle :

• les clés d’accès n’expirent pas (jusqu’à leur rotation)
• ont des portées d’autorisation larges
• peuvent être compromises si divulguées
• nécessitent des procédures de rotation manuelles

Avantages de l’utilisation de la prise en charge de rôles à la place :

• les identifiants persistants peuvent être restreints par adresse IP
• les opérations sont effectuées à l’aide d’identifiants temporaires qui expirent automatiquement (généralement 1 heure)
• accès juste-à-temps car les identifiants n’existent que lorsque nécessaire
• rayon d’explosion réduit car les identifiants temporaires compromis expirent rapidement
• pas de rotation de clés - le processus de prise en charge de rôles gère le rafraîchissement
• meilleures pistes d’audit - chaque session est suivie séparément

Ce que nous envisageons

Nous pensons soit à :

1. Renommer le paramètre en quelque chose de plus clair comme aws_credentials_from_environment
2. Supprimer complètement le paramètre et détecter automatiquement quand les identifiants doivent provenir de l’environnement par rapport aux paramètres du site

Nous avons besoin de votre avis !

Merci de nous faire savoir :

1. Comment vous authentifiez-vous auprès de S3 ?

   • Clés d’accès explicites dans les paramètres du site
   • Profil d’instance EC2 (avec s3_use_iam_profile activé)
   • Rôle de tâche ECS (avec s3_use_iam_profile activé)
   • Variables d’environnement (avec s3_use_iam_profile activé)
   • … autre chose ?

2. Si vous utilisez s3_use_iam_profile :

   • Dans quel environnement exécutez-vous ? (EC2, ECS, Docker, bare metal, etc.)
   • Le nom/la description actuel(le) a-t-il causé une confusion ?
   • Un nom différent serait-il plus clair ?

3. Des préoccupations concernant les changements de ce paramètre ?

   • Vous craignez de casser votre configuration actuelle ?
   • Besoin de temps pour tester les changements ?
   • Autres considérations ?

Pourquoi c’est important

Une meilleure authentification S3 signifie :

• Plus sécurisé - pas de clés statiques à gérer
• Configuration plus facile - surtout pour les déploiements cloud
• Moins de confusion - paramètres et documentation plus clairs
• Meilleur support pour les modèles d’authentification AWS modernes

Vos commentaires nous aideront à apporter des améliorations qui conviennent à tous. Merci de prendre le temps de partager votre configuration !

---

1. ici lire : tout fournisseur de stockage d’objets compatible S3 que vous utilisez ↩︎

[Jagster (Jakke Lehtonen)]

Plus facile de répondre ainsi :

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

Le mien est une opération un homme, un administrateur. Donc, je n’ai pas besoin de quelque chose de sophistiqué, mais la facilité a une grande valeur.

[nathank (Nathan Kershaw)]

J’utilise également l’approche ENV.
Le principal avantage est la résilience / l’agilité - tant que j’ai le fichier app.yml, je peux relancer mon site sur un nouveau serveur avec un minimum de tracas.
De plus, c’est généralement quelque chose que l’on règle une fois, lors de la création d’un site. Ou peut-être que l’on effectue une mise à niveau unique. Cela convient donc bien à l’approche ENV.
Cela dit, il est également utile d’avoir les paramètres disponibles pour le dépannage sans avoir à reconstruire ; une fois les paramètres stables, ils peuvent ensuite être migrés vers les paramètres ENV.

[RGJ (Richard - Communiteq)]

@ducks

quand les informations d’identification doivent provenir de l’environnement par rapport aux paramètres du site

Cela peut sembler une question de détail, mais je pense qu’il y a des nuances importantes ici.
Les options que vous proposez sont un mélange de la manière dont les paramètres sont transmis et de ce qui est transmis.

En ce qui concerne la manière dont les paramètres sont transmis, deux choses s’appliquent :

1. la façon dont les variables d’environnement sont actuellement utilisées
   Les variables d’environnement DISCOURSE_WHATEVER sont actuellement utilisées pendant le processus de construction de Docker pour créer des entrées dans discourse.conf qui sont disponibles en tant que GlobalSetting ou SiteSetting à partir de Discourse. Discourse ne perçoit pas ces variables d’environnement comme telles.

2. les limitations des entrées de discourse.conf
   Bien que les GlobalSettings aient l’avantage de pouvoir supprimer et remplacer les SiteSettings, elles imposent également la limitation que dans les environnements multisites, elles s’appliquent à tous les sites du multisite.

Ces deux éléments combinés signifient que, du point de vue de Discourse, SiteSetting est le plus flexible. Il peut s’agir de SiteSettings réels, ils peuvent provenir de discourse.conf et ces entrées peuvent provenir de variables d’environnement DISCOURSE_. À mon avis, il n’y a pas de choix réel là-bas, SiteSetting est le plus flexible et n’a pas d’inconvénients puisqu’il s’agit d’un sur-ensemble fonctionnel. Vous pouvez utiliser GlobalSettings à la place et ceux-ci peuvent être remplis à l’aide de variables d’environnement.

Cela implique que le seul choix réel est d’utiliser ou non la découverte automatique des informations d’identification. Dans ma perception personnelle, la découverte automatique est toujours très sujette aux erreurs, je préférerais donc avoir quelque chose d’explicite.

C’est-à-dire avoir un SiteSetting qui pointe d’une manière ou d’une autre vers des informations d’identification réelles et concrètes.