OpsCLI ® Advanced Compute Operation

OpsCLI: ハンズオン環境構築ガイド

ハンズオン環境構築ガイドの目的

本ガイドは、このガイドを閲覧している皆様に、OpsCLIのハンズオンを最後まで完遂できるために必要十分な環境についてご理解いただき、ハンズオン環境の構築および破棄をスムーズに実施できるようになっていただくことを目的に公開しています。

AWS CLIの利用形態

AWS CLI (AWSコマンドラインインタフェース)は、AWSのサービスを管理するための統合ツールです。

OpsCLIのAWSハンズオンは、AWS CLIの使用を前提としており、全ての受講者の方が最後まで躓くことなく完遂できるように構成しています。

AWS CLIは多様な環境で利用可能

AWS CLIは、主に以下の環境で利用することができます。

ブラウザ環境 (推奨)

現在主流のブラウザ(Firefox、Chrome、Edge、Mac版Safari)をサポートしており、実行するコンピューター環境に依存せずにAWS CLI(Linux版)を実行することができます。

実行環境依存のトラブルがほとんど無く、AWSの有償サポートも手厚いため、通常利用では最もお勧めの環境となります。

[利用パターン例]

  • Cloud9 (EC2インスタンス環境)

  • CloudShell (コンテナ環境)

Unixシェル

UnixサーバやUnix系クライアントPC(MacOS, Linuxなど)上のUnixシェルでAWS CLIを実行することができます。

スクリプトによるAWS CLIの実行など、特定の用途において使用することがあります。 (サーバ環境やクライアント環境で生成したデータを直接AWSに送信する、など)

実行環境依存のトラブルを自力で解決できる必要があります。

[利用パターン例]

  • Linux環境 (EC2インスタンス、オンプレミスサーバーなど)

  • MacOS環境 (iMac、MacBook など)

Windowsコマンドライン

WindowsサーバやWindowsクライアントPC上のコマンドプロンプロトやPowerShellでAWS CLIを実行することができます。

実行環境依存のトラブルを自力で解決できる必要があります。

注釈

OpsCLIのハンズオンでは、ブラウザ環境のLinux版 AWS CLIを想定しています。

(Windows版、MacOS版のAWS CLIや、ブラウザ以外の環境の使用を想定していません。学習のサポート外となります。)

AWS CLIの利用形態

Linux版 AWS CLIの利用形態として、一般的に以下のものを想定することができます。

../_images/guide-env-figure-type-overview.png
IAMユーザーの永続的な認証情報をAWS外部で使う形態

IAMユーザーの永続的な認証情報(アクセスキー)をAWSの外部(オンプレミスサーバやクライアントPCなど)に持ち出し、AWS外部でAWS CLIを実行する形態です。

  • オンプレミスサーバー

  • クライアントPC

IAMユーザーの永続的な認証情報をAWS内部で使う形態

IAMユーザーの永続的な認証情報(ログインプロファイル: マネジメントコンソールのパスワード)をAWSの外部(クライアントPCなど)に持ち出し、ブラウザ経由でAWS CLIを実行する形態です。

  • CloudShell (IAMユーザー権限で実行する場合)

IAMロールの一時的な認証情報を使う形態

AWS内部で、一時的な認証情報により、AWS CLIを実行する形態です。

  • CloudShell (スイッチロールなどをして、IAMロール権限で実行する場合)

  • Cloud9 (Cloud9環境に付与したIAMロール権限で実行する場合)

  • EC2インスタンス (EC2インスタンスに付与したIAMロール権限で実行する場合)

ハイリスクな利用形態

これらの形態のうち、「IAMユーザーの永続的な認証情報」を利用する形態は、原則としては利用しないことをお奨めいたします。

  • IAMユーザーの永続的な認証情報をAWS外部で使う形態

  • IAMユーザーの永続的な認証情報をAWS内部で使う形態

../_images/guide-env-figure-type-risk-high.png

IAMユーザーに強い権限を付与し、IAMユーザーの数が多い場合、永続的な認証情報の漏洩が、即時に大きなインシデントに直結し得ます。 特に、インタラクティブな操作を想定しているIAMユーザーは、幅広く強い権限を付与されがちなため、その認証情報の漏洩は、大きなダメージとなります。

「IAMユーザーの数」と「IAMユーザーの権限の強さ」が「永続的認証情報の漏洩リスク」の大きさに比例することは意識していただきたいと考えています。

IAMユーザーでのAWS CLIの利用はスクリプトの実行用途のみとし、その権限もスクリプト実行に最低限必要なものに限定する「最小権限の原則」の遵守を大前提としましょう。

(例: 実行内容は全てLambda関数に実装し、そのinvoke権限のみスクリプトに渡す、など。)

重要

AWS CLIのインタラクティブな操作を、IAMユーザーで行うことは、現在ではアンチパターンになっています。

ローリスクな利用形態

今日のAWS CLI利用において、インタラクティブなAWS CLI操作は、IAMロール権限によって行うことが大原則となります。

IAMロールは一時的な認証情報を利用するため、万が一その認証情報が漏洩しても、デフォルト設定で1時間(最大でも12時間)で失効してしまいます。 更に、IAMロールの利用環境が堅牢であれば、IAMロールから一時的な認証情報が漏洩すること自体が困難になります。

../_images/guide-env-figure-type-risk-low.png
CloudShell

マネジメントコンソール上のスイッチロールやAWS APIのsts AssumeRoleアクションなどにより、IAMロールを利用する状態にして、CloudShellでAWS CLIを操作します。

CloudShellのコンテナ環境から意図的に一時的な認証情報を取り出さない限り、認証情報が漏洩することはありません。

Cloud9

IAMロール権限を付与したCloud9環境でAWS CLIを操作します。

Cloud9のEC2インスタンスから意図的に一時的な認証情報を取り出さない限り、認証情報が漏洩することはありません。

EC2インスタンス

IAMロール権限を付与したEC2インスタンスでAWS CLIを操作します。

EC2インスタンス環境の場合、以下の経路で、IMDS(インスタンス メタデータ サービス)から一時的な認証情報が漏洩するリスクがあります。

  • 不正にログインして、EC2インスタンスのIMDSから一時的な認証情報を取得される場合。 (SSH秘密鍵の漏洩など)

  • EC2インスタンスのIMDSに、外部からアクセスできる状態になっている場合。 (プロキシー設定のミスなど)

外部からのアクセスに対しては、IMDSのバージョン1(リクエスト/レスポンスメソッド)を無効にし、バージョン2(セッション志向メソッド)のみを利用することで回避できるようになります。

重要

AWS CLIのインタラクティブな操作は、IAMロールの権限で行うことが、現在のベストプラクティスとなっています。

まとめ

OpsCLIのハンズオンは、原則として、IAMロールの権限で行います。

AWS CLIの実行環境のポイント

OpsCLIのハンズオンでは、原則として、IAMロールの権限で行うため、Cloud9とCloudShellを併用します。

ここでは、Cloud9とCloudShellの特徴と、使い分けについて解説します。

比較: Cloud9 vs. CloudShell

Cloud9、CloudShell、それぞれの特徴は以下のようになっています。

../_images/guide-env-figure-cloud9_vs_cloudshell-diff.png
動作環境

Cloud9は、EC2インスタンス環境で動作します。 このため、Cloud9環境の稼動時間に応じて、EC2インスタンス料金が掛かります。 EC2インスタンスのスペックをフルで利用できるため、安定した動作が期待できます。

CloudShellは、コンテナ環境で動作します。 コンテナ環境の利用は無料ですが、月あたりの実行上限時間があります。(上限時間は非公開) レスポンスが遅くなったり、タイミングによって変数が消えたりする場合があるなど、Cloud9環境と比較して不安定な面が多いことは否めません。

使用開始時の待機時間は、どちらも1分程度と大きな違いはありません。

動作権限

いずれの環境についても、IAMロールに切り替えて使用することを推奨します。

Cloud9は、IAMロールの設定を一度行うことで、永続的にIAMロールを利用する形態になります。

CloudShellは、スイッチロールしている間のみ、そのIAMロールを利用する形態になります。

ストレージ

Cloud9は、EC2インスタンスにアタッチされているEBSボリュームをストレージとして使用します。 通常のEBSボリューム料金が掛かります。 EBSボリュームは永続的なストレージであり、自動的にデータが消えることはありません。 また、通常のEC2インスタンスを利用しているため、EBSボリュームの増設や拡張も可能です。

CloudShellは、無料で1GBの永続的なストレージが提供されます。 CloudShellのストレージは、増設や拡張不可能で、同一リージョンのCloudShellについて120日間利用が無いと消去されてしまいます。

セッション時間

Cloud9は、クールダウン設定(デフォルト30分)を無効にした場合は、セッション時間に制限はありません。

CloudShellは、概ね20分程度(連続実行をしている場合、12時間まで)がセッション時間の上限になります。

結論: Cloud9 vs. CloudShell

これらの特徴から、CloudShellは短時間で終わる確認や検証に向いており、それ以外の用途にはCloud9が向いていると言うことができます。

また、Cloud9環境が未構築である場合のAWS CLI作業や、Cloud9環境の構築や破棄を行うには、CloudShellは不可欠である、と言えます。

重要

Cloud9環境の構築・破棄や、短時間で終わる確認・検証作業は、CloudShellが向いています。

それ以外の用途には、Cloud9が向いています。

Cloud9とCloudShellの使い分け

OpsCLIのハンズオンにおいては、以下のようにCloud9とCloudShellを使い分けます。

../_images/guide-env-figure-cloud9_and_cloudshell.png
CloudShell

Cloud9環境の管理 (環境構築、権限管理、環境破棄)

Cloud9

ClousShellで行うこと以外全て (ハンズオン本編、クリーンアップなど)

Cloud9の構成要素

Cloud9の標準構成は、以下の図のようになっています。

../_images/guide-env-figure-cloud9-default.png

ハンズオン構成

OpsCLIのハンズオン環境では、標準構成について以下の変更を行います。

../_images/guide-env-figure-cloud9-custom.png
  • Cloud9環境における権限

    • AMTCを無効にします。

    • EC2インスタンスに、(インスタンスプロファイル経由で)IAMロールをアタッチします。

      IAMロールにアタッチされているポリシーの権限が、Cloud9環境の権限になります。

  • Cloud9 IDE (画面環境)

    • マネジメントコンソールへのサインインを保護するために、MFAデバイスの使用をIAMユーザーに強制します。

    • Cloud9環境にアタッチされているIAMロールに対して権限の追加・剥奪をする権限を、IAMユーザーに付与します。

      (ハンズオンの利便性向上が目的です。)

Cloud9の構築手順

Step1: ハンズオン環境を準備する方向け

../_images/guide-env-figure-diagram-build-root_cfn.png

Step2: ハンズオン環境を実際に利用する方向け

../_images/guide-env-figure-diagram-build-iam.png

Step3: ハンズオン環境の動作確認

Cloud9の停止・破棄手順

Step1: ハンズオン環境が不要になった方向け

../_images/guide-env-figure-diagram-cleanup-iam.png

Step2: ハンズオン環境が長期に不要になった方向け

../_images/guide-env-figure-diagram-cleanup-root_cfn.png