はじめに

先日以下のような記事を書きました。
・別アカウントからS3にアップロードされたファイルの所有者を変更する

記事の中では、コマンドを使用して別アカウントからアップロードされたファイルの所有者をS3バケットの所有者に変更する方法について試しました。

ただ、S3を使用する場合はコマンド以外にも方法はあります。
今回はS3マウントツールのCloudBerryDrive(MSP360)とJPCyberを使用して、別アカウントのEC2からファイルをアップロードした際の所有者変更方法について試してみます。

マウントツールについて知らない方は以下をご覧ください。
・有名なS3マウントツール2つを比較してみた

準備

S3バケットのオブジェクト所有者は希望するバケット所有者にします。

前回作成したEC2にCloudBerryDriveとJPCyberをインストールします。
アカウントの設定も同時に行っておきます。権限はEC2にアタッチされている別アカウントのIAMロールのものを使用します。

インストール方法は過去の記事に書いています。
・JPCYBER S3 Driveを使ってWindowsにS3をマウントしてみた
・CloudBerry Driveを使用してEC2にS3をマウントしてみた

S3バケットは前回のものを流用します。

JPCyberで実施

事前確認

JPCyberで対象のS3バケットがマウントされていることを確認します。

エクスプローラーからファイルを配置します。

コンソールで確認するとファイルがアップロードされていることが確認できます。
ただ、このままでは別アカウントが所有者のままで設定されてしまっています。

ACL設定

JPCyberのツールからオプションの設定を選択します。

オプションの設定に「親バケットのアクセス権をアップロードするファイルに適用する」というチェックボックスがあるので、チェックをつけて保存します。

自動でJPCyberが再起動されるため、再度エクスプローラーからファイルをアップロードしてみます。

これで所有者が変更されるはず...と思ったのですが、何故か変わっていません。

JPCyberのログを見てみるとAccess Deniedが出ていることがわかりました。
アップロード自体は成功しているところを見るとACLを操作しようとして権限の問題で失敗しているように見えます。

2021/06/07 10:49:08.241 [W] Access Denied
2021/06/07 10:49:09.824 [I] Uploading: s3://test-tmp-20210603/test/test2.txt
2021/06/07 10:49:10.888 [I] Upload completed: s3://test-tmp-20210603/test/test2.txt
2021/06/07 10:49:10.935 [W] Access Denied

試しにとACLのチェックを外してアップロードしたらAccess Deniedは出なかったのでACLが関係していることは確定です。

2021/06/07 10:51:06.121 [I] Uploading: s3://test-tmp-20210603/test/test3.txt
2021/06/07 10:51:06.278 [I] Upload completed: s3://test-tmp-20210603/test/test3.txt

念のため同じIAMロールの権限使ってCLIでアップロードしてみます。

PS C:\Users\Administrator\Desktop> aws s3 cp .\test4.txt s3://test-tmp-20210603/test/ --acl bucket-owner-full-control
upload: .\test4.txt to s3://test-tmp-20210603/test/test4.txt

CLIでは問題なくアップロードされて所有者もS3バケットと一緒になっていることが確認できました。

ちょっと色々と調べてみましたが、答えが見つかりそうにないので一旦置いておきます。
もしエラー原因に心当たりある方がいればコメントください。

2021/6/11追記

以下の記事に記載していますが、JPCYBERのオプションを設定した場合、①ファイルをアップロード→②マウント時に取得したS3バケットACLをPutObjectACLリクエストで設定、という2段階に分けて処理がされているようです。
このうち②のPutObjectACLリクエストで403エラーが発生しているようでした。
・JPCYBERのPUT通信をWiresharkで確認する(ACL設定あり)

以下の記事でS3バケットACLをPutObjectACLリクエストで設定する手順を検証してみました。
結果、S3バケットACLのOwnerに設定されているAWSアカウントとPutObjectACLリクエストを送る認証AWSアカウントが一致している必要があるということがわかりました。
・別アカウントからS3にアップロードされたファイルのACLを変更する

上記2つの検証を元に考えると
①マウント時に取得したS3バケットACLを取得
　※Ownerはアップロード先S3バケットのAWSアカウント
②JPCYBERでファイルをアップロード
③アップロードしたファイルに対してPutObjectACLリクエストを送信
　※その際の認証AWSアカウントは①のACLのOwnerに設定されたものとは異なる
④Access Deniedでエラー発生
ということのようです。

解消方法として、アップロード元のAWSアカウントのIAMロールで認証しているのがよろしくないので、アップロード先のAWSアカウントのIAMユーザを作成し、そのアクセスキーを使用することで対応は可能そうです。
※あまりアクセスキーは使用したくないですが。

CloudBerry Driveで実施

事前確認

CloudBerry Driveでマウントされていることを確認します。

エクスプローラーからファイルをアップロードしてみます。

所有者はアップロード元のAWSアカウントのままです。

ACL設定

CloudBerry DriveでACL設定をしていくのですが、実はCloudBerry DriveにはACLの設定をする項目は存在しません。
その代わりCloudBerry Driveから送られるHTTPSリクエストに指定したヘッダーを追加することができます。

CLIのデバッグモードで「--acl bucket-owner-full-control」を実行するとわかりますが、そのオプションを指定した場合はリクエストのヘッダーに「'x-amz-acl': b'bucket-owner-full-control'」が追加されるため、これをCloudBerry Driveのリクエストヘッダーに追加します。

オプションを開いて、Addボタンを押下します。

Add Rule設定画面が表示されるので、上部の「Specify HTTP Headers」を選択します。

表示された画面でさらにAddボタンを押下して、先ほど記載した設定を追加しOKボタンを押下します。

以下の真ん中を選択してOKボタンを押します。

これで設定が完了しました。
さらにOKを押下するとマウントしなおすポップアップが出てくるので、OKを押しておきます。

別のファイルをアップロードしてみます。

S3コンソールから見ると所有者が変更されていました。
これでエクスプローラーからファイルをアップロードする際は、自動でACLの権限を追加することが可能になりました。

おわりに

JPCyberの設定が上手くできていないので不完全燃焼感はありますが、CloudBerryDriveでは無事できたので良かったです。

どちらのツールにも言えることですが、アップロードする際にオブジェクトに対してアップロード以外の操作が実行されることになるため、大量のデータや大規模なサイズのデータを扱う場合には注意が必要です。