Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Terraform cloudへのSnyk integration

Terraform cloudへのSnyk integration

SnykはモダンなAppStack(ソースコード、OSS、コンテナ、IaCなど)の脆弱性をスキャンするツールです。Terraform CloudのRuntaskで簡単にSnykと連携し、今日からTerraformコードの設定ミスや脆弱性をチェックしましょう。

masatomo-ito2

August 25, 2022
Tweet

Other Decks in Programming

Transcript

  1. Masa Ito Sr. Soluiton Engineer @unagi_ga_suki • 2022年5月〜 Snyk •

    それ以前はHashiCorpにおりました • DevOps, DevSecOps, AppSec, DevSec, etc
  2. Snyk は 迅速な開発とセキュリティの両立を支援 顧客数 1800+ 従業員数 1450+ テスト回数 (四半期) 332M+

    (3.7M/day) 資金調達総額 $850M 本社 : ボストン、米国 設立 : 2015年 PROTECTED BY SNYK
  3. クラウドへの変化に伴い、開発者の責任範囲が拡大 Pre-cloud IT Security - Centralized Cloud AppSec - Decentralized

    App code Security IT Apps (Dropbox, Email) Open Source Library Network Servers, VM’s Hardware App code Open Source Library OSS Platform / Apps Cloud / SaaS Services Containers VPC, Service Mesh Kubernetes Cloud Developers IT / Operations Dev Ops Services Growing Developer Role Shrinking IT/Ops Role 分散化するセキュリティにより、 脆弱性が今まで以上にクリティカルに Security
  4. クラウド時代のアプリケーション リスクの潜む場所 Open Source Libraries Containers App Code IaC 脆弱性の80%は間接的な依存関係で見つかる

    数百におよぶLinuxパッケージがコンテナには含まれて おり、そこから多数の脆弱性が引き継がれる クラウドでの脆弱性発生原因 第1位は設定ミス [米国 NSA] 頻繁なデプロイ - ウォーターフォールでは追いつ けない。スキャンに何時間もかけられない コードベースの 10-20% コードベースの 80-90%
  5. クラウド時代のアプリケーション リスクの潜む場所 Open Source Libraries Containers App Code IaC Snyk

    Code Snyk IaC Snyk Open Source Snyk Container 対象:プログラミング言語 C#, Go, Java, JS, Python, PHPなど 対象:パッケージマネージャ npm, nuget, maven, pipなど 対象:コンテナイメージ DockerFile, Registry (DockerHub, ECR, ACR), K8s連携など 対象:IaC Terraform, CloudFormation, ARM, K8s manifest など
  6. クラウド時代のアプリケーション リスクの潜む場所 Open Source Libraries Containers App Code IaC Snyk

    Code Snyk IaC Snyk Open Source Snyk Container 対象:プログラミング言語 C#, Go, Java, JS, Python, PHPなど 対象:パッケージマネージャ npm, nuget, maven, pipなど 対象:コンテナイメージ DockerFile, Registry (DockerHub, ECR, ACR), K8s連携など 対象:IaC Terraform, CloudFormation, ARM, K8s manifest など
  7. CI/CD (CLI, API) Git repository (SCM) Traditional/PaaS Serverless Production Snyk

    IaC 実行例 Registry deploy Security gate Code (CLI, IDE) Test & fix Test, fix, monitor Kubernetes Monitor & more... Test, fix, monitor コードのチェックイン・マージ: ローカル環境で IaCのMiscofigurationや ポリシー違反を検知 継続的な自動スキャン: Git RepoにあるIaCを継続的にスキャン Provisioning: CI/CDパイプラインなどで Provisioningする際に Misconfigurationやポリシー違 反を検知 新しい脆弱性の検出時には アラート発出・JIRA Issueの自動作成
  8. VS Code IntelliJ Azure Repos GitLab Bitbucket Cloud Bitbucket Server

    Concourse Jenkins Azure Pipelines TeamCity Cloud Foundry VMWare Tanzu Heroku Artifactory micro focus Coding Source Control CI/CD Runtime Snyk CLI AWS Code Pipeline Kubernetes Snyk API Issue Management Eclipse Docker Hub Docker & others AWS Lambda IBM Cloud Registries Slack Jira Azure Functions BitBucket Pipelines CircleCI Snyk API GitHub GitHub Enterprise npm Enterprise Private Registry PyCharm WebStorm PhpStorm GoLand RubyMine Visual Studio 2019 Docker buildah Harbor Quay Amazon ECR Azure Container Registry Google Container Registry RedHat Openshift RiskSense Kenna Security Nucleus Security Vulcan Brinqua Fortify SSC 数多くの開発ツールと連携 Terraform Cloud GitHub Actions
  9. Securing against industry best practices and CIS benchmarks https://snyk.io/security-rules 業界のベストプラクティスのルール

    セット (Terraform, Cloud Formation, ARM, K8s) CISベンチマークとSnykセキュリティ エンジニアによる脅威モデリング研究 のルールセットを拡張 Open Policy Agent (OPA) / Regoによるカスタムポリシー
  10. Snyk IaCは何を解析するのか? 解析対象 → .tfコンフィグもしくは.tfplan • .tfコンフィグ (Terraform file) ◦ HCL2で記述されたIaC ◦

    Snyk IaCはデフォルトでは実行ディレクトリ以下にある全ての .tfコンフィグを解析 ◦ Moduleも含めて解析する場合は予め terraform initを実行して対象のModuleのコンフィ グをダウンロードしておく ◦ 環境変数や -var で指定される変数を補間した解析は出来ない • .tfplan ◦ Terraform planのアウトプットを解析 ◦ Moduleも含め全ての情報が入っている ◦ 変数の補間もすでにされている ◦ もっとも精度の高い解析が可能 terraform plan -out=tf.tfplan terraform show -json tf.tfplan > tfplan.json snyk iac test tfplan.json
  11. Terraform run tasks integration Terraform run tasksとは? • https://www.terraform.io/cloud-docs/workspaces/settings/run-tasks •

    Terraform cloudのRun実行中に3rd partyツールのサービスなどを呼び出す仕組み Snyk integrationとは? • Terraform planが成功した後、RunTaskによりSnykの解析が走る • Tfplanに対して解析するので精度の高い解析が可能 • Snyk解析結果に応じてTerraform Runの制御が可能 PLAN POLICY COST RUN TASK APPLY Terraform Run
  12. Usecases ◦ Snykはデフォルトのルールセットだけでも数百を超える設定ミスやセキュリティルールを解析し ます ▪ https://snyk.io/security-rules/ ◦ ただ、上記以外の会社独自のルールであったり、非機能要件などのチェックをすることで更なる コンプライアンスの強化をしたいケースもあります。 ▪

    間違ったRegionにデプロイしようとしていないか? ▪ 環境に応じたインスタンスやスペックが守られているか? ▪ かならず規定の時間内にデプロイが実行されているか? ▪ 特定のTagがきちんと付いているか?(”Owner”, “TTL”, “Billing” など) ▪ 会社規定のコンテナレジストリのものを使っているか? ▪ などなど ◦ バラバラでチェックするのではなく、一つの場所で全て解析したい ◦ こういった期待に沿うのが SnykのCustom Ruleになります
  13. Parsing resource "aws_redshift_cluster" "example" { cluster_identifier = "tf-redshift-cluster" database_name =

    "mydb" node_type = "dc1.large" cluster_type = "single-node" } example.tf apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: example image: example:latest securityContext: privileged: true } example.yml { "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "example" }, "spec": { "containers": [{ "image": "example:latest", "name": "example", "securityContext": { "privileged": true } }] } } output {   "resource": {     "aws_redshift_cluster": { "example": {   "cluster_identifier": "tf-redshift-cluster",   "cluster_type": "single-node",   "database_name": "mydb",   node_type": "dc1.large" }     }   } } output
  14. Parsing resource "aws_redshift_cluster" "example" { cluster_identifier = "tf-redshift-cluster" database_name =

    "mydb" node_type = "dc1.large" cluster_type = "single-node" } example.tf apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: example image: example:latest securityContext: privileged: true } example.yml { "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "example" }, "spec": { "containers": [{ "image": "example:latest", "name": "example", "securityContext": { "privileged": true } }] } } output {   "resource": {     "aws_redshift_cluster": { "example": {   "cluster_identifier": "tf-redshift-cluster",   "cluster_type": "single-node",   "database_name": "mydb",   node_type": "dc1.large" }     }   } } output RegoにおけるNotation input.resource.aws_redshift_cluster.example.node_type RegoにおけるNotation input.spec.containers[0].securityContext.privileged
  15. Ruleの作成 • RuleはRego( “ray-go”と発音)で記述します ◦ https://www.openpolicyagent.org/docs/latest/policy-language/ package rules deny[msg] {

    resource := input.resource.aws_redshift_cluster[name] not resource.tags.owner msg := { "publicId": "my_rule", "title": "Missing an owner from tag", "severity": "medium", "msg": sprintf("input.resource.aws_redshift_cluster[%s].tags", [name]), "issue": "", "impact": "", "remediation": "", "references": [], } } example.rego Rule条件を記述 この例では: 「ownerというTagがついているかどうか?」 Ruleに当てはまった場合の挙動 deny | allow 検知した場合に Snyk IaCで扱う際の Attributes name変数にRuleに当てはまった Resource名 が返る
  16. Managed (ドリフト)検知とUnmanaged検知 Managed (ドリフト)検知 • Stateファイルと実際のインフラのドリフトを検知・報告 Unmanaged検知 • Terraformで定義されていない( Stateファイルに存在しない)リソースを検知・報告

    Terraform Cloudで管理しているリソースのドリフト検知 snyk iac describe --drift snyk iac describe --only-unmanaged snyk iac describe --drift \ --from="tfstate+tfcloud://ws-bS3c8FFMf2KkFmwe" \ --tfc-token="=GUYddVLQ.atlasv1.D5K・・・" \ --tfc-endpoint="https://app.terraform.io/api/v2"
  17. Cloud infra Resource B Resource A Resource C Resource D

    Resource E Managed (ドリフト)検知 1 State file Cloud infra Resource B’ Resource A Resource C Resource D Resource E 2 State file modify Cloud infra Resource B’ Resource A Resource C Resource D Resource E delete 3 State file Resource Bに変更がありますよ Resource Dが無いですよ Cloud infra Resource B Resource A Resource C Resource D Resource E 4 State file Stateとインフラが Sync Stateとインフラが Out-of-Sync ドリフト検知により差分を検出 アラートをあげる ドリフト内容に合わせて適切なアク ションを行う ・Stateのアップデート ・Terraform Apply ・要らないものは Configから削除 ・など 復旧 • Consoleからの手作業での変更 • CfnやARMなど別のIaCによる変更 • CLIによる変更 • Lambdaなどによる動的な変更 • Ansibleなどからの変更 • などなど
  18. UnManaged検知 Cloud infra Resource B Resource A Resource C Resource

    D Resource E State file 1 既存のインフラ Terraform以外で作成された リソース など Unmanagedの検知をもとに: • 不要なリソースの判別 • IaCでManageするように修正 • TerraformにImport • など Resource G Resource F Resource H Resource I Resource J Resource L Resource K Resource M Resource N Resource O Resource Q Resource P Resource R Resource S Resource T State file 2 State file 3 Managed Managed Manageだが ドリフト発生 Unmanaged Resource P~TはUnmanageですよ 全体の75%はTerraformでManageされてますよ。 100%を目指しましょう! 15個がManagedで5個がUnmanagedですよ 1つのResourceにドリフトが発生してますよ
  19. Terraformのドリフト検知との(大雑把な)違い Terraform Cloud Snyk Managedリソースのドリフト ほぼ同じ機能を提供 State fileへの修正 󰢏 Refresh相当

    Importの実施 🙅 State fileの管理 󰢏 Workspaceで安全に管理 🙅 State fileの指定が必要 たくさんのStateに分割されている場合は結構 大変かも・・・ 必要なCredential権限 Terraform実行時の権限が必要 (将来的には対応されそう) Least Privileged Read-onlyのクレデンシャルでOK Terraform管理外のリソース検知 (Unmanaged) 🙅 Data source使えばリストアップは可能 󰢏 アカウントに存在するリソースのリストアップ (例:既存のリソース) 全体に占める割合の表示 実行タイミング Daily いつでも
  20. • Developer First- bring production insights left to improve the

    developer experience with ◦ Security issue context ◦ Actionable fix advice • Holistic application view - enable developers to take ownership of their application security from writing IaC files in their IDE to the real-time state of the cloud • Faster remediation - close the feedback loop between cloud and production security insights and developer workflows • Reduce the most risk- prioritize issues based on risk, not just finding the most amount of issues Snyk IaC + Cloud Code to cloud, and back to code Coming soon!