¿Cómo autenticas Discourse con AWS? ¡Ayúdanos a mejorar la configuración!

[ducks]

Hola a todos,

Estamos pensando en mejorar la forma en que Discourse maneja la autenticación de AWS ^[1], y nos gustaría entender cómo está configurado actualmente antes de realizar cualquier cambio.

La Situación Actual

En este momento, hay algunas formas de configurar la autenticación de AWS en Discourse:

Opción 1: Credenciales Explícitas (a través de la configuración del sitio)

• configure s3_access_key_id y s3_secret_access_key en la configuración de su sitio
• la autenticación es por sitio

Opción 2: Credenciales Explícitas (a través de variables de entorno)

• configure las variables de entorno:
  DISCOURSE_S3_ACCESS_KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY
• la autenticación es la misma para todos los sitios en un clúster multisitio

Opción 3: Configuración “Usar Perfil IAM”

• habilite la configuración del sitio s3_use_iam_profile o configure la variable de entorno DISCOURSE_S3_USE_IAM_PROFILE=true
• le dice a Discourse que deje que el SDK de AWS encuentre las credenciales automáticamente
• originalmente diseñado para instancias EC2 y para obtener credenciales a través de IMDS, pero funciona en otros entornos

Por Qué Queremos Cambiar

1. Nombre de Configuración Confuso

El nombre de la configuración s3_use_iam_profile es engañoso. Sugiere que solo funciona con perfiles de instancia EC2, pero en realidad habilita cualquier fuente de credenciales del SDK de AWS:

• Perfiles de instancia EC2
• Roles de tarea ECS
• Variables de entorno
• Archivos de credenciales de AWS
• Asunción de roles IAM
• Y más…

2. Seguridad: Claves Estáticas vs. Asunción de Roles

En nuestra plataforma de alojamiento dedicada, actualmente usamos claves de acceso que se rotan regularmente. Nuestro objetivo es cambiar a la asunción de roles para un mejor aislamiento, mejores oportunidades de control de acceso y para respaldar un mejor proceso interno.

Desventajas del enfoque actual:

• las claves de acceso no caducan (hasta que se rotan)
• tienen amplios ámbitos de permisos
• pueden ser comprometidas si se filtran
• requieren procedimientos de rotación manual

Ventajas de usar la asunción de roles en su lugar:

• las credenciales persistentes se pueden restringir por dirección IP
• las operaciones se realizan utilizando credenciales temporales que caducan automáticamente (generalmente 1 hora)
• acceso justo a tiempo, ya que las credenciales solo existen cuando son necesarias
• radio de explosión reducido, ya que las credenciales temporales comprometidas caducan rápidamente
• sin rotación de claves: el proceso de asunción de roles se encarga de la actualización
• mejores pistas de auditoría: cada sesión se rastrea por separado

Lo Que Estamos Considerando

Estamos pensando en:

1. Renombrar la configuración a algo más claro como aws_credentials_from_environment
2. Eliminar la configuración por completo y detectar automáticamente cuándo las credenciales deben provenir del entorno en lugar de la configuración del sitio

¡Necesitamos Tu Opinión!

Por favor, háganos saber:

1. ¿Cómo se autentica con S3?

   • Claves de acceso explícitas en la configuración del sitio
   • Perfil de instancia EC2 (con s3_use_iam_profile habilitado)
   • Rol de tarea ECS (con s3_use_iam_profile habilitado)
   • Variables de entorno (con s3_use_iam_profile habilitado)
   • … ¿algo más?

2. Si usa s3_use_iam_profile:

   • ¿En qué entorno se está ejecutando? (EC2, ECS, Docker, bare metal, etc.)
   • ¿El nombre/descripción actual causó alguna confusión?
   • ¿Sería más claro un nombre diferente?

3. ¿Alguna preocupación sobre los cambios en esta configuración?

   • ¿Le preocupa que se rompa su configuración actual?
   • ¿Necesita tiempo para probar los cambios?
   • ¿Otras consideraciones?

Por Qué Esto Importa

Una mejor autenticación de S3 significa:

• Más seguro: sin claves estáticas que administrar
• Configuración más fácil: especialmente para implementaciones en la nube
• Menos confusión: configuraciones y documentación más claras
• Mejor soporte para patrones modernos de autenticación de AWS

Sus comentarios nos ayudarán a realizar mejoras que funcionen para todos. ¡Gracias por tomarse el tiempo de compartir su configuración!

---

1. aquí se lee: cualquier proveedor de almacenamiento de objetos compatible con S3 que esté utilizando ↩︎

[Jagster (Jakke Lehtonen)]

Más fácil de responder de esta manera:

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

La mía es una operación de un hombre, un administrador. Así que no necesito nada sofisticado, pero la facilidad tiene un alto valor.

[nathank (Nathan Kershaw)]

También utilizo el enfoque ENV.
La principal ventaja es la resiliencia/agilidad: mientras tenga el app.yml, puedo relanzar mi sitio en un nuevo servidor con un mínimo de complicaciones.
Además, esto tiende a ser algo que se soluciona una vez, cuando se establece un sitio. O tal vez se realiza como una actualización única. Por lo tanto, se adapta bien a ENV.
Dicho esto, también es útil tener la configuración disponible para la resolución de problemas sin necesidad de reconstruir; una vez que la configuración sea estable, se puede migrar a la configuración de ENV.

[RGJ (Richard - Communiteq)]

@ducks

cuándo las credenciales deben provenir del entorno frente a la configuración del sitio

Esto puede sonar quisquilloso, pero creo que hay algunos matices importantes aquí.
Las opciones que proporciona son una mezcla de CÓMO se pasan la configuración y QUÉ configuración se pasa.

Con respecto a CÓMO se pasan la configuración, se aplican dos cosas:

1. la forma en que se utilizan actualmente las variables de entorno
   Las variables de entorno DISCOURSE_WHATEVER se utilizan actualmente durante el proceso de compilación de Docker para crear entradas en discourse.conf que están disponibles como GlobalSetting o SiteSetting dentro de Discourse. Discourse no percibe estas variables de entorno como tales.

2. las limitaciones de las entradas de discourse.conf
   Aunque GlobalSettings tiene la ventaja de poder suprimir y anular SiteSettings, también imponen la limitación de que en entornos multisitio se aplican a todos los sitios del multisitio.

Estas dos combinadas significan que, desde dentro de Discourse, SiteSetting es lo más flexible. Pueden ser SiteSettings reales, pueden provenir de discourse.conf y esas entradas pueden provenir de variables de entorno DISCOURSE_. En mi opinión, no hay una opción real allí, SiteSetting es lo más flexible y no tiene desventajas, ya que son un superconjunto funcional. Puede usar GlobalSettings en su lugar y estas pueden completarse utilizando variables de entorno.

Eso implica que la única opción real es si se utiliza o no el descubrimiento automático de credenciales. En mi percepción personal, el descubrimiento automático es siempre muy propenso a errores, por lo que preferiría tener algo explícito.

Es decir, tener un SiteSetting que de alguna manera apunte a credenciales reales y concretas.