Help us understand the problem. What is going on with this article?

AWSのS3署名バージョン2は廃止となる為、現在バージョン2で稼動中のbash+AWSCLIでS3にファイルアップロードする仕組みを、署名バージョン4に対応させる為に行った作業について

1. 作業が必要になった背景

Amazon AWSのS3へのファイルアップロードをする仕組みを、
bashスクリプト + AWS CLIで実装していたのだが、

署名バージョン 2 は廃止され、署名バージョン 2 の最終サポートは 2019 年 6 月 24 日に終了します。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingAWSSDK.html

このアナウンスがあった為、これまでの仕組みの変更が必要となった。

修正内容は、これまで署名バージョン2を使っていたファイルアップロードする仕組みを、
署名バージョン4でファイルアップロードする仕組みに改める事。

2. 対処方法の概要

2.1. AWS CLIのバージョンアップ

AWSのドキュメントを紐解いて調べると、使用しているAWS CLIのバージョンは1.11.108以上が求められるようだ。
20190405_アップグレードの判定.png
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingAWSSDK.html 抜粋

2.2. 実装のバージョンアップ

AWSのSDKを使っている実装であるならば、プログラムの修正はあまり必要なく、SDKのバージョンアップと、
新しい署名へ対応する為の僅かなコードの追加のみで、スムーズに移行できる雰囲気だ。
AWS CLIもAWSのSDKによって実装されている為、簡単な対応の適用範囲だと思われる。

だが、具体的にどうやったら良いか全くわからないので、AWSのドキュメントを紐解いて調べる。
20190405_リクエスト認証に署名バージョン4を使用するようリクエストする.png
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingAWSSDK.html 抜粋

デフォルトプロファイルか、カスタムプロファイルか、どちらによる実装であるかを、実装から見分ける必要がある。
今回は、bashで書かれたシェルの中で、以下のとおり環境変数を設定している為、

export AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX
export AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
export AWS_DEFAULT_REGION=XX-XXXXXXXXX-X

この処理に使われているプロファイルは、デフォルトプロファイルとなり、
上記の一文をbashスクリプトに追記する事が主な対応となるようだ。
aws configure set default.s3.signature_version s3v4

3. 対処方法の詳細:①AWS CLIのバージョンアップ

3.1. 環境のチェック

現在使っている環境の情報はコマンドを入れて確かめると以下のような状態となっている。

[XXXXXXXX@ip-XXX-XXX-XXX-XXX bin]$ cat /etc/system-release
Amazon Linux AMI release 2016.03
[XXXXXXXX@ip-XXX-XXX-XXX-XXX bin]$ arch
x86_64
[XXXXXXXX@ip-XXX-XXX-XXX-XXX bin]$ aws --version
aws-cli/1.10.8 Python/2.7.10 Linux/4.4.10-22.54.amzn1.x86_64 botocore/1.4.51

また、AmazonのマネージドコンソールからEC2構築時のイメージを調べると以下のように表示される。

amzn-ami-hvm-2015.03.0.x86_64-gp2

この事から、aws-cliのバージョンが1.10.8と、1.11.108を下回るので、AWS CLIのバージョンアップが必要である事がわかった。

3.2.バージョンアップ作業

本当は以下のようなコマンドでやれるとうれしかったのだが、
sudo pip install --upgrade --user awscli=1.11.108

以下の理由から、このコマンドでは対応ができなかった。
・ AWS CLIは最新バージョンへのアップグレードにしか対応していない
・ sixというライブラリを除外するオプションをつけないと、アップグレードが異常終了する

正式には以下のコマンドを投入する事で解決した。
sudo /usr/local/bin/pip install --upgrade awscli --ignore-installed six

[XXXXXXXX@ip-XXX-XXX-XXX-XXX bin]$ aws --version
aws-cli/1.16.139 Python/2.7.10 Linux/4.4.10-22.54.amzn1.x86_64 botocore/1.12.129

4. 対処方法の詳細:②実装のバージョンアップ

既に以下のように書かれているs3へのアップロード処理の部分について、

修正前.sh
sudo /usr/bin/aws s3 cp XXXXXXXXXXXXX/*.tar s3://XXXXXXXXXX-XXXXXXXXXXX-XXXXXXXXXX/

以下のとおり「aws configure set default.s3.signature_version s3v4」の一行を割り込ませる。

修正後.sh
aws configure set default.s3.signature_version s3v4
sudo /usr/bin/aws s3 cp XXXXXXXXXXXXX/*.tar s3://XXXXXXXXXX-XXXXXXXXXXX-XXXXXXXXXX/

この事で、署名はバージョン2から、バージョン4へ切り替わるようだ。

5. 対処方法の詳細:③実行結果のログの確認

5.1.シェルの実行

上記で4まで作業を進め、実際にシェルを実行するわけだが、

処理が正常終了しエラーを吐かないようだ、だからOKだ。 ←NGですね

では終わらないのがエンジニアの仕事。ちゃんとエビデンスを採取して確認する必要がある。

5.2.ログの出力

まずは、S3のログ出力は現在OFFになっているので、アクセスログを採取できるように設定を行う。
S3のバケットのアクセスログを採取できるように、設定を変更する。
[プロパティ]→[サーバーアクセスのログ記録]→[ログ有効化]→ターゲットパケットの指定
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ServerLogs.html 詳細は参照

1時間くらい経過すると、バケットの中に次々とログが出力されるようになる。
大体1時間以上遅れてログが吐き出されるらしく、お昼の12:00に出力したはずのバックアップのログは13:20頃に出力されていた。
20190408_S3のログ_2.png

5.3.ログの分析

S3のログの分析のやり方はこちらに説明がある。
Amazon S3サーバーアクセスログフォーマット

今回、確認したい事は、bashのシェルがs3へ行うアップロード処理が、署名バージョン4で行われている事の確認である。
ログを分析すると、署名バージョンに「SigV4」と出力されている。
正しく署名バージョン4で処理された事が確認できた。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx [07/Apr/2019:03:01:38 +0000] xxx.xx.xx.xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx REST.PUT.PART xxxxxxxxxxxxxxxxxxxxxxxx.tar "PUT /xxxxxxxxxxxxxxxxxxxxxxxx.tar?partNumber=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-- HTTP/1.1" 200 - - 8388608 708 53 "-" "aws-cli/1.16.132 Python/2.7.10 Linux/4.4.10-22.54.amzn1.x86_64 botocore/1.12.122" - xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= SigV4 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.amazonaws.com TLSv1.2

※ログにはマスクをかけさせていただいております。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした