本文の内容は、2022年9月14日にEduardo Mínguezが投稿したブログ(https://sysdig.com/blog/security-infrastructure-as-code-sysdig/)を元に日本語に翻訳・再構成した内容となっております。
IaC (Infrastructure as Code) は、インフラストラクチャーを管理するための強力なメカニズムですが、このIaCがもたらす大きな力には大きな責任が伴います。もし、あなたのIaCファイルにセキュリティ上の問題（例えば、タイプミスのために誤ったパーミッションが設定されるなど）があれば、それは、セキュリティ問題のほとんどがスキャンされるか、実行時に発見されるまで、CI/CDパイプラインに沿って伝播していくことになります。一方、インフラストラクチャーに潜在するセキュリティ問題をソースで修正できるとしたらどうでしょうか？
Infrastructure as Code（インフラストラクチャー・アズ・コード）とは？
IaCは、インフラストラクチャーのビルドブロック（仮想マシン、ネットワーク、コンテナーなど）を、さまざまな技術やツールを使ってコードとして扱う方法論です。つまり、VM、コンテナ、ネットワーク、ストレージなどのインフラストラクチャーを、お気に入りのインフラストラクチャー・プロバイダーのWebインターフェースから手動で作成するのではなく、それらをコードとして定義し、選択したツール（terraform、crossplane、pulumiなど）で作成／更新／管理するのです。これにより非常に大きなメリットを得られます。インフラストラクチャーをコードであるかのように管理でき（今はコードです）、開発のベストプラクティス（自動化、テスト、トレーサビリティ、バージョン管理など）をインフラストラクチャー資産に活用することができるのです。このトピックに関する情報は数多くありますが、このブログが良い出発点となるでしょう。
なぜInfrastructure as Code資産を保護することが、追加のセキュリティ層として重要なのでしょうか？
ほとんどのセキュリティ・ツールは、潜在的な脆弱性や問題を実行時に検出しますが、それでは遅すぎます。それらを修正するためには、手動で修正を行うか（例えば、k8sオブジェクトのパラメータをkubectl editで直接修正する）、理想的にはソースで修正が行われ、それがサプライチェーン全体に伝搬されることが必要です。これが、”Shift Security Left “と呼ばれるものです。手遅れになってから問題を解決することから、問題が起こる前に解決するやり方に移りましょう。Red Hatの ”2022 state of Kubernetes security report“によると、回答者の57％がコンテナライフサイクルのランタイムフェーズを最も心配しているとのことです。しかし、そのような潜在的な問題をコード定義で直接発見することができれば、より良いのではないでしょうか？
Sysdig Git Infrastructure as Code Scanningの紹介
現時点での ” CIS Kubernetes “と” Sysdig K8s Best Practices “ベンチマークに基づき、Sysdig SecureはInfrastructure as Codeマニフェストをソースからスキャンします。現在、Kubernetesワークロードを表すYAML、Kustomize、HelmまたはTerraformファイルのスキャンをサポートしており（今後のリリースに乞うご期待！）、GitHub、GitLab、BitbucketまたはAzure DevOpsでホストされるリポジトリ上のプルリクエストに直接、潜在する問題を表示し、開発ワークフローにシームレスに統合されます。詳細については、公式ドキュメントを参照してください。コンセプトの証明として、サンプルのゲストブック アプリケーションを”Infrastructure as Code”として、小さなEKSクラスターで実際に使って見ましょう。ArgoCDでアプリケーションのライフサイクルを管理するために、GitOpsのプラクティスも適用してみましょう。
これは、GitOps と Sysdig IaC スキャンとの統合のPoCです。この PoC で使用されるバージョンは、ArgoCD 2.4.0、Sysdig Agent 12.8.0、Sysdig Charts v1.0.3 です。ノート：GitOpsについてもっと知りたいですか？GitOpsを使用してソースにセキュリティを適用する方法をご覧ください。
準備
EKSクラスター（ “eksctl create cluster -n edu --region eu-central-1 --node-type m4.xlarge --nodes 2“として作成）は以下のような状態になっています：kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-0-2-210.eu-central-1.compute.internal Ready <none> 108s v1.20.15-eks-99076b2 ip-10-0-3-124.eu-central-1.compute.internal Ready <none> 2m4s v1.20.15-eks-99076b2
Argo CDのインストールは、公式ドキュメントの指示に従うだけで、簡単にできます：
kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.0/manifests/install.yaml
Argo をデプロイして、サンプルアプリケーションを作りましょう。ここでは https://github.com/argoproj/argocd-example-apps.git で公開されているゲストブック Argo CD アプリケーションのサンプルを活用し、GitHub で直接フォークを作成します：
あるいは、GitHub の cli ツールを使ってください。：
❯ cd ~/git ❯ gh repo fork https://github.com/argoproj/argocd-example-apps.git --clone ✓ Created fork e-minguez/argocd-example-apps Cloning into 'argocd-example-apps'... ... From github.com:argoproj/argocd-example-apps * [new branch] master -> upstream/master ✓ Cloned fork
さて、Argo CD を設定して、Web インターフェイス経由で k8s クラスタにアプリケーションをデプロイします。Argo CD のウェブインターフェースにアクセスするには、パスワードを取得し（インストール時にランダム化されます）、また外部から利用できるようにする必要があります。この例では、ポートフォワードが使用されています：
❯ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
s8ZzBlGRSnPbzmtr
❯ kubectl port-forward svc/argocd-server -n argocd 8080:443 &次に、ウェブブラウザで http://localhost:8080 を指定して Argo CD の UI にアクセスします：
または、Kubernetesオブジェクトを直接使用します。
❯ cat << EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-example-app
namespace: argocd
spec:
destination:
namespace: my-example-app
server: https://kubernetes.default.svc
project: default
source:
path: guestbook/
repoURL: https://github.com/e-minguez/argocd-example-apps.git
targetRevision: HEAD
syncPolicy:
automated: {}
syncOptions:
- CreateNamespace=true
EOFしばらくすると、Argo が git リポジトリから、全てのオブジェクトを含むアプリケーションをデプロイします。
Argo CD UI のスクリーンショット：同期に成功したアプリケーションの例
❯ kubectl get all -n my-example-app NAME READY STATUS RESTARTS AGE pod/guestbook-ui-85985d774c-n7dzw 1/1 Running 0 14m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/guestbook-ui ClusterIP 172.20.217.82 <none> 80/TCP 14m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/guestbook-ui 1/1 1 1 14m NAME DESIRED CURRENT READY AGE replicaset.apps/guestbook-ui-85985d774c 1 1 1 14m
成功!
コードとして定義されたアプリケーションは、すでにKubernetesクラスターで稼働しており、GitOpsのプラクティスを使ってデプロイも自動化されています。しかし、セキュリティ面は一切考慮していませんでした。私のアプリケーションの定義は十分に安全でしょうか？何か見落としていることはないでしょうか？何がわかるか見てみましょう。
Sysdig Secureを設定して、私たちの新しい輝くリポジトリをスキャンすることは、新しいgitリポジトリの統合を追加するのと同じくらい簡単です。
プルリクエストポリシー評価
では、実際に見てみましょう。例えば、レプリカの数を 1 から 2 に増やすなど、いくつかのコードを変更してプルリクエストを作成します：
または、cliを使用して：
❯ git switch -c my-first-pr Switched to a new branch 'my-first-pr' ❯ sed -i -e 's/ replicas: 1/ replicas: 2/g' guestbook/guestbook-ui-deployment.yaml ❯ git add guestbook/guestbook-ui-deployment.yaml ❯ git commit -m 'Added more replicas' [my-first-pr c67695e] Added more replicas 1 file changed, 1 insertion(+), 1 deletion(-) ❯ git push Enumerating objects: 7, done. …
ほぼ即座に、Sysdig Secureはリポジトリフォルダのスキャンを実行し、潜在的な問題を通知することになります：
Sysdigのプルリクエストポリシー評価の実行中のスクリーンショット
ここでは、CIS Kubernetes V1.6ベンチマークとSysdig Kubernetesベストプラクティスに基づき、いくつかの潜在的な問題を深刻度順に見ることができます。例として、サンプルアプリケーションのデプロイファイルにある「Container with writable root file system」（書き込み可能なルートファイルシステムを持つコンテナ）が挙げられます。
これらの推奨事項はソースコードを修正することで適用できますが、Sysdig Secureに代行してもらうのはどうでしょうか？
ソースコード上の問題を自動的に修正する
helm経由でSysdig Secureエージェントをクラスターにデプロイして、KSPM機能を有効にするためのいくつかの新しいフラグを含めて、実行中のオブジェクトを検査できるようにしましょう。
❯ helm repo add sysdig https://charts.sysdig.com
❯ helm repo update
❯ export SYSDIG_ACCESS_KEY="XXX"
❯ export SAAS_REGION="eu1"
❯ export CLUSTER_NAME="mycluster"
❯ export COLLECTOR_ENDPOINT="ingest-eu1.app.sysdig.com"
❯ export API_ENDPOINT="eu1.app.sysdig.com"
❯ helm install sysdig sysdig/sysdig-deploy \
--namespace sysdig-agent \
--create-namespace \
--set global.sysdig.accessKey=${SYSDIG_ACCESS_KEY} \
--set global.sysdig.region=${SAAS_REGION} \
--set global.clusterConfig.name=${CLUSTER_NAME} \
--set agent.sysdig.settings.collector=${COLLECTOR_ENDPOINT} \
--set nodeAnalyzer.nodeAnalyzer.apiEndpoint=${API_ENDPOINT} \
--set global.kspm.deploy=true
# after a few moments
❯ kubectl get po -n sysdig-agent
NAME READY STATUS RESTARTS AGE
nodeanalyzer-node-analyzer-bw5t5 4/4 Running 0 9m14s
nodeanalyzer-node-analyzer-ccs8d 4/4 Running 0 9m5s
sysdig-agent-8sshw 1/1 Running 0 5m4s
sysdig-agent-smm4c 1/1 Running 0 9m16s
sysdig-kspmcollector-5f65cb87bb-fs78l 1/1 Running 0 9m22s
読者のために練習として、このステップは Argo CD と helm チャートを使って GitOps 方式で行うことができます。数分後、エージェントがデプロイされ、Kubernetesのステータスが新しいPosture -> “Actionable Compliance “のセクションにレポートされ、セキュリティ要件が観察できるようになります：
Sysdigのコンプライアンスビューのスクリーンショット
”Container Image Pull”ポリシーコントロールを修正してみましょう（利用可能なポリシーコントロールの詳細なリストについては、公式ドキュメントを参照してください）。
そこには、修正案、Kubernetesパッチ、そして”Setup Pull Request”の項目が表示されています。でも、本当にプルリクエストを使って修正できるのでしょうか？
確かに! Sysdig Secureは、Kubernetesオブジェクトのソースとランタイムの状態を比較することもできるようになり、ソースから実行まで、あなたに代わって修正することもできるようになりました。
複雑な操作や、雪だるまを作るような手動修正は必要ありません。その代わり、ソースで修正しましょう。
最後に
IaCスキャン、セキュリティ、コンプライアンスの仕組みをツールボックスに追加することで、お客様の組織は、サプライチェーンのソース（セキュリティのシフトレフト）で直接、潜在的なセキュリティ問題を発見し、修正することができます。Sysdig Secureは、お客様に代わって直接修正策を作成することも可能です！
今すぐSysdig Secureの無料トライアルを開始し、ご自身の目でお確かめください。