Skip to content
Published on

[Golden Kubestronaut] KCSA 追加実践問題30問 - クラウドネイティブセキュリティ深化

Authors

KCSA 追加実践問題30問

KCSA試験のコアドメインであるサプライチェーンセキュリティランタイムセキュリティゼロトラストネットワーキングイメージ検証ポリシーエンジンPodセキュリティを深く学習するための追加問題30問です。


問題1. SLSAフレームワーク

SLSA(Supply-chain Levels for Software Artifacts)フレームワークの主な目的は?

  • A) コンテナランタイムのパフォーマンスを最適化する
  • B) ソフトウェアサプライチェーンの整合性を保証するためのセキュリティレベルを定義する
  • C) Kubernetesクラスタのネットワークポリシーを管理する
  • D) コンテナイメージのサイズを削減する
正解と解説

正解: B) ソフトウェアサプライチェーンの整合性を保証するためのセキュリティレベルを定義する

SLSAはソフトウェアサプライチェーン攻撃を防止するためのセキュリティフレームワークで、Build Level 0からLevel 3までのセキュリティレベルを定義します。ビルドプロセスの出所(provenance)追跡、改ざん防止、隔離されたビルド環境などを要求します。


問題2. Sigstoreプロジェクト

Sigstoreのコアコンポーネントでないものは?

  • A) Cosign - コンテナイメージ署名
  • B) Fulcio - 短期証明書発行CA
  • C) Rekor - 透明性ログ
  • D) Falco - ランタイム脅威検出
正解と解説

正解: D) Falco - ランタイム脅威検出

SigstoreはCosign(イメージ/アーティファクト署名)、Fulcio(キーレス署名のための短期証明書発行)、Rekor(署名透明性ログ)で構成されます。Falcoはランタイムセキュリティツールで、Sigstoreとは別のCNCFプロジェクトです。


問題3. in-totoフレームワーク

in-totoが保護する対象は?

  • A) ランタイムコンテナのメモリアクセス
  • B) ソフトウェアサプライチェーンの全プロセス(レイアウトとリンクによるステップごとの検証)
  • C) Kubernetes APIサーバーの認証
  • D) ネットワークトラフィックの暗号化
正解と解説

正解: B) ソフトウェアサプライチェーンの全プロセス(レイアウトとリンクによるステップごとの検証)

in-totoはソフトウェアサプライチェーンの全過程を保護するフレームワークです。レイアウト(layout)でサプライチェーンの期待されるステップを定義し、リンク(link)メタデータで各ステップの実際の実行を記録して改ざんを検出します。


問題4. Falcoランタイムセキュリティ

Falcoがシステムイベントを検知する主要メカニズムは?

  • A) コンテナイメージの静的解析
  • B) eBPFまたはカーネルモジュールを通じてシステムコールをリアルタイムで監視する
  • C) Kubernetes APIをポーリングしてリソース変更を検知する
  • D) ネットワークパケットをキャプチャして分析する
正解と解説

正解: B) eBPFまたはカーネルモジュールを通じてシステムコールをリアルタイムで監視する

FalcoはeBPFプローブまたはカーネルモジュールを使用してシステムコールをリアルタイムで監視し、YAMLベースのルールに基づいて異常な動作(例:予期しないシェルの実行、機密ファイルへのアクセス)を検出します。


問題5. Tetragon

Cilium Tetragonの差別化された機能は?

  • A) コンテナイメージビルドの自動化
  • B) eBPFベースでカーネルレベルでセキュリティポリシーを適用し、プロセスを即座にブロックできる
  • C) Kubernetesマニフェストの静的解析
  • D) SSL証明書の自動更新
正解と解説

正解: B) eBPFベースでカーネルレベルでセキュリティポリシーを適用し、プロセスを即座にブロックできる

TetragonはCiliumプロジェクトのeBPFベースのセキュリティオブザーバビリティおよびランタイム強制ツールです。Falcoとは異なり、検出だけでなくカーネルレベルでプロセスを直接キルできるランタイム強制(enforcement)機能を提供します。


問題6. ゼロトラストネットワーキング

ゼロトラスト(Zero Trust)セキュリティモデルのコア原則は?

  • A) 内部ネットワークは常に信頼できる
  • B) ネットワーク位置に関係なくすべてのリクエストを検証し、最小権限を付与する
  • C) ファイアウォールだけで十分なセキュリティを提供する
  • D) VPNを使用すればすべてのトラフィックが安全である
正解と解説

正解: B) ネットワーク位置に関係なくすべてのリクエストを検証し、最小権限を付与する

ゼロトラストモデルは「絶対に信頼せず、常に検証する(Never Trust, Always Verify)」を原則とします。ネットワーク境界内であってもすべてのリクエストに対して認証、認可、暗号化を要求し、最小権限原則を適用します。


問題7. SPIFFE/SPIRE

SPIFFE(Secure Production Identity Framework for Everyone)のコア概念は?

  • A) DNSベースのサービスディスカバリ
  • B) ワークロードに統一されたID(SPIFFE ID)を付与し、SVIDを通じて認証する
  • C) コンテナイメージスキャニング
  • D) ネットワークセグメンテーション
正解と解説

正解: B) ワークロードに統一されたID(SPIFFE ID)を付与し、SVIDを通じて認証する

SPIFFEはワークロードにプラットフォーム独立のID(spiffe://trust-domain/path形式)を付与する標準です。SPIREは参照実装で、X.509 SVIDまたはJWT SVIDを発行してワークロード間のmTLS認証を可能にします。


問題8. VaultとKubernetesの統合

HashiCorp VaultをKubernetesと統合する際、最も一般的な認証方式は?

  • A) ユーザー名/パスワード
  • B) Kubernetes Auth Method(ServiceAccountトークンベース)
  • C) SSH鍵認証
  • D) LDAP認証
正解と解説

正解: B) Kubernetes Auth Method(ServiceAccountトークンベース)

VaultのKubernetes Auth MethodはPodのServiceAccountトークンを使用してVaultに認証します。Vault Agent InjectorまたはCSI Providerを通じてシークレットをPodに注入でき、動的シークレット管理が可能です。


問題9. Cosignイメージ署名

cosignでコンテナイメージを署名する際の「Keyless Signing」が意味するものは?

  • A) 署名なしでイメージをデプロイする
  • B) OIDCベースのIDを使用して長期鍵管理なしに短期証明書で署名する
  • C) イメージを暗号化しない
  • D) 公開鍵のみを使用して署名する
正解と解説

正解: B) OIDCベースのIDを使用して長期鍵管理なしに短期証明書で署名する

Keyless SigningはFulcio CAからOIDC認証(例:Google、GitHub)を通じて短期署名証明書を発行してもらい署名し、Rekor透明性ログに記録します。長期秘密鍵を管理する必要がなく、鍵管理の負担を排除します。


問題10. Notation(Notary v2)

Notation(Notary v2)の主な役割は?

  • A) Kubernetesクラスタのバックアップ
  • B) OCIアーティファクトに署名し検証するための標準ツール
  • C) Podネットワークポリシーの管理
  • D) ログ収集と分析
正解と解説

正解: B) OCIアーティファクトに署名し検証するための標準ツール

NotationはOCIイメージおよびアーティファクトの署名と検証のためのCLIツールおよびライブラリです。プラグイン拡張モデルをサポートし、Azure Key Vault、AWS SignerなどのKMSと統合できます。


問題11. SBOM(Software Bill of Materials)

SBOMの主な目的は?

  • A) コンテナのCPU使用量を追跡する
  • B) ソフトウェアに含まれるすべてのコンポーネント(ライブラリ、依存関係)のリストを提供し、脆弱性管理を支援する
  • C) ネットワークトラフィックを監視する
  • D) Kubernetesリソースクォータを管理する
正解と解説

正解: B) ソフトウェアに含まれるすべてのコンポーネント(ライブラリ、依存関係)のリストを提供し、脆弱性管理を支援する

SBOMはソフトウェアの「材料リスト」で、含まれるすべてのコンポーネントとバージョンを文書化します。新しいCVEが発見された場合、SBOMを通じて影響を受けるソフトウェアを迅速に特定できます。


問題12. CycloneDX vs SPDX

CycloneDXとSPDXの共通点は?

  • A) どちらもコンテナランタイムである
  • B) どちらもSBOM形式の標準である
  • C) どちらもサービスメッシュの実装である
  • D) どちらもKubernetesデプロイツールである
正解と解説

正解: B) どちらもSBOM形式の標準である

CycloneDX(OWASP)とSPDX(Linux Foundation)はどちらもSBOMを作成するための標準形式です。SPDXはライセンスコンプライアンスに焦点があり、CycloneDXはセキュリティと脆弱性分析に最適化されています。


問題13. Admission Controllerの概要

Kubernetes Admission Controllerの実行順序として正しいものは?

  • A) Mutating -> Validating -> Object Persistence
  • B) Validating -> Mutating -> Object Persistence
  • C) Object Persistence -> Mutating -> Validating
  • D) Mutating -> Object Persistence -> Validating
正解と解説

正解: A) Mutating -> Validating -> Object Persistence

Kubernetes APIリクエストは認証/認可後、まずMutatingAdmissionWebhookでリソースを変形(修正)し、次にValidatingAdmissionWebhookで有効性を検証した後、etcdに保存されます。


問題14. Kyvernoポリシーエンジン

KyvernoがOPA/Gatekeeperと差別化される点は?

  • A) Rego言語を使用する
  • B) YAMLベースでポリシーを定義し、検証に加えて変形(mutate)と生成(generate)機能を提供する
  • C) Kubernetes外部でのみ動作する
  • D) ポリシー監査機能がない
正解と解説

正解: B) YAMLベースでポリシーを定義し、検証に加えて変形(mutate)と生成(generate)機能を提供する

KyvernoはKubernetesネイティブのポリシーエンジンで、YAMLとCELでポリシーを定義します。validate(検証)、mutate(変形)、generate(リソース生成)、verifyImages(イメージ検証)ルールをサポートします。


問題15. OPA/Gatekeeper

OPA(Open Policy Agent)Gatekeeperでポリシーを定義するために使用する言語は?

  • A) YAML
  • B) JSON
  • C) Rego
  • D) Python
正解と解説

正解: C) Rego

OPAは汎用ポリシーエンジンで、Regoという宣言的クエリ言語を使用してポリシーを定義します。GatekeeperはOPAをKubernetesに統合したもので、ConstraintTemplateにRegoでポリシーロジックを記述します。


問題16. Pod Security Standards

Kubernetes Pod Security Standardsの3つのポリシーレベルは?

  • A) Low, Medium, High
  • B) Privileged, Baseline, Restricted
  • C) Open, Default, Strict
  • D) Allow, Warn, Deny
正解と解説

正解: B) Privileged, Baseline, Restricted

Pod Security StandardsはPrivileged(無制限)、Baseline(既知の権限昇格を防ぐ最小限の制限)、Restricted(Podハードニングのベストプラクティスを適用する最大セキュリティ)の3段階を定義します。


問題17. Pod Security Admission

Pod Security Admissionで使用する3つのモードは?

  • A) allow, block, audit
  • B) enforce, audit, warn
  • C) accept, reject, log
  • D) permit, deny, monitor
正解と解説

正解: B) enforce, audit, warn

Pod Security Admissionはenforce(違反時に拒否)、audit(違反を監査ログに記録)、warn(違反時に警告メッセージを表示)の3つのモードをサポートします。ネームスペースラベルで適用します。


問題18. PodSecurityPolicyのサポート終了

PodSecurityPolicy(PSP)がKubernetesから削除された最も適切な理由は?

  • A) パフォーマンスが遅すぎた
  • B) 使い方が複雑で、RBACバインディングが混乱し、適用範囲が予測しづらかった
  • C) セキュリティ機能が不足していた
  • D) 1つのクラウドプロバイダーしかサポートしなかった
正解と解説

正解: B) 使い方が複雑で、RBACバインディングが混乱し、適用範囲が予測しづらかった

PSPはRBACを通じたバインディングメカニズムが直感的でなく、どのPSPがどのPodに適用されるかの予測が困難でした。Kubernetes 1.25で削除され、Pod Security Admission、Kyverno、OPA/Gatekeeperが代替します。


問題19. ネットワークポリシー

Kubernetes NetworkPolicyに関する正しい説明は?

  • A) NetworkPolicyがなければすべてのトラフィックがブロックされる
  • B) NetworkPolicyがなければすべてのトラフィックが許可され、ポリシーが適用されると明示的に許可されたトラフィックのみ通過する
  • C) NetworkPolicyはノード間通信のみ制御する
  • D) すべてのCNIプラグインがNetworkPolicyをサポートする
正解と解説

正解: B) NetworkPolicyがなければすべてのトラフィックが許可され、ポリシーが適用されると明示的に許可されたトラフィックのみ通過する

デフォルトでKubernetesはすべてのPod間通信を許可します。NetworkPolicyを適用すると、選択されたPodに対して明示的に許可されたイングレス/イグレストラフィックのみが通過します。ただし、CNIプラグインがNetworkPolicyをサポートする必要があります。


問題20. シークレット管理

Kubernetes Secretのデフォルト保存方式に関する正しい説明は?

  • A) デフォルトでAES-256で暗号化されてetcdに保存される
  • B) デフォルトではBase64エンコードのみでetcdに保存され、暗号化にはEncryptionConfigurationを別途設定する必要がある
  • C) Secretはメモリにのみ保存され、ディスクには書き込まれない
  • D) Secretは自動的にVaultに保存される
正解と解説

正解: B) デフォルトではBase64エンコードのみでetcdに保存され、暗号化にはEncryptionConfigurationを別途設定する必要がある

Kubernetes Secretはデフォルトでは Base64エンコードされた状態でetcdに保存されます。これは暗号化ではないため、etcdへのアクセス権限があればシークレットを読めます。暗号化にはEncryptionConfigurationの設定またはKMSプロバイダの使用が必要です。


問題21. イメージスキャニング

コンテナイメージ脆弱性スキャニングツールでないものは?

  • A) Trivy
  • B) Grype
  • C) Clair
  • D) Helm
正解と解説

正解: D) Helm

Trivy(Aqua Security)、Grype(Anchore)、Clair(Quay)はすべてコンテナイメージ脆弱性スキャニングツールです。HelmはKubernetesパッケージマネージャーでセキュリティスキャニングとは関連がありません。


問題22. RBAC最小権限原則

RBACで最小権限原則を適用する際の正しいアプローチは?

  • A) すべてのServiceAccountにcluster-adminロールを付与する
  • B) 必要なリソースと動詞(verbs)のみを含むRoleを作成し、最小範囲のRoleBindingを使用する
  • C) ClusterRoleのみ使用し、ネームスペースRoleは使用しない
  • D) ワイルドカード(*)を使用してすべてのリソースへのアクセスを許可する
正解と解説

正解: B) 必要なリソースと動詞(verbs)のみを含むRoleを作成し、最小範囲のRoleBindingを使用する

最小権限原則は必要最小限の権限のみを付与することです。特定リソースの特定の動詞のみ許可するRoleを作成し、該当ネームスペースにのみ適用するRoleBindingを使用します。ワイルドカードの使用とcluster-adminの乱用を避ける必要があります。


問題23. mTLS(相互TLS)

サービスメッシュにおけるmTLSの役割は?

  • A) サービス間通信を圧縮する
  • B) サーバーとクライアントの両方が証明書で相互認証し、通信を暗号化する
  • C) DNSクエリを暗号化する
  • D) ロードバランシングを行う
正解と解説

正解: B) サーバーとクライアントの両方が証明書で相互認証し、通信を暗号化する

mTLS(mutual TLS)はサーバーだけでなくクライアントも証明書を提示して双方向認証を行います。Istio、Linkerdなどのサービスメッシュはサイドカープロキシを通じてサービス間のmTLSを自動的に適用します。


問題24. 監査ログ

Kubernetes監査ログのレベルで最も詳細な情報を記録するものは?

  • A) None
  • B) Metadata
  • C) Request
  • D) RequestResponse
正解と解説

正解: D) RequestResponse

Kubernetes監査ログはNone(記録なし)、Metadata(リクエストメタデータのみ)、Request(メタデータ+リクエスト本文)、RequestResponse(メタデータ+リクエスト+レスポンス本文)の4段階をサポートします。RequestResponseが最も詳細です。


問題25. SecurityContext

PodレベルのSecurityContextで設定できない項目は?

  • A) runAsUser
  • B) fsGroup
  • C) networkPolicy
  • D) runAsNonRoot
正解と解説

正解: C) networkPolicy

Pod SecurityContextではrunAsUser、runAsNonRoot、runAsGroup、fsGroup、supplementalGroups、sysctls、seccompProfileなどを設定できます。NetworkPolicyは別のKubernetesリソースで、SecurityContextとは関連がありません。


問題26. AppArmorとSeccomp

Seccompプロファイルの役割は?

  • A) ファイルシステムアクセスを制御する
  • B) コンテナが使用できるシステムコールをフィルタリングする
  • C) ネットワークトラフィックを制限する
  • D) CPU使用量を制限する
正解と解説

正解: B) コンテナが使用できるシステムコールをフィルタリングする

Seccomp(Secure Computing Mode)はプロセスが呼び出せるシステムコールを許可リストまたはブロックリストでフィルタリングします。KubernetesではseccompProfileを通じてRuntimeDefaultまたはカスタムプロファイルを適用できます。


問題27. イメージポリシー

Kubernetesで信頼できるイメージのみの実行を強制する方法は?

  • A) すべてのイメージにlatestタグを使用する
  • B) Admission Controller(Kyverno、OPA)を通じて署名されたイメージのみを許可するポリシーを適用する
  • C) パブリックレジストリからのみイメージを取得する
  • D) imagePullPolicyをNeverに設定する
正解と解説

正解: B) Admission Controller(Kyverno、OPA)を通じて署名されたイメージのみを許可するポリシーを適用する

KyvernoのverifyImagesルールやOPA/GatekeeperのConstraintTemplateを使用して、cosign署名またはNotation署名が検証されたイメージのみのデプロイを許可できます。これはサプライチェーンセキュリティの核心的な要素です。


問題28. ServiceAccountセキュリティ

Kubernetes 1.24以降のServiceAccountトークン管理の変更点は?

  • A) ServiceAccountトークンが完全に削除された
  • B) 自動マウントされる永続トークンが生成されなくなり、TokenRequest APIによる短期トークンの使用が推奨される
  • C) すべてのPodにcluster-adminトークンが自動マウントされる
  • D) ServiceAccountがもはや存在しない
正解と解説

正解: B) 自動マウントされる永続トークンが生成されなくなり、TokenRequest APIによる短期トークンの使用が推奨される

Kubernetes 1.24からServiceAccount作成時にSecretが自動的に生成されなくなりました。代わりにTokenRequest APIを通じて時間制限のある短期トークンを発行する方式が推奨され、セキュリティが強化されました。


問題29. コンテナ分離

gVisorとKata Containersが提供するセキュリティ上のメリットは?

  • A) ネットワーク暗号化
  • B) カーネルを共有しないか追加の分離レイヤーを通じてコンテナエスケープのリスクを軽減する
  • C) イメージ署名の検証
  • D) RBACポリシーの強化
正解と解説

正解: B) カーネルを共有しないか追加の分離レイヤーを通じてコンテナエスケープのリスクを軽減する

gVisorはユーザー空間カーネル(application kernel)を提供してホストカーネルへの直接システムコールを遮断します。Kata Containersは軽量VM内でコンテナを実行してハードウェアレベルの分離を提供します。どちらもRuntimeClassを通じて選択的に使用します。


問題30. 総合セキュリティベストプラクティス

多層防御(Defense in Depth)戦略に該当しないものは?

  • A) イメージスキャニング + 署名検証
  • B) NetworkPolicy + mTLS
  • C) RBAC + Pod Security Standards
  • D) すべてのワークロードをrootで実行しprivilegedモードを使用
正解と解説

正解: D) すべてのワークロードをrootで実行しprivilegedモードを使用

多層防御は複数のセキュリティレイヤーを重ねて、1つのレイヤーが失敗しても他のレイヤーが保護する戦略です。イメージセキュリティ、ネットワークセキュリティ、アクセス制御、ランタイムセキュリティを組み合わせます。root実行とprivilegedモードはセキュリティベストプラクティスに反します。


まとめ

この30問はKCSA試験のコアドメインであるサプライチェーンセキュリティランタイムセキュリティプラットフォームセキュリティネットワークセキュリティコンプライアンスとセキュリティフレームワークを深く学習するために構成されました。実際の試験ではKubernetesセキュリティメカニズムだけでなく、CNCFセキュリティエコシステム全般に対する理解が求められます。