Snyk IaC によるインフラのドリフトとアンマネージドリソースを検出する

開発者であれば、何らかのインフラのクラウドプロバイダーを利用しています。また、インフラの一部を IaC を使用して自動化することで、導入を繰り返して、一貫性を保ち、簡単に導入できるようにするだけでなく、コードによってパラメーターの可視性を高めることができるため、セキュリティを強化できます。

最終的には、クラウドプロバイダーにすべてのライブリソースを上げることになりますが、現在の状態については、把握している場合もあれば、把握していない場合もあります。S3バケットの設定が手動で変更されていますか？同僚が API Gateway の導入で新しいパスを作成しましたか？一部のデフォルトのリソースに設定ミスが生じている可能性がありますか？最終的には、クラウドプロバイダーのアカウントで Terraform 導入にリソースがまったく検出されないか、変更されている、あるいは完全に削除されているという状態が発生することになります。クラウドリソースの設定と実際に設定されている内容との相違はインフラのドリフトと呼ばれています。

現在、Snyk Infrastructure As Code (Snyk IaC) はすべてのタイプのインフラドリフトを検出でき、Terraform リソースとして報告できるため、開発者には完全な可視性が得られ、早期に対策を実施できます。これには、「マネージド」リソース (IaC から実際に導入されたリソース) と「アンマネージド」リソース (IaC で管理していないリソース) の変更や削除が含まれます。  Snyk CLI が生成するレポートは、端末から直接読み取ったり、パイプラインや定期的なチェックに統合したり、他のユーザーと共有するために HTML としてエクスポートしたりできます。

Snyk ではすべての Terraform 状態をサポートしており、ファイルは Amazon S3、GCS、Azure、HTTPS、Terraform Cloud など、すべての BLOB ストレージにローカルに保存されます。複数のチームで複数の Terraform リポジトリが存在している場合でも、一元化されたモデルがある場合でも、ストレージを組み合わせて IaC の構造を反映できます。  最後の点として、Snyk は AWS、GCP、および Azure などの主要なクラウドプロバイダーすべてにおいて最小限のアクセス権限で動作します。

このブログでは、Snyk IaC のドリフト管理で対処できる以下のような問題のいくつかについて説明します。

• クラウド環境における IaC カバレッジの拡大

• 機能またはアプリケーションでのインフラのドリフトの通知

• 特定のクラウドサービスでのドリフトの検出

ドリフト管理のメリット

ドリフト管理には、1 つのサービスと多数のリソースが関係します。簡単な例として、API Gateway の導入を見てみましょう。AWS では、エクスペリエンスが Web コンソール内に正しく統合されています。Terraform では、API Gateway のバージョンに応じて 10 ～ 25 個のリソースに分割されます。メソッド、レスポンス、モデル、ルート、ステージなど、すべてが異なるリソースになります。

これは、既存のサービスから Terraform コードを記述し始める場合、クラウドサービスとリソースタイプによってカテゴリ分けされたアンマネージド Terraform リソースの完全なリストが用意されていることで、可視性が非常に高くなり、Terraform でクラウドサービスの機能の構成を一つひとつ確認する場合と比べて大幅に時間を節約できるということです。

もしすでに API Gateway が Terraform で管理されている場合、手動によるルートや HTTP レスポンスの追加を防ぐことはできません。また、それは誰にも通知されません。ドリフト検出により、これらの変更が検出され、報告されることが保証され、潜在的な不整合や設定の問題が緩和されます。

つまり、ドリフトを可視化する理由は以下のとおりです。

• コードカバレッジを改善し、導入前にコードの設定ミスを分析できるようにする。

• ただちにアクションを実行して、損害が発生する前に、リソースを削除したり、変更を元に戻したりする。

IaC カバレッジを拡大する

一般的には、多数の Terraform リポジトリがある中で、現在使用していて、チーム間で共有しているものをすべてカバーしきれていない、という状況が見られます。では、Snyk IaC を使うと、アンマネージドリソースをどのように検出できるのでしょうか？

Snyk IaC は、フィードされたすべての Terraform 状態を 1 つの大きな集約マップに結合し、AWS アカウントで検出されたものと比較します。その違いがドリフトとなり、Terraform リソースとして報告されます。

Snyk IaC describe を --only-unmanaged オプションで使用することで、まさにこれを実現できます。

1$ snyk iac describe --only-unmanaged
2[...]
3Snyk Scanning Infrastructure As Code Discrepancies...
4
5  Info:    Resources under IaC, but different to terraform states.
6  Resolve: Reapply IaC resources or update into terraform.
7
8Unmanaged resources: 5
9
10Service: aws_iam [ Unmanaged Resources: 3 ]
11
12  Resource Type: aws_iam_policy_attachment
13    ID: user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
14
15  Resource Type: aws_iam_user
16    ID: labs
17
18  Resource Type: aws_iam_user_policy
19    ID: dat-user:manuals3policy
20
21Service: aws_s3 [ Unmanaged Resources: 2 ]
22
23  Resource Type: aws_s3_bucket
24    ID: manual-bucket-2022
25    ID: test-resource-exposure-caxyxllsajfrzbwe
26
27Test Summary
28
29  Managed Resources: 4
30  Unmanaged Resources: 5
31
32  IaC Coverage: 44%

開発者は、この出力を簡単に利用できます。

• まず、コードカバレッジが 44% と認識することで、IaC への移行の進捗状況が把握しやすくなります。

• Terraform にない S3 バケット (タイプ: aws_s3_bucket) が 2 つあり、それぞれ名前が挙げられています。インポートするか、削除するかを簡単に選択できます。

• IAM の設定にはいくつかの矛盾があります。 

  • IAM ユーザー「labs」が手動で作成された (タイプ: aws_iam_user_policy)。このユーザーは何をしているのでしょうか？

  • 「管理者」アクセスポリシーがマネージド IAM ユーザー「user1-84i30k」に手動でアタッチされた (タイプ:aws_iam_policy_attachment)。この結果についてチームは把握していますか？

  • 完全な IAM ポリシーが手動で追加された (タイプ: aws_iam_user_policy)。誰かが内容を変更した場合、誰が管理を担当しますか？

前回の導入以降の変更点を通知する

もう一つ、開発者にとって一般的なユースケースとして、特定のスコープ内でのドリフト管理があります。多くの場合、開発者は、非常に明確に定義されたインフラのスコープで特定の機能を担当します。このような場合、クラウドアカウント全体のフィードバックを得るのではなく、定義した範囲内で何が変わったかを検出する必要があります。

これは、単にすべての Terraform 状態を Snyk IaC に入力し、不足しているリソースや一部が変更されているリソースを検出する最初の機会です。

1$ snyk iac describe --only-managed
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Changed resources: 1
8
9State: tfstate://terraform.tfstate [ Changed Resources: 1 ]
10
11  Resource Type: aws_s3_bucket
12    ID: somebucket-84i30k
13    ~ versioning.0.enabled: false => true
14
15Missing resources: 1
16
17State: Generated [ Missing Resources: 1 ]
18
19  Resource Type: aws_iam_policy_attachment
20    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
21
22Test Summary
23
24  Managed Resources: 3
25  Changed Resources: 1
26  Missing Resources: 1
27
28  IaC Coverage: 75%

このレポートには、興味深い内容が記載されています。

• 使用するすべての Terraform 状態を集約できるが、ドリフト情報はその範囲に対してのみ取得できる。

• レポートではドリフトや変更がそれぞれどの Terraform 状態で発見されたかが表示される。

• この機能は軽量で、クラウドアカウントで最小限のアクセス権しか必要としない。CI/CD Terraform の導入資格情報はこれ以降、決して使用しないこと。

クラウドサービス内で不足しているリソースを検出する

開発者として、一つのクラウドサービスについて、詳細に調べたい場合もあるでしょう。たとえば、「S3」や「IAM」などです。Snyk IaC のリソースフィルター (--filter="aws_resource_name") を使用することもできますが、そのためには全部把握してリストアップし、リストを常に更新していく必要があります。これでは大変です。関係するリソースの数がわからない場合でも、--service オプションを使うことでサービス全体を含めることができます。

1$ snyk iac describe --only-managed --service=aws_iam
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Missing resources: 1
8
9State: Generated [ Missing Resources: 1 ]
10
11  Resource Type: aws_iam_policy_attachment
12    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
13
14Test Summary
15
16  Managed Resources: 2
17  Missing Resources: 1
18
19  IaC Coverage: 66%
20  Info: To reach full coverage, remove resources or move it to Terraform.

今回のユースケースでは、AWS IAM サービスで見つかったすべてのレポートを取得しています。簡単に数十の Terraform リソース (アクセス キー、グループ、アタッチメント、ポリシー、ロールなど) を一度にカバーできます。

Snyk IaC でドリフト管理が利用可能に

IaC を使い始めたばかりの開発者から、洗練された IaC ワークフローを確立した経験豊富なチームメンバーに至るまで、Snyk IaC のドリフト管理は、実際にクラウドアカウントで実行されているリソースの可視化を高め、最小限のアクセス権限ですばやく対策を講じるのに役立ちます。

Snyk IaC ドリフト管理は、CLI により開発者のローカルのパソコンからオンデマンドまたは CI/CD パイプライン上で実行するか、cron ジョブをスケジュール設定して実行することにより、情報を集約したレポートを取得できます (v1.918.0 以降)。

ドリフト管理は、無料プランを含むすべての Snyk プランでご利用いただけます。今すぐ IaC のセキュリティを確保しましょう。