コンテナ・Kubernetes環境向けセキュリティ・モニタリング プラットフォーム

本文の内容は、2022年2月3日現在における、docs.sysdig.com上のIaC Security(https://docs.sysdig.com/en/docs/sysdig-secure/iac-security/#iac-security) を元に日本語に翻訳・再構成した内容となっております。

IaC セキュリティ

利点と使用例

Infrastructure as Codeは、セキュリティプロトコルと標準を開発パイプラインに落とし込み、開発プロセスの可能な限り早い段階で潜在的な問題を浮き彫りにし、解決するのに役立ちます。これにより、組織内の多くの関係者にメリットがあります。

• セキュリティおよびコンプライアンス担当者は、違反やセキュリティリスクの減少を実感できます。
• DevOps管理者は、プロセスを合理化し、パイプラインを保護することができます。
• 開発者は、問題を早期に発見し、最小限の労力で問題を解決するための明確なガイダンスを得ることができます。

Git IaCスキャン

Sysdigは、Infrastructure as Code (IaC)ソリューションの一環として、Gitインテグレーションを導入しています。現時点では、この統合機能を使用して、受信したプル・リクエスト（PR）をスキャンし、事前に定義されたポリシーに基づいてセキュリティ違反を検出することができます。スキャン評価の結果は、PR自体に表示されます。合格した場合、ユーザーはマージすることができ、失敗した場合、ユーザーはマージできません。また、PRで提供される情報は、ユーザーの改善を支援するために、問題領域を対象としています。

プロセスの概要

Sysdigは現在、Github、Bitbucket、GitLab、およびAzure DevOpsの統合をサポートしています。

いずれの場合も、管理者としてログインし、「Git Integrations」を選択し、フレーバーを選択して設定し、ソースのどの部分を保護するかを定義します。

• リポジトリ (リストから選択)
• 各リポジトリ内のフォルダ (または / を使ったすべてのフォルダ)
• ブランチ（プルリクエストの評価のためのみ）

インテグレーションの開始

1. Sysdig Secureに管理者としてログインし、ナビゲーション・バーの「Settings」ボタンを選択します。
2. Git Integrationsを選択します。
   • インテグレーションが一度も追加されていない場合は、このページは空です。Add Git Integrationをクリックします。
   • いくつかの統合がすでに存在する場合は、Git Integrations Listページが表示され、インテグレーションの名前、ステータス、構成されたソースの数が表示されます。
   • Add Git Integrationをクリックします。
3. ドロップダウン・リストから該当する統合タイプを選択し、設定を開始します。

Github

この設定では、Sysdig SecureのインターフェースとGithubのインターフェースが切り替わります。

Git Integrations ListページからGithubとを選択します：

1. インテグレーション名を入力し、Complete in Githubをクリックします。
   • Githubインターフェースが新しいタブで開きます。
2. Githubにサインインし、Sysdig Githubアプリをインストールする場所を選択します。Configureをクリックします。
3. All Repositoriesを選択するか、選択したリポジトリを定義し、Installをクリックします。
   • インストールが完了すると、Sysdig SecureのIntegrationページにリダイレクトされます。Integration StatusにActiveが表示されているはずです。
4. 新しいインテグレーションリストでAdd Sourcesをクリックします。
5. レポを1つずつ追加し、スキャンするフォルダを定義します。SysdigがPull Requestの評価チェックを行うべきBranchを選択します。正規表現を使ってBranchを定義します。 .* を使ってすべてのBranchのPRをチェックすることも、mainを使うこともできます。
6. Add Sourceをクリックします。必要に応じて繰り返し、Saveをクリックします。有効なフォルダ名が入力されているかどうか、システムが自動的にチェックします。
7. Sysdig SecureとSysdig Githubアプリケーションの間の接続に問題がないか、Integrations ListページのStatusを確認します。
   • Active：すべて期待通りに動作しています
   • Not Installed：Sysdig Github Appがインストールされていません。
   • Suspended： Suspended: Sysdig Githubアプリが一時停止しており、再開する必要があります。

Bitbucket

前提条件

1. Bitbucketの組織を開き、Sysdig用のアカウントを作成します。
2. そのアカウントのアクセス権を、関連するワークスペースに設定します。
3. アカウントに新しいアプリのパスワードを作成します。
4. Personal Settings > App passwordsを開き、Create app password をクリックします。
5. 以下の権限を割り当てます。
   • Account: Read
   • Repositories: Read, Write, Admin
   • Pull requests: Read, Write
   • Webhooks: Read and write
6. Createをクリックします。

Bitbucketインテグレーションの追加

1. SysdigのGit Integration画面に移動します。
2. Add Git Integration をクリックし、Bitbucket を選択します。
3. 前提条件のステップで作成したアプリのパスワードを含む詳細情報を入力します。
4. Addをクリックして完了です。インストールが完了すると、Sysdig SecureのIntegrationページにリダイレクトされます。Integration Status に「Active」と表示されているはずです。
5. 新しいインテグレーションリストの Add Sources をクリックします。
6. レポを1つずつ追加し、スキャンするフォルダを定義します。SysdigがPull Requestの評価チェックを行うべきBranchを選択します。正規表現を使ってブランチを定義します。すべてのブランチのPRをチェックするために.* を使用したり、mainを使用することができます。
7. 必要に応じて繰り返し、Saveをクリックします。有効なフォルダ名が入力されているかどうか、システムが自動的にチェックします。
8. Sysdig SecureとSysdig Bitbucketアプリケーションの間の接続に問題がないか、Integrations ListページのStatusを確認します。
   • Active: すべて期待通りに動作しています
   • Not Installed: Sysdig Bitbucketアプリがインストールされていません。
   • Suspended: Sysdig Bitbucket アプリが一時停止しており、再開する必要があります。

GitLab

GitLab UIでの前提条件：

• GitLab組織にログインし、Sysdig Secure用のアカウントを作成します。
• アカウントのプロジェクトへのアクセスを設定する
• 固有の個人アクセストークンを作成し、以下を設定します。
  • トークンの固有名
  • トークンの有効期限
  • トークンの以下のスコープ
    • api
    • read_repository
    • write_repository
• トークンの値をコピーする

インテグレーションの追加

Git Integrations List ページから GitLab を選択します。

1. Integration Name（インテグレーション名）とToken（トークン）を前提条件のステップから入力します。
2. Test Connection をクリックして、 Add をクリックします。Manage Integration ページが表示されます。
3. 新しい統合の一覧で Add Sources をクリックします。
4. Reposを1つずつ追加し、スキャンするFolder(s)を定義します。SysdigがPull Requestの評価チェックを行うブランチを選択します。正規表現を使ってブランチを定義します。.* を使ってすべてのブランチのPRをチェックすることも、mainを使ってチェックすることもできます。
5. 有効なフォルダ名が入力されているか、システムが自動的にチェックします。
6. Integrations ListページでStatusを確認します。

Azure DevOps

Azure DevOps UIでの前提条件

• Azure DevOps組織にログインし、Sysdig Secure for cloudの指定アカウントを作成します。
• アカウントのアクセス アカウントのリポジトリとプロジェクトへのアクセスを設定する
• アカウント・サブスクリプション・パーミッション アカウントにサブスクリプションの表示、編集、削除の権限を割り当てます。
  • ヒント：Azure CLIを使って必要なサブスクリプションのアクセス権を付与します。
    • ServiceHooks Namespace: az devops security permission namespace list --output tableを実行し、ServiceHooks namespace IDを記録します。
    • PublisherSecurity Token: az devops security permission update --allow-bit 7 --namespace-id {{ServiceHooks namespace Id}} --subject {{accountUserEmail}} --token PublisherSecurity --output tableを実行します。-subject {{accountUserEmail}}を指定します。
• Personal Access Token: 固有のパーソナルアクセストークンを取得する
  • トークンの値の記録
  • トークンのスコープ Custom Defined（カスタム定義）に設定
  • Code Scope：コードのスコープ。Read、Write、Statusの各パーミッションを選択
  • Extensions Scope: 読み取りパーミッションを選択
  • その他のヘルプについては、Azure DevOpsのドキュメントを参照してください。

インテグレーションの追加

Git Integrations List ページから Azure DevOps を選択します：

1. 前提条件のステップから、Integration Name（統合名）、Organization Name（組織名）、Personal Access Token（個人用アクセス・トークン）を入力します。
2. Test Connection をクリックし、 Add をクリックします。Manage Integration ページが表示されます。
3. 新しいインテグレーションのリストで Add Sources をクリックします。
4. レポを1つずつ追加し、スキャンするフォルダを定義します。SysdigがPull Requestの評価チェックを行うブランチを選択します。正規表現を使ってブランチを定義します。 .* を使ってすべてのブランチのPRをチェックすることも、mainを使ってチェックすることもできます。
5. 有効なフォルダ名が入力されているか、システムが自動的にチェックします。
6. Integrations ListページでStatusを確認します。

プルリクエストポリシーの評価

Git Sourcesで定義されたブランチに対して、SysdigはPull Request Policy Evaluationのチェックを行います。このチェックでは、プル・リクエスト内のInfrastructure-as-Codeファイルをスキャンし、事前に定義されたポリシーに対する違反を特定します。

チェックの結果には、違反のリストとその深刻度、ファイルごとの失敗したリソースのリストが含まれます。

GitHubでの出力例：

IaCポリシーコントロール

開発中のプルリクエストのコンプライアンスをチェックするためにGithubインテグレーションを実行する際、Sysdigは以下のポリシーのコントロールを実行します。

CIS Kubernetes 1.5.1

要件グループ	グループ説明	要件	要件説明	コントロール	コントロール説明
5.1 - RBAC	役割ベースのアクセス制御とサービスアカウントのポリシー
		5.1.5 - Default ServiceAccounts	アプリケーションに付与された権限をより簡単に監査・確認できるようにするために、デフォルトのサービスアカウントを使用してはいけません。
				デフォルトのServiceAccountを使用したワークロード	ポッドは、最小限の権限を持つ固有のユーザーで実行する必要があります。これにより、アクションの説明責任を果たし、トラブルシューティングを容易にし、ポッドが不正なアクションを行わないようにします。
		5.1.6 - SA Tokens	サービスアカウントトークンは、ポッドで実行されているワークロードが明示的にAPIサーバーと通信する必要がある場合を除き、ポッドにマウントするべきではありません。
				ワークロード mounting ServiceAccount Token	APIサーバーへのポッドのアクセスは最小限にすべきです。サービスアカウントが不要な場合は、シークレットの自動マウントを避けることができます。
5.2 - PSP	ポッドのセキュリティに関するポリシー
		5.2.1-privileged containers	一般に、securityContext.privileged フラグが true に設定されたコンテナの実行を許可しません。
				特権的に動作するコンテナ	特権コンテナはほぼ無制限なので、使用してはいけません。
		5.2.2-Host PID	hostPIDフラグをtrueに設定してコンテナを実行することを一般的に許可しない
				ワークロードシェアリング HostPID	ホストのPIDを共有すると隔離性が低下し、環境変数などのホストデータが実行中のPodに公開されてしまう
		5.2.3 - Host IPC	hostIPCフラグがtrueに設定されているコンテナの実行を一般的に許可しない。
				ワークロードシェアリング HostIPC	ホストのIPCを共有することで孤立感をなくし、Podがホストのプロセスと通信することで、あたかもホスト上で動作しているかのようにタスクを実行することが可能になります。
		5.2.4-Host Network	通常、hostNetworkフラグがtrueに設定されたコンテナの実行を許可しません。
				ワークロードシェアリング ホストネットワーク	ホストネットワークを共有すると、Podにアクセスできる誰もがPodのネットワークを公開することになります。また、ホストのループバックにバインドされたプロセスとPodが通信できるようになります。
		5.2.5 - Allow Privilege Escalation	allowPrivilegeEscalationフラグをtrueに設定してコンテナを実行することを一般的に許可しない。
				特権的なサブプロセスを許可するコンテナ	サブプロセスは、親プロセスよりも多くの権限を得ることができます。
		5.2.6 - Root containers	一般的に、コンテナをルートユーザーとして実行することを許可しない。
				ルートを許可するコンテナ	この設定では、コンテナが root 以外の uid で実行されることを強制します。イメージが設定を上書きして root で実行されないようにするために、この設定を行うのが最善の方法です。
				rootで起動するコンテナ	rootでコンテナを実行するとポッドエスケープが発生する
				コンテナのuidはホストの範囲	ホストのユーザーテーブルとの衝突を避けるため、uid>10000で実行することをお勧めします。
				SYS_ADMIN能力を持つコンテナ	root権限に相当するSYS_ADMIN権限の付与
		5.2.7-NET_RAW	危険性のあるNET_RAW機能を持つコンテナを一般的に許可しない。
				NET_RAW機能付きコンテナ	任意のアドレスにバインドして任意のホストアドレスを透過的にプロキシすることができるNET_RAWケイパビリティを割り当てます。
		5.2.8 - Added capabilities	デフォルトセット以上の機能が割り当てられたコンテナを一般的に許可しない。
				ANY機能付きコンテナ	コンテナはanyの機能を持ってはいけません。
		5.2.9 - No capabilities	機能を持つコンテナは一般的に許可しない。
				ANY機能付きコンテナ	コンテナはanyの機能を持ってはいけません。
5.4 - Secrets	Secrets management
		5.4.1 - Secrets Env Vars	Kubernetesはデータボリュームや環境変数としてのシークレットのマウントをサポートしています。環境変数のシークレットの使用は最小限にしてください。
				シークレットを暴露するEnv変数	アプリケーションがシークレットの内容をプリントする可能性があるため、コンテナは環境変数でシークレットを使用しないようにする必要があります。
		5.4.2 - Ext secret storage	より複雑なシークレット管理のニーズがある場合は、Kubernetes Secretsを直接使用する代わりに、外部のシークレットストレージおよび管理システムの使用を検討してください。ソリューションは、シークレットにアクセスするための認証を必要とし、シークレットへのアクセスと使用の監査があり、シークレットを暗号化することを確認してください。いくつかのソリューションはまた、シークレットをローテートさせることが容易になります。
				シークレットからキーを露出させるEnv変数	アプリケーションがシークレットの内容をプリントする可能性があるため、コンテナは環境変数でシークレットを使用しないようにする必要があります。
5.7 - General	General security policies
		5.7.1 -Namespacing	ネームスペースを使ってKubernetesのオブジェクトを分離します。
				デフォルトのネームスペースで定義されたワークロード	ポッドは隔離を促進するためにネームスペースを確保する必要があります。
		5.7.2 - seccomp	ポッド定義でdocker/default seccompプロファイルを有効にする。
				docker.sockアクセスによるワークロード	docker.sockをマウントするポッドは、他のコンテナの情報をリークし、コンテナのブレイクアウトを引き起こす可能性があります。
				Seccompプロファイル docker/default	ワークロード内のコンテナがセキュアコンピューティングモードを使用する（これはアルファ版の機能であり、ランクは低い）
		5.7.4 - Default namespace	Kubernetesにはデフォルトのネームスペースがあり、ネームスペースが指定されていない場合はここにオブジェクトが置かれます。このネームスペースにオブジェクトを配置すると、RBACなどの制御の適用が難しくなります。
				デフォルトのネームスペースで定義されたワークロード	ポッドは隔離を促進するためにネームスペースを確保する必要があります。

Sysdig K8sベスト・プラクティス（IaC）

要件グループ	グループ説明	要件	要件説明	コントロール	コントロール説明
1 - Workload Security	ワークロードのセキュリティ設定に直接関連する設定
		1.1 - Workload Default SecurityContext	ワークロードでデフォルトのセキュリティコンテキストを定義することは、設定ミスを防ぐために重要であり、もう一つの保護層として機能します。
				ワークロードコンテナのデフォルトの RunAsUser root	ポッド内のコンテナが runAsUser を定義していない場合、ユーザーを root に設定します。
				ワークロードコンテナのデフォルトの RunAsGroup root	Pod内のコンテナがrunAsGroupを定義していない場合は、グループをrootに設定します。
				ワークロードコンテナのルートをデフォルト許可	ポッド内のコンテナが runAsNonRoot を定義していない場合、これにより root をユーザーとして定義することができます。
		1.2 - Immutable container filesystem	コンテナのファイルシステムは不変でなければなりません。コンテナのルートファイルシステムが改ざんされるのは、マルウェアが原因である可能性があります。
				書き込み可能なルートファイルシステムを持つコンテナ	ルートファイルシステムが書き込み可能なコンテナでは、実行ファイルの改ざんが可能なため、攻撃を受けやすくなります。
		1.3 - Immutable container volumes	コンテナボリュームのマウントは、可能な限り不変でなければなりません。不変的であればあるほど、より安全です。
				書き込み可能なボリュームを持つワークロード	ポッドは主に読み取り専用のボリュームを使用して、ワークロードが不変であることを確認する必要があります。
		1.4 - Disable docker.sock volume	docker.socketをマウントすることで、ワークロードが他のコンテナの情報を聞くことができ、コンテナのブレイクアウトが可能になります。
				docker.sockアクセスによるワークロード	docker.sockをマウントするポッドは、他のコンテナの情報をリークし、コンテナのブレイクアウトを引き起こす可能性があります。
		1.5 - Exposing HostPort	HostPortは物理ノードからポートを取ります。サービスを公開するには、Servicesを使用する必要があります。
				HostPortを公開するコンテナ	ホストポートの使用により、Podを実行できる場所に制約がある場合があります。
		1.6 - Container root group access	グループIDは、コンテナを実行するユーザーのグループアクセスレベルを定義します。グループ "root "は使用しないことをお勧めします。
				Container with root group access	Running with root group context allows access to all files owned by root group
2 - Workload-Operations	ワークロードの日常的な運用に影響を与える設定項目
		2.1 - Missing container requirements	リソース要件は、Kubernetesのスケジューラーがワークロードをノードに適切に割り当てるのに役立ちます。
				ワークロードがCPUリクエストを満たしていない	リソースリクエストがないと、スケジューラーのワークロードに対するリソース割り当てを損ないます。
				ワークロードがメモリリクエストを満たしていない	リソースリクエストがないと、スケジューラーのワークロードに対するリソース割り当てを損ないます。
		2.2 - Missing container limits	リミットのないワークロードによるリソースの圧迫を避けるために、リソースリミット定義する必要があります。
				ワークロードがCPUリミットを満たしていない	リミットなしの設定ではプロセスの窮乏を招く可能性があります。
				ワークロードがメモリリミットを満たしていない	リミットなしの設定ではプロセスの窮乏を招く可能性があります。
		2.3 - Container image pull	コンテナは常にイメージをプルする必要があります（最良のオプション）。またはイメージがローカルに存在しない場合。
				コンテナパーマネントイメージ	イメージレポジトリから更新されないイメージは、改ざんされたイメージになる可能性がある
				存在しない場合はコンテナイメージの更新のみ	プルポリシーをAlwaysに設定することで、最新のイメージでコンテナを実行することができます。
		2.4 - Container image tag	コンテナは、その適切な機能に必要な特定のイメージを常に定義する必要があります。
				最新イメージのコンテナ	latest またはブランクのタグで実行されているイメージは、特定のイメージなしに更新されるため、システムの整合性が崩れる可能性がある
				ダイジェストのないイメージを使用するコンテナ	イメージダイジェストは不変で、すべてのインスタンスが常に同じコードを実行することが保証されています。
		2.5 - Container probes	コンテナは、正しいデータで準備ができたときにのみリクエストを処理するように、readniessとlivenessのプローブを構成する必要があります。
				livenessプローブなしのコンテナ	コンテナは、アプリの状態を公開し、システムの整合性を維持するために、 livenessプローブを持つ必要があります。
				readinessプローブのないコンテナ	コンテナには、リクエストに対応する能力とシステムの整合性を維持する能力を明らかにする readinessプローブが必要です。
3 - Cluster & Workload Access	クラスター内のワークロードアクセスと特権ユーザに影響する設定
		3.1 - NET_Admin capability	ネットワーク管理機能により、ネットワークインターフェースを操作し、他のワークロードからデータをリークしたり、プロキシしたりすることができ、結果的にクラスターを乗っ取ることができます。
				NET_ADMIN機能を持つコンテナ	任意のホストアドレスへのトランスペアレントなプロキシ、インターフェースの管理、すべてのホストトラフィックのスニッフィングなどを可能にするNET_ADMIN機能を割り当てます。
		3.2 - Container overlap host UID Range	コンテナのUID範囲は、衝突を避けるためにホストの範囲を避ける必要があります。
				コンテナのuidはホストの範囲	ホストのユーザーテーブルとの衝突を避けるため、uid>10000で実行することをお勧めします。

Sysdigに関するお問い合わせはこちらから