Discourse를 AWS에 인증하는 방법은 무엇인가요? 설정 개선을 도와주세요!

기여 기능
1

안녕하세요 여러분,

Discourse가 AWS [1] 인증을 처리하는 방식을 개선하는 방안을 검토 중입니다. 변경 사항을 적용하기 전에 현재 여러분의 설정 방식을 이해하고 싶습니다.

현재 상황

현재 Discourse에서 AWS 인증을 설정하는 방법은 다음과 같습니다:

옵션 1: 명시적 자격 증명 (사이트 설정을 통한)

  • 사이트 설정에서 s3_access_key_id와 s3_secret_access_key를 설정합니다.
  • 인증은 사이트별로 적용됩니다.

옵션 2: 명시적 자격 증명 (환경 변수를 통한)

  • 다음 환경 변수를 설정합니다:
    DISCOURSE_S3_ACCESS_KEY_ID
    DISCOURSE_S3_SECRET_ACCESS_KEY
  • 멀티사이트 클러스터 내 모든 사이트에 동일한 인증이 적용됩니다.

옵션 3: “IAM 프로필 사용” 설정

  • s3_use_iam_profile 사이트 설정을 활성화하거나 환경 변수 DISCOURSE_S3_USE_IAM_PROFILE=true를 설정합니다.
  • Discourse가 AWS SDK를 통해 자격 증명을 자동으로 찾도록 지시합니다.
  • 원래 EC2 인스턴스와 IMDS를 통한 자격 증명 획득을 위해 설계되었지만, 다른 환경에서도 작동합니다.

변경을 원하는 이유

1. 혼란을 주는 설정 이름

s3_use_iam_profile 설정은 오해의 소지가 있는 이름입니다. EC2 인스턴스 프로필에서만 작동하는 것처럼 보이지만, 실제로는 모든 AWS SDK 자격 증명 소스를 활성화합니다:

  • EC2 인스턴스 프로필
  • ECS 태스크 역할
  • 환경 변수
  • AWS 자격 증명 파일
  • IAM 역할 가정(Role Assumption)
  • 기타 등등…

2. 보안: 정적 키 vs. 역할 가정

저희 메탈 호스팅 플랫폼에서는 현재 정기적으로 로테이션되는 액세스 키를 사용하고 있습니다. 더 나은 격리, 접근 제어 기회, 그리고 더 나은 내부 프로세스를 지원하기 위해 역할 가명으로 전환하는 것을 목표로 하고 있습니다.

현재 방식의 단점:

  • 액세스 키는 (로테이션될 때까지) 만료되지 않습니다.
  • 권한 범위가 넓습니다.
  • 유출 시 탈취될 수 있습니다.
  • 수동 로테이션 절차가 필요합니다.

대신 역할 가명을 사용하는 것의 장점:

  • IP 주소를 통해 영속적 자격 증명을 제한할 수 있습니다.
  • 자동 만료되는 임시 자격 증명(보통 1시간)을 사용하여 작업을 수행합니다.
  • 자격 증명이 필요할 때만 존재하므로 필요 시점 접근(Just-in-time access)이 가능합니다.
  • 탈취된 임시 자격 증명이 빠르게 만료되므로 피해 범위가 줄어듭니다.
  • 키 로테이션이 필요하지 않으며, 역할 가정 프로세스가 갱신을 처리합니다.
  • 각 세션이 별도로 추적되므로 감사 트레일이 더 좋습니다.

검토 중인 사항

다음 중 하나를 고려하고 있습니다:

  1. 설정 이름을 aws_credentials_from_environment처럼 더 명확한 이름으로 변경
  2. 설정을 완전히 제거하고 자격 증명이 환경 변수에서 가져와야 하는지 사이트 설정에서 가져와야 하는지를 자동으로 감지

여러분의 의견이 필요합니다!

다음에 대해 알려주시기 바랍니다:

  1. S3 인증 방식을 어떻게 사용하고 계신가요?

    • 사이트 설정에 명시된 액세스 키
    • EC2 인스턴스 프로필 (s3_use_iam_profile 활성화)
    • ECS 태스크 역할 (s3_use_iam_profile 활성화)
    • 환경 변수 (s3_use_iam_profile 활성화)
    • … 기타?

  2. s3_use_iam_profile을 사용 중이시라면:

    • 어떤 환경에서 실행하고 계신가요? (EC2, ECS, Docker, 베어 메탈 등)
    • 현재 이름/설명이 혼란을 주었나요?
    • 다른 이름이 더 명확할까요?

  3. 이 설정에 대한 변경 사항에 우려가 있으신가요?

    • 현재 설정이 깨질까 걱정되나요?
    • 변경 사항을 테스트할 시간이 필요하신가요?
    • 기타 고려 사항이 있나요?

왜 이것이 중요한가

더 나은 S3 인증은 다음과 같은 것을 의미합니다:

  • 더 안전함 - 관리해야 할 정적 키가 없음
  • 더 쉬운 설정 - 특히 클라우드 배포 환경에서
  • 더 적은 혼란 - 더 명확한 설정 및 문서
  • 최신 AWS 인증 패턴에 대한 더 나은 지원

여러분의 피드백은 모든 사람에게 유용한 개선을 만드는 데 도움이 됩니다. 설정 방식을 공유해 주셔서 감사합니다!

  1. 여기서 'AWS’는 '사용 중인 S3 호환 객체 저장소 프로바이더’로 읽으십시오 ↩︎

2개의 좋아요
An AWS S3 Integration with Discourse Tutorial would be nice
2

이렇게 답변하는 것이 더 쉽습니다:

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

제 환경은 한 사람이 모든 것을 관리하는 운영 방식입니다. 따라서 화려한 기능이 필요하지는 않지만, 편의성은 매우 중요합니다.

2개의 좋아요
3

저도 ENV 방식을 사용합니다.

가장 큰 장점은 회복력과 민첩성입니다. app.yml 파일만 있으면 최소한의 노력으로 새 서버에 사이트를 재실행할 수 있습니다. 또는 스테이징 서버를 쉽게 조작할 수도 있습니다.

또한, 이는 일반적으로 사이트를 구축할 때 한 번만 설정하거나, 일회성 업그레이드로 처리하는 경우가 많습니다. 따라서 ENV 방식이 잘 맞습니다.

그럼에도 불구하고, 재빌드 없이 문제 해결을 위해 설정값을 활용할 수 있는 것도 유용합니다. 설정이 안정화되면, 그 후 ENV 설정으로 이관할 수 있습니다.

4

이것은 사소한 지적처럼 들릴 수 있지만, 여기에는 몇 가지 중요한 뉘앙스가 있다고 생각합니다.
제시하신 옵션들은 설정이 어떻게(HOW) 전달되는지와 어떤(WHAT) 설정이 전달되는지의 혼합입니다.

설정 전달 방식(HOW)에 관해서는 다음 두 가지가 적용됩니다:

  1. 현재 환경 변수가 사용되고 있는 방식

DISCOURSE_WHATEVER 환경 변수는 현재 Docker 빌드 과정에서 discourse.conf 항목을 생성하는 데 사용되며, 이 항목들은 Discourse 내부에서 GlobalSetting 또는 SiteSetting으로 사용할 수 있습니다. Discourse는 이러한 환경 변수를 환경 변수로 인식하지 않습니다.

  1. discourse.conf 항목의 제한 사항

GlobalSettings는 SiteSettings를 억제하고 오버라이드할 수 있는 좋은 장점이 있지만, 멀티사이트 환경에서는 멀티사이트의 모든 사이트에 적용된다는 제한 사항을 강요합니다.

이 두 가지가 결합되면 Discourse 내부에서는 SiteSetting이 가장 유연합니다. 이들은 실제 SiteSettings일 수 있으며, 선택적으로 discourse.conf에서 가져올 수 있고, 해당 항목은 DISCOURSE_ 환경 변수에서 가져올 수 있습니다. 제 생각에는 거기에 실질적인 선택지가 없습니다. SiteSetting은 가장 유연하고, 다른 것들의 기능적 초집합(superset)이므로 단점이 없습니다. 원한다면 대신 GlobalSettings를 사용할 수 있으며, 그것도 환경 변수를 사용하여 채울 수 있습니다.

즉, 유일한 실질적인 선택지는 자격 증명의 자동 발견을 사용할 것인지 여부입니다. 제 개인적인 인식에 따르면, 자동 발견은 항상 오류가 발생하기 쉬우므로 명시적인 무언가를 선호합니다.

즉, 실제 구체적인 자격 증명을 가리키는 SiteSetting을 가지는 것입니다.