Snyk IaCでインフラのドリフトと未管理リソースを検出
Stephane Jourdan
2022年5月9日
0 分で読めます廃止のお知らせ：管理対象リソースのドリフト検出
snyk iac describe --only-managed and snyk iac describe --driftを含む、管理対象リソースのドリフト検出は廃止されました。管理対象リソースのドリフト検出の提供終了日は2023年9月30日です。
開発者であれば、何らかのクラウドインフラプロバイダーを利用していることでしょう。また、インフラの一部をInfrastructure as Code（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の構造を反映できます。また、AWS、GCP、Azureなど主要なクラウドプロバイダーすべてで動作し、必要なアクセス権限は最小限です。
この記事では、Snyk IaCのドリフト管理で対処できる問題をいくつか紹介します。
クラウド環境におけるIaCのカバレッジを向上
機能やアプリケーションにおけるインフラのドリフトを把握
特定のクラウドサービス内のドリフトを検出
ドリフト管理のメリット
これは、1つのサービスと多数のリソースの物語です。例として、API Gatewayのデプロイを取り上げましょう。AWSでは、ウェブコンソール上で美しく統合された形で管理できます。一方Terraformでは、API Gatewayのバージョンによって10～25個のリソースに分かれています。メソッド、レスポンス、モデル、ルート、ステージなど、すべてが個別のリソースです。
既存のサービスをもとにTerraformコードを書き始める場合、未管理のTerraformリソースをクラウドサービス別・リソースタイプ別に分類した完全な一覧があれば、リソースがはっきり見えるようになり、各クラウドサービスの機能がTerraformでどう構成されているかを一つずつ調べるよりも、はるかに時間を節約できます。
TerraformでAPI Gatewayを管理していても、誰かが手動でルートやHTTPレスポンスを追加する可能性はあります。そして、それに誰も気づかないかもしれません。ドリフト検出 によってこうした変更を検出・報告し、不整合や設定上の問題が発生するリスクを軽減できます。
つまり、ドリフトを可視化する目的は次のとおりです。
コードのカバレッジを高め、デプロイ前にコードの設定ミスを分析できるようにする。
リソースの削除や変更の差し戻しなど、速やかに対処して、被害が発生する前に対応する。
IaCのカバレッジを向上
多くのチームと同じように、複数のチームで使用・共有している多数のTerraformリポジトリすべてを、まだ管理しきれていないかもしれません。では、Snyk IaCの未管理リソース検出はどのように機能するのでしょうか。
Snyk IaCは、入力されたすべてのTerraformステートを1つの大きな集約マップにまとめ、AWSアカウント上で検出した内容と比較します。その差分がドリフトであり、Terraformリソースとして報告されます。
Snyk IaCのdescribeコマンドで--only-unmanagedオプションを使うと、これを実現できます。
開発者は、この出力を簡単に活用できます。
まず、コードのカバレッジが44%だと把握できます。IaC化に向けた進捗を追いやすくなります。
Terraformに含まれていないS3バケット（タイプ：
aws_s3_bucket）が2つあり、名前も確認できます。これらをインポートするか削除するかを簡単に判断できます。IAMの設定にもいくつか不整合があります。
「labs」というIAMユーザーが手動で作成されています（タイプ：
aws_iam_user_policy）。このユーザーは何に使われているのでしょうか。「user1-84i30k」という管理対象のIAMユーザーに、「Administrator」アクセスポリシーが手動でアタッチされています（タイプ：
aws_iam_policy_attachment）。チームはその影響を理解しているでしょうか。IAMポリシー全体が手動で追加されています（タイプ：
aws_iam_user_policy）。誰かが変更した場合、その内容を誰が管理するのでしょうか。
前回のデプロイ以降の変更を把握
開発者によくあるもう1つのユースケースは、特定の範囲におけるドリフトの管理です。多くの場合、開発者はインフラの範囲が明確に定められた特定の機能を担当します。クラウドアカウント全体のフィードバックではなく、定義した範囲内で何が変更されたかを検出する必要があります。
まず、すべてのTerraformステートをSnyk IaCに入力し、欠落しているリソースや変更されたリソースを検出する方法があります。
このレポートから、次のような有益な情報が得られます。
使用するすべてのTerraformステートを集約しながら、対象範囲内のドリフト情報だけを取得できます。
各ドリフトや変更がどのTerraformステートで検出されたかが、レポートに表示されます。
必要なのはクラウドアカウントへの最小限のアクセス権限だけなので、この機能は手軽に利用できます。CI/CDのTerraformデプロイ用認証情報は、もう使わないでください。
クラウドサービス内の欠落リソースを検出
開発者として、より詳しく確認したいクラウドサービスが「S3」や「IAM」など1つだけの場合があります。その場合は、Snyk IaCのリソースフィルター（--filter="aws_resource_name"）を使用できますが、対象をすべて把握して一覧にし、常に更新し続ける必要があります。これは面倒です。そんなときは--serviceオプションを使えば、対象となるリソースの数を把握しなくても、サービス全体を指定できます。
このユースケースでは、AWS IAMサービス内で見つかったすべてのリソースがレポートされます。アクセスキー、グループ、アタッチメント、ポリシー、ロールなど、数十種類ものTerraformリソースを一度に簡単に網羅できます。
Snyk IaCでドリフト管理が可能に
IaCを使い始めたばかりの開発者でも、確立された高度なIaCワークフローを持つ経験豊富なチームの一員でも、Snyk IaCのドリフト管理を活用すれば、クラウドアカウントで実際に稼働しているものをより把握し、必要最小限のアクセス権限を活用して迅速に対処できます。
Snyk IaCのドリフト管理は、開発者のノートパソコン上でCLIを使って必要なときに実行できるほか、CI/CDパイプラインや定期的なcronジョブで実行し、対象を絞ったレポートを取得できます（v1.918.0以降）。
ドリフト管理はFreeプランを含むすべてのSnykプランで利用できます。今すぐInfrastructure as Codeのセキュリティを強化しましょう。
ソースコードの段階からインフラを保護
Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。