#AWS aws configureを使った認証系あれこれのお試し

aws configureを使ってEC2からのAWSリソース(S3)認証周りを試してみたのでメモ。

(前提)

　東京リージョン(ap-northeasrt-1)

　EC2インスタンスｘ１（Amazon Linux2)

　S3に１つバケット作成済　（バケット名：hogehoge）

①IAMユーザのアクセスキーをaws configureを使ったプロファイルとして作成してアクセスする方法

まず何もしないでいきなりs3にアクセスしようとしてもエラーになります。

　　[ec2-user@***** ~]$ aws s3 ls s3://hogehoge/
　　Unable to locate credentials. You can configure credentials by running "aws configure".
　
次に現在のプロファイル（default）を確認→何も入っていない
　　[ec2-user@***** ~]$ aws configure list
　　      Name                    Value             Type    Location
　　      ----                    -----             ----    --------
　　   profile                <not set>             None    None
　　access_key                <not set>             None    None
　　secret_key                <not set>             None    None
　　    region                <not set>             None    None
　　
　　[ec2-user@***** ~]$ aws s3 ls --profile default
　
　　The config profile (default) could not be found
　

マネジメントコンソール側の作業は割愛しますが、あらかじめS3にアクセスできる権限(IAMポリシー)を付与した

IAMユーザを作成しました。

んでそのIAMユーザに紐づくアクセスキーを作成しておきまして、そこから各種Key情報を取ったうえで、

aws configureコマンドでプロファイルを作成。

今回は「s3access」という名前でプロファイルを作成しました。

　
　　[ec2-user@***** ~]$ aws configure --profile s3access
　　AWS Access Key ID [None]: **********
　　AWS Secret Access Key [None]: *************
　　Default region name [None]: ap-northeast-1
　　Default output format [None]: json
　　
　　[ec2-user@***** ~]$ aws configure list
　　      Name                    Value             Type    Location
　　      ----                    -----             ----    --------
　　   profile                <not set>             None    None
　　access_key                <not set>             None    None
　　secret_key                <not set>             None    None
　　    region                <not set>             None    None
　　
　　[ec2-user@***** ~]$ aws configure list --profile s3access
　　      Name                    Value             Type    Location
　　      ----                    -----             ----    --------
　　   profile                 s3access           manual    --profile
　　access_key         **************** shared-credentials-file    
　　secret_key         **************** shared-credentials-file    
　　    region           ap-northeast-1      config-file    ~/.aws/config

というところまで準備したのでs3へのアクセス可否を確認

aws s3 lsコマンド時に何も指定しないとdefalutプロファイルでのアクセスになるので、やっぱりエラー。

　　[ec2-user@***** ~]$ aws s3 ls s3://hogehoge/
　　Unable to locate credentials. You can configure credentials by running "aws configure".
　　

次にプロファイル名「s3access」を指定して実行

　　[ec2-user@***** ~]$ aws s3 ls --profile s3access s3://hogehoge
　　2023-07-04 10:45:38       5258 xxxxxx.txt
　　2023-07-04 10:45:37        942 xxxxxx.txt
　　2023-07-04 10:45:38        539 xxxxxx.txt
　　2023-07-04 10:45:37       2138 xxxxxx.txt
　　2023-07-04 10:45:37         99 xxxxxx.txt
　　2023-07-04 10:45:37        375 xxxxxx.txt
　　
はい、ちゃんと見えました。

一旦これはこれでOK。
 

②今さら感がありますが、IAMロールでも確認

詳細割愛しますが、あらかじめs3FullAccessのポリシーを付与したIAMロールを作り、

且つ今回のEC2インスタンスに、IAMロールをアタッチしました。

その状態でaws configureを実行すると、下記のようにdefaultに設定されるようです。

　　
　　[ec2-user@***** ~]$ aws configure list
　　      Name                    Value             Type    Location
　　      ----                    -----             ----    --------
　　   profile                <not set>             None    None
　　access_key         ****************         iam-role    
　　secret_key         ****************         iam-role    
　　    region                <not set>             None    None

ですので、aws s3 lsコマンドもプロファイル名を指定せずに実行できるようになります。

　　[ec2-user@***** ~]$ aws s3 ls s3://hogehoge/
　　2023-07-04 10:45:38       5258  xxxxx.txt
　　2023-07-04 10:45:37        942  xxxxx.txt
　　2023-07-04 10:45:38        539  xxxxx.txt
　　2023-07-04 10:45:37       2138  xxxxx.txt
　　2023-07-04 10:45:37         99  xxxxx.txt
　　2023-07-04 10:45:37        375  xxxxx.txt

一方で先ほど設定したs3accessも健在。

　　[ec2-user@***** ~]$ aws configure list --profile s3access
　　      Name                    Value             Type    Location
　　      ----                    -----             ----    --------
　　   profile                 s3access           manual    --profile
　　access_key         **************** shared-credentials-file    
　　secret_key         **************** shared-credentials-file    
　　    region           ap-northeast-1      config-file    ~/.aws/config
　　

IAMロールをアタッチした方が簡単ですし、アクセスキーも持たずに済むので

セキュリティリスクも運用負荷も避けられることからIAMロール運用の方が

AWSのべスプラであることは間違いないですが、、、

システムや運用によっては、IAMロールは別のものに使って、その他の用途と組み合わせる時には

こういう方法もありなのかなあ、とか思ったり。

（それでもIAMポリシー/IAMロールの方をいろいろ組み合わせればなんとかなるし、

　そちらの方がよいような気もしますが、、）


（番外編）アクセスキーを入れ替えた場合のプロファイル設定変更
　　
　　[ec2-user@***** ~]$ aws s3 ls s3://hogehoge/ --profile s3access
　　
　　An error occurred (InvalidAccessKeyId) when calling the ListObjectsV2 operation: The AWS Access Key Id you provided does not exist in our records.
　　
　　[ec2-user@***** ~]$ aws configure --profile s3access
　　AWS Access Key ID [****************]: **********************
　　AWS Secret Access Key [****************]: ***********************
　　Default region name [ap-northeast-1]: 
　　Default output format [json]: 
　　
　　[ec2-user@***** ~]$ aws configure list --profile s3access
　　      Name                    Value             Type    Location
　　      ----                    -----             ----    --------
　　   profile                 s3access           manual    --profile
　　access_key         **************** shared-credentials-file    
　　secret_key         **************** shared-credentials-file    
　　    region           ap-northeast-1      config-file    ~/.aws/config
　　
　　[ec2-user@***** ~]$ aws s3 ls s3://hogehoge/ --profile s3access
　　2023-07-04 10:45:38       5258 xxxx.txt
　　2023-07-04 10:45:37        942 xxxx.txt
　　2023-07-04 10:45:38        539 xxxx.txt
　　2023-07-04 10:45:37       2138 xxxx.txt
　　2023-07-04 10:45:37         99 xxxx.txt
　　2023-07-04 10:45:37        375 xxxx.txt
 

#AWS AWSCLIをインストール～設定@win11

Windows 11のPCになったのでAWS CLIを再度設定

・以下からAWSCLIV2をDL

Installing or updating the latest version of the AWS CLI - AWS Command Line Interface

・cmd開いて、以下のコマンドを実行

　msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi

　　→インストールの案内が出るのでNextをポチポチ～Finish

　つつがなく終わったら、cmdもう1個開いて確認

　aws --version

　こんな感じの結果になったのでＯＫのようです。

　C:>aws --version
　　aws-cli/2.12.1 Python/3.11.3 Windows/10 exe/AMD64 prompt/off

・IAMユーザの認証紐づけ

　Mangement Console

　　→　IAM

　　　→　IAMユーザ選択

　　　　→　セキュリティ認証情報　タブ

　　　　　→　アクセスキーの作成　選択

　　ステップ1：

　　　CLIを選択

　　ステップ2：

　　　説明タグを入力

　　アクセスキーをダウンロード(CSVで)

・cmdで認証情報をセッティング

　C:\Users\kento>aws configure
　　AWS Access Key ID [None]: Access Key ID
　　AWS Secret Access Key [None]: Secret Access Key
　　Default region name [None]: ap-northeast-1
　　Default output format [None]: json

　設定はここに作られる

　C:\Users\ユーザ名\.aws

　C:\Users\xxxx\.aws>type credentials
　　[default]
　　aws_access_key_id = Access Key
　　aws_secret_access_key = Secret Key

　C:\Users\xxxx\.aws>type config
　　[default]
　　region = ap-northeast-1
　　output = json

　ここまでやれば目的のAWSリソースにアクセスできる

#AWS マネジメントコンソールからWindows Serverのリモート接続できるの便利〜

AWSマネジメントコンソールからWindows serverに

RDP的に接続できたのでメモ。

これは便利。

毎回Global IP変わるのにRDPクライアントの設定イジるのめんどかったので。

使用したもの→Fleet Manager（SSMの機能の1つ？なのかしらね）

・準備

１）Windows server 2019のEC2インスタンスをLaunch

　　→ここでたいしたことはしていない。

　　→このFleet ManagerにはSSMエージェントが必要っぽいけど

　　　Win2019はクイックスタートAMIでプリインストールされてるよう

省略）ちゃんとやろうとするのであれば、Fleet Manager接続用の

　　　IAMユーザとIAMグループを作らないといけないっぽいが

　　　まあ自分の検証用なので単純にAdmin権限で。

２）IAMロールを準備

　→以下のポリシーをアタッチしたIAMロールを作成。

　　AmazonSSMManagedInstanceCore　（必須）SSMでは必須のポリシー

　　AmazonS3FullAccess 　（任意）SSMログをS3に置きたければ必須

　　AmazonSSMDirectoryServiceAccess　（任意）AD配下に置きたければ

　　CloudWatchAgentServerPolicy　（任意）CloudWatchでなにかしたければ

　なんで厳密には1個めだけでいいっぽいけど、とりあえず全部つけてみた。

　（AWSの設計ポリシーに反するｗ）

　んでできたIAMロールを作ったWin2019サーバにアタッチ。

３）マネジメントコンソールのSSM→Fleet Managerのところに行くと

　　さっき作ったWin2019が表示されているので、

　　選択　→　「ノードアクション」　→　「リモートデスクトップとの接続」

　　あとはお好きなユーザ認証方法で認証を進めてConnect

これでRDPで接続して操作ができるようになる。

↓

  参照

EC2 インスタンス用 AWS Systems Manager のセットアップ - AWS Systems Manager

#AWS メモ：S3のバケット作成、オブジェクト格納、バケット削除までのCLI作業メモ

■バケット作成〜バージョニング有効化まで

#事前確認：バケットの一覧

aws s3api list-buckets --output text

#バケットをTokyoリージョンに作成

aws s3api create-bucket --bucket labo-bucket202301 --region ap-northeast-1 --create-bucket-configuration LocationConstraint=ap-northeast-1

#作成後確認

aws s3api list-buckets --output text 

#バージョニング有効化前確認

aws s3api get-bucket-versioning --bucket labo-bucket202301

#バージョニング有効化

aws s3api put-bucket-versioning --bucket labo-bucket202301 --versioning-configuration Status=Enabled

#バージョニング有効化後確認

aws s3api get-bucket-versioning --bucket labo-bucket202301

■作ったバケットにファイルを試しに置く

#ｌｓ確認

aws s3 ls labo-bucket202301

#ファイルをｃｐで置く

aws s3 cp hogehoge.yml s3://labo-bucket202301

#ｌｓ確認

aws s3 ls labo-bucket202301

■バケットを削除する

#ｒｂで消す→remove bucketということかしらね

aws s3 rb s3://labo-bucket202301

んで、エラーが出ました。

remove_bucket failed: s3://labo-bucket202301 An error occurred (BucketNotEmpty) when calling the DeleteBucket operation: The bucket you tried to delete is not empty. You must delete all versions in the bucket.

バケットが空じゃないから消せないよ、って言ってるんですね。

これは想定どおり。

どう怒られるのか知りたかったので、敢えて空にしないままやりました。

ということでまずはオブジェクトを消す。

#オブジェクトを消す

aws s3 rm s3://labo-bucket202301/hogehoge.yml

#確認

aws s3 ls s3://labo-bucket202301

#ということでもう一度ｒｂチャレンジ

aws s3 rb s3://labo-bucket202301

...また怒られました。

remove_bucket failed: s3://labo-bucket202301 An error occurred (BucketNotEmpty) when calling the DeleteBucket operation: The bucket you tried to delete is not empty. You must delete all versions in the bucket.

なんで？となりましたが、バージョニングが有効化されている場合

オブジェクトを消すと削除マーカーっていうのができるので

バケット削除がエラーになるって聞いたことがあったのを思い出しました。

→この後施工錯誤したんですが、CLIだとうまくできなかったので

　コンソールからオブジェクトを完全削除

→その後もう1度CLIで削除を試して無事バケット削除完了

　（失敗したやつ載せておく）

　#削除マーカーの確認

　aws s3api list-object-versions --bucket labo-bucket202301

　aws s3api delete-object --bucket labo-bucket202301 --key hogehoge.yml

　→これで消えると思ったんだけどな〜

#AWS メモ：S3バケットのバージョニング設定をCLIで有効化した

S3のバケットバージョニング設定を、CLIからやってみたのでメモ。

クライアントはCloud9を使う。

これ楽ね。

■バケットの一覧を出す

aws s3api list-buckets 

　→デフォだとjson形式で出るので見づらかったら、textかtable形式も指定できる

　　aws s3api list-buckets --output text

　　aws s3api list-buckets --output table

■バージョニングの有効化

（事前確認）

aws s3api get-bucket-versioning --bucket バケット名

→デフォだと無効化中なので、何も返ってこない

（変更：バージョニング有効化）

aws s3api put-bucket-versioning --bucket バケット名 --versioning-configuration Status=Enabled

→成功すると特に何も返ってこない

（事後確認）

aws s3api get-bucket-versioning --bucket バケット名

→こんな結果が返ってくる

~~~~~~~~~~~~~~

$ aws s3api get-bucket-versioning --bucket バケット名
{
    "Status": "Enabled"
}

~~~~~~~~~~~~~~

→この後マネジメントコンソールのS3画面でも確認したけど、ちゃんとバージョニングが有効化されてた。

#ヴェルディ マジでそこ取れたの案件

佐藤ひさや更新。

まあそうかなとは思ってた。

3年目、今年が勝負やね。ライバル多いけど。

佐藤久弥 選手、契約更新のお知らせ | 東京ヴェルディ / Tokyo Verdy

そしてマアヤはなんとなくそうかなとは思っていたが放流へ。

おっきくなって帰ってこいよ。

まあ出られるところへ行ったほうがよい。正直。

佐古真礼 選手、長野パルセイロへ育成型期限付き移籍のお知らせ | 東京ヴェルディ / Tokyo Verdy

そしてマリオ、宮原に続く思わぬところからマジでよく取れたね案件。

これはいい補強。

よくわかってないんだけどFW？ウィング？真ん中？

どちらにせよJ2レベルではない選手のハズ。

これは期待！

齋藤功佑 選手が横浜FCより完全移籍加入のお知らせ | 東京ヴェルディ / Tokyo Verdy

#ヴェルディ 谷口残った！

谷口更新のニュースがやっと来た。。。

おそらくJ1からオファーはあっただろう、、、

そりゃそうだよ。

現時点でのレベルと年齢を考えた場合の伸びしろ期待値が高すぎるやん。

でも残ってくれた！

嬉しい！

ユニ買っちゃう！ｗ

さあ、あとは最大の懸念案件、アーレーモリタコウキーか。。。

谷口栄斗 選手、契約更新のお知らせ | 東京ヴェルディ / Tokyo Verdy

#AWS ロギングサービスを整理したメモ

AWSのロギングサービスを整理してみたのでメモ。

これで全部じゃないと思うけどとりあえず勉強した範囲で出てきたもので。。。

#ヴェルディ 2023年もJFK（さよならIDE）

やっと懸念材料でしたJFK更新のニュースが来てホッとしております。

風呂に入りながら、

マジでJFKアウト→中後昇格とかやったらマジで勘弁しねえからな

と思っていた矢先でしたので良かったです。

（いや、中後が悪いわけではないんですがこの場合）

そしてひっそりとIDEがKOBEに。

上手いは上手いが、あの稼働率でよく取ってくれたな、という感想です。

でもIDEのプレーは好きだった。

KOBEでも頑張れよ。

でも向こうにさ、HIDEKIいるけど大丈夫なん？

城福浩 監督、契約更新のお知らせ | 東京ヴェルディ / Tokyo Verdy

#AWS SNSトピックをCLIで設定してみた。

SNS TopicをCLIで作成

aws sns create-topic --name topic-name

はい、エラー出ました。

いつものIAMロールです。

エラーを出さないと思い出さない。

An error occurred (AuthorizationError) when calling the CreateTopic operation: User: arn:aws:sts::***:assumed-role/AmazonSSMRoleForInstancesQuickSetup/i-**** is not authorized to perform: SNS:CreateTopic on resource: arn:aws:sns:ap-northeast-1:******:topic-get-cost because no identity-based policy allows the SNS:CreateTopic action

IAMロールにいって、SNS:CreateTopicポリシーをIAMロールに追加付与。

（めんどくさかったのでSNSフルアクセスで付けちゃった）

もう1回実行。

# aws sns create-topic --name topic-name
{
    "TopicArn": "arn:aws:sns:ap-northeast-1:******:topic-name"
}

サブスクライブの登録

#aws sns subscribe --topic-arn arn:aws:sns:ap-northeast-1:*****:topic-name --protocol email --notification-endpoint hogehoge@example.com

{
    "SubscriptionArn": "pending confirmation"
}

→これで登録したメールの方にConfirmを求めるメールが来るので

　リンクをクリックしてConfirm完了。

SNSにパブリッシュのテスト

aws sns publish --topic-arn arn:aws:sns:us-west-2:****:my-topic --message "Hello World"

これでSubscriptionに登録したメールの方にHello Worldが来ていたので設定はOK。

AWS CLI での Amazon SNS の使用 - AWS Command Line Interface