Terraform:自動化シナリオ - マルチアカウント自動化シナリオでの AccessKey ペア管理ソリューション

次のトランスクリプトを参照できます。

以下のトランスクリプトを参照できます。

Alibaba Cloud オープン プラットフォーム自動化シリーズ Auto Talk へようこそ。 オープン プラットフォーム チームのソリューションアーキテクト、Yaofang です。 このエピソードでは、マルチアカウント自動化シナリオ向けの ID 管理ソリューションをご紹介します。

コードを使用して Alibaba Cloud リソースを管理しようとしたことはありますか? アプリケーションを作成する場合、または Terraform のようなツールを自動化に使用する場合、3 つのステップを実行します。 まず、アプリケーションには ID が必要です。つまり、Alibaba Cloud API と対話するには AccessKey ペアが必要です。 次に、すべてのリソースはアカウント内に存在するため、アカウントが必要です。 3 番目に、Alibaba Cloud API を呼び出して、ECS インスタンスや OSS バケットなどのリソースを作成します。

アプリケーションの ID について話すとき、API を呼び出すためにアプリケーションが使用する認証メカニズムについて言及しています。 Alibaba Cloud は、認証のために 2 つの方法を提供しています。 1 つ目の方法は、AccessKey ペアと呼ばれる固定認証情報を使用する方法で、もう 1 つの方法は、STS トークンと呼ばれる一時的な認証情報を使用する方法です。 アプリケーションが AccessKey ペアを使用するか STS トークンを使用するかにかかわらず、いくつかの共通のリスクがあります。 たとえば、一部のお客様は Alibaba Cloud アカウントを使用して API を呼び出す場合がありますが、これは非常に高いリスクを伴います。

Alibaba Cloud アカウントの AccessKey ペアが漏洩した場合、損害を軽減するためのコストは非常に高くなる可能性があります。 あるいは、一部のユーザーは AccessKey ペアをコードに直接ハードコーディングする場合があります。 AccessKey ペアが漏洩した場合、アカウントに重大なリスクをもたらす可能性があります。

これらのリスクを考慮して、いくつかのベストプラクティスを確立しました。これらは 2 つの重要なポイントにまとめることができます。 1 つ目は、公開期間を最小限に抑えることです。 これはどういう意味でしょうか? たとえば、AccessKey ペアのような固定認証情報を使用する場合、定期的にローテーションしない限り、認証情報の有効期間は長くなる可能性があります。 開発者は、同じ AccessKey ペアを 1 年、2 年、あるいは 10 年も使用する場合があります。 この長期間の使用はリスクを高めます。 ただし、6 か月ごとなどの定期的なローテーションなどのポリシーを実装すれば、AccessKey ペアの有効期間を制限できます。 あるいは、本質的に有効期間が短い一時トークンを使用することもできます。

2 つ目のポイントは、公開範囲を最小限に抑えることです。 たとえば、テスト環境と本番環境では、すべての環境で単一の認証情報を使用するのではなく、異なる認証情報を使用できます。 一部のユーザーは、1 つの AccessKey ペアを使用してすべてのアプリケーションを管理することさえあります。 その AccessKey ペアが漏洩した場合の影響を想像してみてください。 すべてのシステムが影響を受けます。 前述のように、一時トークンにもクラウドにおけるベストプラクティスがあります。 たとえば、ECS を使用してアプリケーションを ECS インスタンスにデプロイする場合、ECS はインスタンスロールと呼ばれる機能を提供します。 これは、ECS インスタンスにロールを割り当て、特定のクラウドリソースを操作できるようにするものと考えてください。 このように、アプリケーションは AccessKey ペアを認識する必要はありません。 この ECS インスタンスにコードをデプロイするだけで、アプリケーションは必要な権限を取得します。 アプリケーションは AccessKey ペアに公開されないため、AccessKey ペアが漏洩するリスクはありません。 すべての認証情報は ECS インスタンス内で管理されます。 これが 1 つのアプローチです。 多くのお客様はマルチアカウント環境で運用しています。 マルチアカウント管理サービスに精通しているか、使用したことがあるかはわかりませんが、リソースディレクトリはアカウントツリーとして機能します。 たとえば、ビジネス A、ビジネス B、ビジネス C など複数のビジネスがあり、それぞれに A1、B1、C1 などの独自のアカウントがあるとします。 自動化された操作を実行する場合、運用アカウント C などの新しいクラウドアカウントを作成する場合があります。 このアカウントで、スクリプトまたはパイプラインを実行します。 たとえば、Jenkins をセットアップしたり、Apsara Devops を使用したりする場合があります。 パイプラインを実行するときは、アカウント A1 と B1 のリソースを操作する必要があります。つまり、これらのアカウントの ID と権限が必要です。 A1 に AccessKey ペアがあり、B1 に AccessKey ペアがある場合、AccessKey ペアが漏洩するリスクが高いことは想像に難くありません。 さらに、各アカウントの AccessKey ペアを管理すると、運用の複雑さとコストが増加します。

このような図を見て、企業がマルチアカウントシナリオで運用している場合は、このソリューションを強くお勧めします。 このソリューションを強くお勧めします。 このソリューションをご紹介します。 運用アカウントに ECS インスタンスを作成し、ロールを割り当てることができます。 このロールには、管理アカウント (いわゆるルートアカウント) など、他のアカウントのロールを引き受ける機能があります。 引き受けられたロールには、すべてのアカウントのリソースを管理するための権限があります。 重要なのは、このプロセス全体を通して、プレーンテキストの AccessKey ペアが関係しないことです。これは、このソリューションの重要な側面です。

このソリューションは、2 つの主要な機能を活用しています。 1 つ目は、リソースディレクトリの下にメンバーアカウントを編成するリソース管理ツリーです。 2 つ目の機能は、運用アカウントがロールを引き受ける必要があることです。

次に、このプロセスをデモします。 この図について簡単に説明します。 これは、典型的なマルチアカウントアーキテクチャを表しています。 企業には多くのアカウントがある場合があり、前述のように、運用アカウントは自動化アプリケーションを実行します。 また、本番アカウント A、B などもあります。 すべての自動化アプリケーションは、運用アカウント C 内で実行されます。 では、手順を見ていきましょう。

まず、運用アカウントに ecs-role という ECS ロールを作成します。 このロールには、STS の AssumeRole 権限があります。 その後、ECS インスタンスをこのインスタンスロールに関連付けることができます。 2 番目のステップでは、automation-assume などの管理アカウントにロールを作成します。 このロールには、リソースディレクトリに関連する権限と STS AssumeRole 権限があります。 次に、運用アカウントの ECS インスタンスのロールを構成し、ECS インスタンスに Alibaba Cloud CLI ツールをインストールして、一時的な AccessKey ペアを取得できるようにします。

それではデモを行います。 これが私たちのデモ環境です。 これがマルチアカウントツリーです。 現在、Alibaba Cloud アカウントを使用しています。 自動化アプリケーションを実行するために使用される運用アカウントを選択します。 ここではいくつかの操作手順の概要を説明しましたので、簡単に確認してみましょう。 まず、信頼できるエンティティタイプが Alibaba Cloud サービスで、名前が ecs-role であるロールを運用アカウントに作成し、このロールに STS を呼び出すために必要な権限を付与します。

2 番目のステップでは、信頼できるエンティティタイプが Alibaba Cloud アカウントであるロールを管理アカウントに作成します。 その信頼ポリシーにより、運用アカウントによって引き受けることができます。

3 番目のステップでは、運用アカウント内に ECS インスタンスを購入します。 この ECS インスタンスで、Alibaba Cloud アカウントの一時的な AccessKey ペアを取得できるかどうかを確認するための基本的な操作を実行します。 一時的な AccessKey ペアを取得したら、Alibaba Cloud SDK および API を呼び出したり、Terraform スクリプトを実行したりできます。 これらの手順をコンソールで実行する場合、このように表示されます。 これらの操作はすでに Terraform を使用してスクリプト化されています。

Terraform スクリプトを簡単に見てみましょう。 まず、運用アカウントにロールを作成し、適切な権限を付与します。 このステップでは、スクリプトはロールを作成し、必要な権限を割り当てます。

ステップ 2 には、管理アカウントに自動化ロールを作成し、その権限と信頼ポリシーを構成することが含まれます。 では、スクリプトを実行してみましょう。

少し待ちましょう。 はい、実行が完了しました。 では、リソースがアカウントに作成されたかどうかを確認しましょう。 現在、管理アカウントにいます。 ドキュメントによると、ロールが作成されているはずです。 ロールが存在するかどうかを確認しましょう。

ここにタイムスタンプが表示されます。午後 12 時 28 分。 これは、このロールが作成されたばかりであることを示しています。 このロールには、STS 権限とリソースディレクトリ管理権限の 2 つの権限が付与されています。 その信頼ポリシーにより、アカウント 463 (運用アカウント) によって引き受けることができます。 権限と信頼ポリシーの両方が正しく構成されています。 スクリプトが実行されます。

次に、運用アカウントに移動します。 ステップ 1 では、運用アカウントにロールが作成されているはずです。 ロール ecs-role が作成されているかどうかを確認しましょう。 作成時のタイムスタンプが一致していることがわかります。 ロールには必要な権限があり、その信頼ポリシーは ECS にリンクされています。

これは、Terraform スクリプトを実行した後、ステップ 1 と 2 を完了し、必要なリソースを作成したことを確認します。 運用アカウントには、ECS インスタンスがあります。 注意すべき重要なことの 1 つは、この ECS インスタンスを私たちが作成したロールにバインドする必要があることです。 このバインディングは不可欠です。バインディングがないと、ECS インスタンスは必要な権限を持ちません。 バインディングが完了すると、ECS インスタンスで Alibaba Cloud CLI コマンドを実行できます。 CLI については、公式ドキュメントを参照して、ECS インスタンスにインストールしてください。 これらのコード行を ECS インスタンスに貼り付けます。

出力をエコーしてみましょう。 取得された値は STS トークン、つまり一時キーであることがわかります。 この一時キーは管理アカウントに属しています。 この一時キーを使用すると、このアカウント内のリソースを操作でき、権限は非常に広範です。 これは、マルチアカウント設定では、運用アカウントで ECS インスタンスを購入し、ECS インスタンスからすべてのスクリプトを実行できることを示しています。 このプロセス全体を通して、プレーンテキストの AccessKey ペアは公開されません。 すべては一時キーを介して行われ、セキュリティが大幅に向上します。 以上で実践的なデモは終わりです。

これでこのエピソードのコンテンツは終わりです。 クラウドの自動化について質問やアイデアがある場合は、以下の QR コードをスキャンして DingTalk グループに参加して詳細な説明を受けるか、お問い合わせください。 ご清聴ありがとうございました。次のエピソードでお会いしましょう。