AWSに関する操作をコマンドで実行する時にアクセスキーは頻繁に使われていた。
そのアクセスキーが漏洩することによりAWSの不正利用が行われるリスクがある。
なので、AWSとしてもアクセスキーの利用を推奨していない。
にもかかわらず、一部のツールはアクセスキーの利用を当たり前のようにしている。
AWS内はIAMロールを利用するのが基本。
ではAWS外は??
最近だとIAM Roles Anywareなるサービスがリリースされたけど、Private CAが必要で証明書の管理が結構手間。
別の方法として、ジャンプアカウントのIAMユーザーでアクセスキーを発行して、スイッチロールすることでワンクッション置いているけどもなんかモヤモヤw
アクセスキーと一緒にIAMロール名やジャンプ先のアカウントIDが一緒に漏れると意味がないw
ジャンプアカウントでのやり方は以前にブログ記事に書きますた。
OCIのサーバからAWS S3へファイルをアップロード。(aws s3 sync)スイッチロールを添えて。
AWSたのしいよおおおおおおおおん
ということで、第3の方法としてAWS外でもIAMロールを利用する(=アクセスキーを利用しない)方法を紹介。
Systems Manager Agentをインストールして、アクティベーションするだけです。
詳細はAWSのマニュアル参照。
というわけで、実際にやってみました。
構成は↑と同じです。
Oracle Cloud上のUbuntuサーバからAWSにアクセスする想定。
IAMロール、IAMポリシー作成
AWS外のサーバに付与するIAMロールおよびIAMポリシーを作成。
今回はS3しか利用しないので、IAMポリシーは省略。
IAMロールだけ作成する。
IAMロールの作成画面で、信頼されたエンティティタイプは「Systems Manager」を選択。
許可ポリシーは「AmazonSSMManagedInstanceCore」は絶対必須。
あとは許可させたいAWSの操作に応じたポリシーを追加する。
※ここではAmazonS3FullAccessを追加してる。
適当なロール名(OnPremissSSMInstanceProfileなど)を設定してIAMロール作成。
以上でIAMロール作成完了。
Systems Managerでアクティベーション
Systems Managerにノードとして追加する。
Systems Managerより「ハイブリッドアクティベーション」を選び、「アクティベーションを作成する」をクリック。
アクティベーション設定を行う。
ここでは制限をデフォルトの"1"から"100"に変えているが、1つのアクティベーションに登録できる数の話なので
デフォルトのままでいいかもw
重要なのは下のIAMロールで先ほど作成したIAMロールを指定する。
アクティベーションを作成したら、コードおよびIDが表示されるのでメモしておく。
Systems Manager Agentをインストールおよび登録
AWS外のサーバにSystems Manager Agentをインストールする。
インストール方法は以下。
登録時に↑で表示されたアクティベーションコードおよびアクティベーションIDが必要になる。
Linux:https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-install-managed-linux.html
Windows:https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-install-managed-win.html
OracleCloudのArm版Ubuntuだけど普通にインストールができた。
SSM Agentのログを確認し、以下の通り"Successfully registered"と表示されていればOK。
Systems Manager側にも作成したアクティベーションのところに登録済みインスタンスの数が増えているはず。
アクセスキー無しでAWS CLIコマンドが使えるが注意点もある
SSM Agentがインストールされ登録されると、
クレデンシャルファイルが30分おきに自動更新される。
が、クレデンシャルファイルのユーザーはLinuxの場合はrootになる。
Windowsならシステムだったかな?
なので、AWS CLIコマンドはrootユーザーだけがアクセスキー無しで実行できる。
まぁーsudoコマンドをつければ一般ユーザーでも同じことができるので大した影響はないかな。
もしくは/root/.aws/credentialsに読み取り権限を付与してもいいか。
俺の場合は面倒なのでsudoにしたけど。
SSM Agentを追加でインストールする必要が出てくるが、
AWS外の環境下でもアクセスキーを意識することなく必要最小限の権限でAWS CLIを実行できるのは大きい。
IAM Roles Anywareより気軽に実装できるので
特に細かなセキュリティ要件じゃなければこの方法でいいんじゃないかなと。
また一つAWSについて詳しくなりました(・∀・)
0 件のコメント:
コメントを投稿