S3互換ストレージ(MinIO等)にWindowsから接続する — つまずくのは接続設定
MinIO や Ceph、各社のオブジェクトストレージを Windows から使うとき、手順書どおりに進めたのに繋がらない、ということがよくあります。原因はたいていマウントの手前、S3 の接続設定にあります。しかもその要件は、本家 Amazon S3 と S3 互換とで逆になっている項目があります。
この記事の内容
パススタイルと仮想ホスト形式 — AWSと互換ストレージで要件が逆
S3 の API には、バケットをどう指すかで2つの形式があります。
問題は、どちらが必要かが接続先によって変わることです。
- 本家 Amazon S3 は、
us-east-1以外のバケットに対してパススタイルのリクエストを拒否します。 - S3 互換ストレージは、多くの場合パススタイルが必要です。仮想ホスト形式はバケット名がホスト名の一部になるため、ワイルドカード DNS を用意していない環境では名前解決そのものができないからです。MinIO の標準的な構成もこれに当たります。
つまり、AWS 用に書かれた手順をそのまま互換ストレージに使うと繋がらず、逆もまた同じです。
MovedPermanently や The bucket you are attempting to access must be addressed using the specified endpoint が返ります。厄介なのは、これが HTTP 301 で返ってくるのに自動で追従できないことです。HEAD や List のレスポンスには本文が無く、正しいエンドポイントがどこかを読み取れないためです。「リダイレクトされているのに辿れない」という、原因の分かりにくい失敗になります。
バケット名.エンドポイント という FQDN を名前解決しようとして失敗します。DNS のエラーとして出るため、認証情報やバケット名を疑ってしまい、遠回りしがちです。
どちらが必要かの見分け方
エンドポイントのホスト名が amazonaws.com で終わるかどうかで判断できます。終わるなら仮想ホスト形式、それ以外はパススタイル、という切り分けが実用上ほぼ当たります。
S3 DriveBridge はこの判定を自動で行うため、利用者が選ぶ設定項目にはしていません。エンドポイント URL を入れれば、AWS 宛は仮想ホスト形式、それ以外はパススタイルで送ります。
署名バージョンとリージョン名
S3 の API リクエストは署名されます。現行は SigV4、古い実装向けに SigV2 があります。新しく構築した MinIO であれば V4 で問題ありません。V2 が要るのは、かなり古い互換実装や、一部の機器組み込みのオブジェクトストレージです。
見落としやすいのがリージョン名です。SigV4 の署名文字列にはリージョンが含まれるため、クライアントとサーバーで同じ値を使っていないと署名が一致しません。互換ストレージにはリージョンという概念が無いことも多く、その場合は既定値(us-east-1 など)が使われています。
SignatureDoesNotMatch になります。接続先のドキュメントで既定のリージョン名を確認してください。
リバースプロキシ越しの SignatureDoesNotMatch
互換ストレージを社内に置き、前段にリバースプロキシ(nginx、HAProxy、各種アプライアンス)を挟んでいる構成では、認証情報が正しくても署名が通らないことがあります。
原因は Host ヘッダーです。SigV4 は Host ヘッダーを署名対象に含みます。一方、リバースプロキシの既定動作は「転送先のホスト名や IP に Host を書き換えて渡す」ことが多く、そうなるとサーバーが受け取る Host はクライアントが署名したものと別物になります。結果は SignatureDoesNotMatch です。
対処
- リバースプロキシ側で、クライアントが送ってきた Host をそのまま転送する設定にします。nginx なら
proxy_set_header Host $host;にあたります。 - 前段がアプライアンスなどで Host を保持できない場合は、転送先の直前にもう一段プロキシを置き、
X-Forwarded-Hostから Host を復元してから渡す、という形で回避できます。 - いずれも難しい場合は、クライアントが署名する Host と、サーバーが検証する Host を一致させる — つまり公開ホスト名でそのまま到達させるのが確実です。
TLS と自己署名証明書
検証環境の MinIO では、自己署名証明書を使っていることがよくあります。この場合、多くのクライアントは証明書の検証に失敗して接続できません。
取れる方法は3つです。
- 正規の証明書を用意する。 社内向けでも、Let's Encrypt などで正規の証明書を取得できる構成にするのがいちばん後腐れがありません。
- 自己署名証明書(またはその CA)を Windows の証明書ストアに入れる。 「信頼されたルート証明機関」に配置すれば、OS の検証を通ります。
- TLS を使わない。 閉じた検証環境に限った話です。S3 の認証情報が平文で流れるため、業務データには使わないでください。
接続前に手元で確認できること
クライアントを設定する前に、次を押さえておくと切り分けが早くなります。
| 項目 | 確認すること |
|---|---|
| エンドポイント URL | スキーム(https:// か http://)とポート番号まで含めた完全な形。バケット名は含めない |
| パススタイル | 接続先が AWS 以外なら、まずパススタイルを前提にする |
| 署名バージョン | 原則 V4。V2 が要るのは古い実装のみ |
| リージョン名 | サーバー側の既定値に合わせる。「無いから空」は誤り |
| Host ヘッダー | 前段にプロキシがあるなら、Host が保持されているか |
| 証明書 | 自己署名なら Windows の証明書ストアに入れておく |
ここまで揃っていれば、あとはドライブとして見せる部分の話になります。Windows でファイルシステムとして扱うには WinFsp が必要です。
S3互換ストレージも、ドライブとして開けます
S3 DriveBridge は Amazon S3 のほか、MinIO などの S3 互換ストレージに対応しています。パススタイルは自動判定、署名バージョン・リージョン・TLS・HTTPプロキシは設定画面から指定できます。30日間、無料で試せます。
製品ページを見る