KCSA サンプル問題

正解：B

A　Kubernetesクラスタ自体の層。Cloudの内側にあり、土台であるCloud層の設定に依存する

B（正解）　正解。4CはCloud→Cluster→Container→Codeという入れ子構造で、Cloud(またはデータセンターや企業ネットワーク)が最も外側の土台となる

C　イメージとランタイムの層。内側から2番目で、土台ではない

D　最も内側のアプリケーションコードの層。4Cの中心であって土台ではない

正解：D

A　実際は逆で、基盤が脆弱ならアプリケーションだけを強化しても保護しきれない

B　4層は入れ子であり独立していない。単層のみの対策では防御に穴が残る

C　責任共有モデルにより、ネットワーク設計やIAMなど利用者側に残る設定責任がある

D（正解）　正解。多層防御の考え方であり、外側の層の弱点は内側の層の対策では埋め合わせられないというのが4Cの基本思想

正解：C

A　マネージドサービスでは事業者が管理する領域で、利用者は通常アクセスできない

B　一般にマネージド側で提供される。利用者がetcdを直接操作できないことが多い

C（正解）　正解。クラスタに何をどう配置するかは、どの提供形態でも常に利用者の責任として残る

D　コントロールプレーンのソフトウェア保守は事業者側の責任

正解：A

A（正解）　正解。セルフマネージドではkube-apiserverの起動フラグやetcdの保存時暗号化を含め、コントロールプレーンの設定・更新・保護がすべて利用者責任になる

B　どちらの形態でも常に利用者の責任であり、追加で負うものではない

C　IaaSを利用する限り、物理層はクラウド事業者の責任のまま

D　これもどちらの形態でも利用者責任であり、両者の差分にはならない

正解：D

A　etcdはクラスタのすべてのAPIオブジェクトを保持する

B　既定では保存時暗号化は有効になっておらず、EncryptionConfigurationの明示的な設定が必要

C　RBACはkube-apiserver上の仕組み。etcdに直接アクセスされた場合、RBACは一切効かない

D（正解）　正解。Secretを含むすべてのオブジェクトが平文で保存される。だからこそetcdは相互TLS、ネットワーク到達性の制限、保存時暗号化という多層で守る必要がある

正解：B

A　etcdはKubernetesのRBACを使わないため制限は効かず、全公開は最悪の構成になる

B（正解）　正解。etcd自身の認証は専用CAで発行した証明書ベースで行い、加えて到達できるネットワークをコントロールプレーンに限定する多層防御が推奨される

C　NetworkPolicyはPodネットワーク上の到達性制御であり、認証の代わりにはならない

D　CAを共有すると、片方で発行された証明書がもう一方でも受け入れられ、侵害の影響が両方へ及ぶ

正解：C

A　匿名リクエストもRBACによる認可を受けるため、無条件にcluster-adminになるわけではない

B　認証方式の設定と通信の暗号化はまったく別の話

C（正解）　正解。匿名リクエストはsystem:anonymousユーザ、system:unauthenticatedグループとして扱われる。このグループへ誤って広い権限をバインドしたことによる情報漏えいは実際に問題になっており、匿名アクセスは原則無効にする

D　匿名アクセスの可否とServiceAccountトークンの利用は独立している

正解：A

A（正解）　正解。kubelet APIはexecやlogsといった強力な操作を持つため、認可の素通しはノード乗っ取りに直結する。Webhookモードでkube-apiserverに認可を委譲すべき

B　認可モードの設定はPodの起動可否とは無関係

C　ノード登録は通常どおり行われる

D　レジストリの認証とkubelet APIの認可はまったく別の仕組み

正解：C

A　匿名アクセスを許したうえで認可も素通しにする、最も危険な組み合わせ

B　認可はkube-apiserverへ委譲されるが、匿名アクセスを残すと不要な攻撃面がそのまま残る

C（正解）　正解。匿名アクセスを拒否したうえで、認可判断をkube-apiserverのSubjectAccessReviewに委譲することで、kubelet APIへのアクセスをRBACで統制できる

D　認証は要求されるものの、認証さえ通れば何でもできてしまうため保護として不十分

正解：B

A　必要以上に広く、Secretまで読めてしまうため侵害時の被害が大きい

B（正解）　正解。kube-proxyの役目はServiceの通信ルールを維持することなので、転送ルールの生成に必要な情報の参照だけあればよい

C　kube-proxyはPodもDeploymentも作成・削除しない

D　転送ルールの生成にSecretは不要で、与えると侵害時に資格情報を持ち出される

正解：D

A　容量の問題ではない

B　kubeletの管理対象から外れるわけではない

C　それはhostNetworkを有効にした場合の説明で、ランタイムソケットの問題とは別

D（正解）　正解。ホストのファイルシステムをマウントしたコンテナも起動でき、KubernetesのRBACやアドミッション制御を丸ごと迂回する経路になる

正解：D

A　制限のないプロファイルで、既知の特権昇格をすべて許してしまう。信頼されたシステムワークロード向け

B　既知の特権昇格を防ぐ最小限の制限にとどめ、一般的なアプリを動かしやすくした中間のプロファイル

C架空　Pod Security Standardsにこの名前のプロファイルは存在しない

D（正解）　正解。現在のPodハードニングのベストプラクティスに沿った最も厳しいプロファイルで、runAsNonRootやseccompProfileの指定などを要求する

正解：B

A　違反するPodが即座に作成できなくなり、再起動やスケール時に本番障害を招く

B（正解）　正解。auditは監査ログに記録し、warnはkubectl実行時に警告を返すため、稼働に影響を与えずに違反を洗い出して適合状況を評価できる

C　稼働中のワークロードを失うだけで、適合状況の評価にはならない

D　セキュリティを著しく悪化させる操作であり、評価の手段としても意味がない

正解：C

A　非rootの要求はrestrictedの条件で、baselineではrootでの実行自体は許容される

B　Capabilityをほぼすべて削除させるのはrestricted。baselineは危険な追加Capabilityの付与を制限するにとどまる

C（正解）　正解。baselineはprivileged、hostNetwork/hostPID/hostIPC、任意のhostPathなど、既知の特権昇格につながる設定を禁じる最小限の制限として定義されている

D　イメージ署名の検証はPod Security Standardsの対象外で、別のアドミッション制御で実現する

正解：A

A（正解）　正解。ルートファイルシステムを読み取り専用にすることでバイナリやスクリプトの書き込みを防げる。書き込みが必要な箇所だけemptyDirをマウントする

B　コンテナをrootで実行させる設定であり、むしろ危険度を高める

C　ホストのデバイスやカーネル機能へのアクセスを許す最も危険な設定

D　コンテナ内のプロセスが新たな特権を得ることを許す設定。falseにすべきもので、ツールの書き込みや実行を妨げる効果はない

正解：B

A　ServiceAccountトークンをマウントしない設定で、プロセスの権限獲得とは別の対策

B（正解）　正解。Linuxのno_new_privsを設定し、実行中のプロセスが新たに特権を得ることを防ぐ。restrictedプロファイルでも必須とされる

C　ファイルシステムへの書き込みを防ぐ設定で、setuidによる昇格そのものを止めるものではない

D　ホストのネットワーク名前空間を使わないという既定の設定で、権限昇格の抑止とは目的が異なる

正解：C

A　ホストのほぼすべての権限を与えることになり、必要な権限に対して過剰

B　動作はするが、コンテナ内のプロセスがrootになるため侵害時の影響が大きくなる

C（正解）　正解。まず全Capabilityを外し、業務上必要な1つだけを戻すのが最小権限の原則に沿った設定になる

D　ホストのネットワーク名前空間を使うだけで低位ポートのbind権限は得られず、分離も大きく弱まる

正解：D

A　ClusterRoleBindingは全Namespaceに権限が及ぶため、devだけに限定できない

B　権限はdev内に限定されるが、そのNamespace内であらゆる操作ができてしまい参照権限をはるかに超える

C　認証情報の共有は誰の操作か追跡できなくなるうえ、権限も過剰になる

D（正解）　正解。get/list/watchのみを許可するRoleは対象Namespace内でのみ有効で、動詞も参照系に絞られるため最小権限になる

正解：D

A　他人の身元を騙る脅威。ここでの本質は痕跡を追えなくすることにある

B　データや設定の不正な書き換えを指す。ログ停止も書き換えを伴いうるが、STRIDEでは記録が残らないこと自体を指す分類が別にある

C　本来見えるべきでない情報が漏れる脅威で、この場面では情報は漏れていない

D（正解）　正解。誰が何をしたかを立証できなくなる脅威で、監査ログの停止・改ざん・保護不足が典型的な原因になる

正解：B

A　可用性を奪う攻撃を指す。ここではサービスは動き続けている

B（正解）　正解。想定された成果物が不正に書き換えられる脅威で、対策は署名とデプロイ時の署名検証、ダイジェストによる固定になる

C　行為を否認できてしまう脅威で、すり替えそのものの分類ではない

D　身元の詐称を指す。ここではイメージの中身が書き換えられた点が本質なのでTamperingが適切

正解：A

A（正解）　正解。与えられた権限を超える権限を獲得する脅威で、特権コンテナやhostPath、ランタイムソケットのマウントが代表的な経路になる

B　結果として情報も漏れうるが、この事象の本質は権限そのものの獲得にある

C　可用性への攻撃であり、ここでの本質ではない

D　行為の追跡可能性に関する脅威で、分類が異なる

正解：C

A　通常のコンテナはホストカーネルを共有するため、VM同士に比べて境界は弱い

B　同一Namespaceでも、Podごとに扱うデータや権限が異なるため境界として考慮すべき

C（正解）　正解。だからこそSecurityContextによる制限、seccompやAppArmor、必要に応じたサンドボックスランタイムの併用が重要になる

D　kube-apiserverは送信元にかかわらず認証と認可を行う。内部だから信頼するという設計ではない

正解：B

A　性能や可用性ではなく、権限と到達範囲が問題の本質

B（正解）　正解。他コンテナのファイルにも到達でき、ノードの掌握や、起動時に実行される設定の書き換えによる永続化にも悪用される

C　それはhostNetworkの効果であり、hostPathとは別

D　自動的な共有は起きない。問題はホスト側のデータへ到達できてしまうこと

正解：C

A架空　このようなkubectlのサブコマンドは存在しない。また人手の取り決めは強制力を持たない

B　タグ運用の改善にはなるが、署名の有無は一切検証できない

C（正解）　正解。署名と信頼された発行者を、デプロイ経路上の強制ポイントであるアドミッションで検証することで、抜け道なくポリシーを適用できる

D　取得元の制限にはなるが、そのレジストリに置かれたイメージが正当な出所かどうかまでは保証できない

正解：D

A　SBOMは構成情報の一覧であり、イメージの軽量化とは無関係

B　それはランタイムセキュリティツールの役割で、SBOMは実行時の監視を行わない

C　SBOMは目録であって、予防的な実行制御は行わない

D（正解）　正解。依存関係とバージョンの目録があることで、再スキャンの完了を待たずに影響を受けるコンポーネントを含む成果物を特定でき、対応の優先順位付けができる

正解：B

A　ベースイメージに含まれるパッケージも含めて検査できる

B（正解）　正解。ビルド時に問題がなかったイメージも後から脆弱になる。レジストリ上の既存イメージや稼働中のワークロードを定期的に再スキャンし、再ビルドと再デプロイにつなげる運用が必要になる

C　同じイメージを本番で動かすのだから当然影響する

D　イメージスキャナはレジストリ上のイメージも検査できる

正解：A

A（正解）　正解。同じマニフェストでも取得されるイメージが変わりうる。sha256ダイジェストで指定すれば内容が一意に固定されるため、再現性とサプライチェーンの完全性の観点から本番ではダイジェスト指定が推奨される

B　取得はできる。問題は取得できるかどうかではなく、何が取得されるかが不定な点にある

C　タグを省略した場合やlatestの場合の既定はAlwaysで、Neverにはならない

D　タグの名前によって署名検証の要否が変わることはない

正解：D

A　順序は決まっており、Mutatingが先、Validatingが後に実行される

B　オブジェクトの書き換えはMutatingの役割で、Validatingは許可か拒否かを返すだけ

C架空　このような種類のアドミッションWebhookは存在しない

D（正解）　正解。Mutatingがオブジェクトを書き換え、Validatingが最終的な内容を検証して許可・拒否を判断する。この順序により、Mutatingが追加・変更した内容もValidatingの検証対象になり、ポリシーの抜けを防げる

正解：B

A　試験のカリキュラムはLinux FoundationやCNCFが公開するもので、CISの文書ではない

B（正解）　正解。コントロールプレーンやノードの設定について、匿名認証を無効にする、といった具体的な推奨を、監査可能なチェック項目として提供する

C　パッケージの許可リストを配布する文書ではない

D　契約文書ではなく、技術的な設定基準にあたる

正解：C

A架空　このような名前のツールは存在しない

B　ローカルのマニフェストとクラスタ上の状態の差分を表示するコマンドで、ベンチマークの評価は行わない

C（正解）　正解。CIS Kubernetes Benchmarkの各項目をテストとして実装しており、ノードやコントロールプレーンの設定を検査して合否と是正方法を出力する

D　etcdを直接操作するCLIで、ベンチマークの検査用途ではない