Discourseの認証をAWSで行うには？設定改善にご協力ください！

[ducks]

皆さん、こんにちは。

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 ロール引き受け
• その他多数…

2. セキュリティ: 静的キー vs ロール引き受け

当社のメタルホスティングプラットフォームでは、定期的にローテーションされるアクセスキーを使用しています。より優れた分離、アクセス制御の機会、および優れた内部プロセスのサポートのために、ロール引き受けに切り替えることを目指しています。

現在の方法の欠点:

• アクセスキーは（ローテーションされるまで）期限切れになりません。
• 広範な権限スコープを持っています。
• 漏洩した場合に侵害される可能性があります。
• 手動ローテーション手順が必要です。

代わりにロール引き受けを使用することの利点:

• 永続的な認証情報は IP アドレスによって制限できます。
• 操作は、自動的に期限切れになる（通常は 1 時間）一時的な認証情報を使用して行われます。
• 認証情報は必要なときにのみ存在するため、ジャストインタイムアクセスが可能です。
• 侵害された一時的な認証情報はすぐに期限切れになるため、影響範囲が縮小されます。
• キーローテーションなし - ロール引き受けプロセスが更新を処理します。
• より優れた監査証跡 - 各セッションは個別に追跡されます。

検討中のこと

以下のいずれかを検討しています。

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. ここを読む: 使用している S3 互換オブジェクトストレージプロバイダー ↩︎

[Jagster (Jakke Lehtonen)]

このように答える方が簡単です。

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

私の運用は「1人の人間、1人の管理者」のオペレーションです。そのため、派手なものは必要ありませんが、手軽さは非常に重要です。

[nathank (Nathan Kershaw)]

私もENVアプローチを使用しています。

主な利点は、回復力/俊敏性です。app.ymlがあれば、最小限の手間で新しいサーバーにサイトを再開できます。

また、これはサイトを確立したときに一度だけ解決するか、または一度限りのアップグレードとして実行するものです。そのため、ENVにうまく適合します。

とはいえ、再構築せずにトラブルシューティングのために設定を利用できるようにしておくことも役立ちます。設定が安定したら、ENV設定に移行できます。

[RGJ (Richard - Communiteq)]

@ducks

認証情報が環境から来るべきか、サイト設定から来るべきか

これは些細なことのように聞こえるかもしれませんが、ここにはいくつかの重要なニュアンスがあると思います。
提供されているオプションは、設定がどのように渡されているかと、どの設定が渡されているかの混合です。

設定がどのように渡されているかに関して、2つのことが適用されます。

1. 環境変数が現在どのように使用されているか
   DISCOURSE_WHATEVER 環境変数は、現在 Docker ビルドプロセス中に discourse.conf のエントリを作成するために使用されており、これらは Discourse 内から GlobalSetting または SiteSetting として利用できます。Discourse はこれらの環境変数をそのように認識しません。

2. discourse.conf エントリの制限
   GlobalSettings は SiteSettings を抑制およびオーバーライドできるという便利な機能を持っていますが、マルチサイト環境ではマルチサイトのすべてのサイトに適用されるという制限も課しています。

これら2つを組み合わせると、Discourse 内からは SiteSetting が最も柔軟であることがわかります。これらは実際の SiteSetting であったり、discourse.conf から来たり、それらのエントリは DISCOURSE_ 環境変数から来たりすることができます。私の意見では、そこには実際の選択肢はありません。SiteSetting は最も柔軟で、欠点がありません。なぜなら、それらは機能的なスーパーセットだからです。代わりに GlobalSettings を使用でき、それらは環境変数を使用して入力できます。

これは、唯一の実際の選択肢は、認証情報の自動検出を使用するかどうかであるということです。私の個人的な認識では、自動検出は常にエラーを起こしやすいため、明示的なものを好みます。

つまり、実際の具体的な認証情報を示す SiteSetting を持つということです。