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　これもどちらの形態でも利用者責任であり、両者の差分にはならない

正解：B

A　既定のクラスタネットワークはフラットで、Namespaceが違ってもPodは相互に通信できる。遮断にはNetworkPolicyが必要

B（正解）　正解。カーネルレベルやネットワークの分離は提供しない。NamespaceはAPI上のスコープであり、RBACやResourceQuota、NetworkPolicyの適用単位として使うことで初めて実効的な分離になる

C　ノード上のコンテナはホストのカーネルを共有する。KubernetesのNamespaceとLinuxのnamespaceは別概念で、混同されやすい

D　スケジューリング先は分離されない。ノードを分けたい場合はtaint/tolerationやnodeSelectorが必要

正解：D

A　SELinuxは強制アクセス制御、iptablesはパケットフィルタで、いずれも分離を補強するが基礎機構ではない

B　仮想マシンの分離技術。通常のコンテナはVMを介さずホストカーネルを共有する

C　chrootは限定的なファイルシステムの見え方の変更にすぎず、sudoは権限昇格のためのツールで分離機構ではない

D（正解）　正解。namespacesがプロセスやネットワーク、マウントなどの可視範囲を分離し、cgroupsがCPUやメモリといった資源の使用量を制限する

正解：C

A　API上の区切りが増えるだけで、カーネルを共有しているという構造は変わらない

B　資源の枯渇には有効だが、カーネルの脆弱性を突いた脱出は防げない

C（正解）　正解。サンドボックス化されたランタイムを使い、システムコールを仲介するユーザ空間カーネルや軽量VMを挟むことで、ホストカーネルへの攻撃面を大きく減らせる

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やアドミッション制御を丸ごと迂回する経路になる

正解：A

A（正解）　正解。期限が近づくとkubeletが自動でCertificateSigningRequestを提出し、承認されると新しい証明書を受け取るため、短い有効期限でも運用できる

B　長期証明書は漏えいしたときに影響が長く続くため、セキュリティ上は逆行する

C　静的トークンは失効も監査も難しく、推奨されない認証方式

D　認証の無効化は攻撃面を最大化するため、選択肢になりえない

正解：C

A　性能上の理由ではない

B　1つのCAから多数の証明書を発行することは技術的に可能

C（正解）　正解。CAを分ければ、一方のCAで発行された証明書が他方では受け入れられなくなる。CAを分けることは信頼境界を分けることであり、侵害時の横展開を抑えられる

D　CAを分割しても失効の仕組みが増えるわけではない

正解：B

A　性能を目的とした設定ではない

B（正解）　正解。内部情報の漏えいや不要な攻撃面を減らせる。外部へ晒す必要のないエンドポイントはループバックに限定するという、攻撃面の最小化の考え方に沿っている

C　リーダー選出はkube-apiserver経由で行われ、バインドアドレスとは無関係

D　むしろ逆で、外部やPodからの接続を到達不能にするための設定

正解：D

A　知られていないことに頼る対策で、ポートスキャンによって容易に発見される

B　クライアント側の更新は重要だが、APIサーバがインターネットに晒されている状態は変わらない

C　事後の検知には役立つが、予防的な攻撃面の削減にはならない

D（正解）　正解。到達できないものは攻撃できないという原則どおり、露出そのものを減らすのが最も効果が大きい。やむを得ず公開する場合も許可リストで到達範囲を絞る

正解：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内でのみ有効で、動詞も参照系に絞られるため最小権限になる

正解：B

A　RBACでRoleのcreate権限を与えれば、一般ユーザでもRoleを作成できる

B（正解）　正解。Roleの作成・更新時にこの制約がかかる。なければRoleのcreate権限だけを起点にcluster-admin相当まで自力で昇格できてしまう

C　RBACに承認ワークフローは組み込まれていない

D　そのような自動削除の仕組みは存在しない

正解：A

A（正解）　正解。PodまたはServiceAccountで指定できる。トークンが存在しなければ、コンテナが侵害されてもそれを使ってAPIサーバへアクセスされることはない

B　必要のない最大権限を与えることになり、対策として真逆

C　既定ではトークンがマウントされるため、攻撃面は残ったままになる

D　APIトークンの問題とは無関係なうえ、ネットワークの分離を弱めてしまう

正解：C

A　どちらも署名付きJWTであり、暗号化されているわけではない

B　検証はどちらの方式でもkube-apiserverが行う

C（正解）　正解。Podが消えたり期限が切れれば漏えいしても使えなくなる。永続トークンは削除しない限り無期限に有効でaudienceの制限もないため、漏えい時の影響が大きい

D　投影トークンはボリュームとしてファイルにマウントされる。環境変数のほうがむしろ漏えい経路が多い

正解：D

A　ハッシュ化すると元の値を取り出せない。Secretは利用のために復元可能な形で保存される

B　他のリソースと同様にetcdへ永続化される

C　get権限を持つユーザはkubectlでSecretの内容を取得できるため、参照権限の設計が重要になる

D（正解）　正解。base64は符号化であって暗号化ではないため、保存時暗号化、RBACによる参照制限、外部シークレット管理との連携が必要になる

正解：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　自動的な共有は起きない。問題はホスト側のデータへ到達できてしまうこと

正解：A

A（正解）　正解。全ノードで動くDaemonSetや定期実行のCronJobなら、個々のPodを削除されても再作成される。想定外のワークロード作成をアドミッション制御と監査で押さえることが対策になる

B　資源割り当ての変更にすぎず、アクセスの維持にはつながらない

C　外部からの到達性は増えるが、これ単体は永続化というより露出の問題

D　単なる情報収集であり、永続化にはあたらない

正解：D

A　ネットワーク経路の制御であり、計算資源の枯渇は防げない

B　分離を弱めるだけで、資源枯渇の対策にはならない

C　既知脆弱性の把握には有効だが、資源の消費量は抑えられない

D（正解）　正解。limitsで個々のコンテナの上限を、ResourceQuotaでNamespace全体の総量を制限し、LimitRangeで未指定時の既定値を強制することで、隣接するワークロードへの影響を抑えられる

正解：C

A　推奨される扱い方。ファイルはメモリ上に置かれ、Podの削除とともに消える

B　Kubernetesの外で集中管理・ローテーションでき、望ましい選択肢のひとつ

C（正解）　正解。イメージ層に残るためレジストリを参照できる全員が取得でき、履歴からも消しにくい。ローテーションのたびに再ビルドも必要になる

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の検証対象になり、ポリシーの抜けを防げる

正解：C

A　Webhookが応答しないリクエストをそのまま通すため、Webhookを落とせばポリシーを回避できてしまう

B　待ち時間が延びるだけで最終的に失敗した場合の扱いは決まらず、APIサーバの応答性も悪化する

C（正解）　正解。Webhookが応答しない場合はリクエストを拒否するためポリシーの回避を防げる。ただしWebhookの可用性がクラスタの可用性に直結する点には注意が必要

D　Webhookが外部に副作用を持たないことを宣言するフィールドで、障害時の挙動とは関係しない

正解：B

A　リクエストとレスポンスの本文が記録されるため、Secretの中身が監査ログに平文で残ってしまう

B（正解）　正解。誰がいつ何にアクセスしたかは記録しつつ本文は残さないことで、追跡可能性を確保しながら、監査ログ自体が新たな漏えい経路になることを避けられる

C　Secretへのアクセスこそ追跡すべき対象であり、記録しないのは検知と否認防止の観点で問題がある

D　クラスタを掌握した攻撃者に改ざんされうる。監査ログはクラスタ外の追記専用のストレージへ送るのが望ましい

正解：A

A（正解）　正解。eBPFやカーネルモジュールを使うFalcoに代表されるこの種のツールは、イメージスキャンやアドミッション制御では捉えられない実行時の異常を検知する

B　デプロイ前に既知の脆弱性を見つける仕組みで、実行時の挙動は見ていない

C架空　このような標準コンポーネントは存在しない

D　Namespaceの資源使用量に上限を設ける仕組みで、挙動の検知は行わない

正解：B

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

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

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

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

正解：C

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

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

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

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

正解：A

A（正解）　正解。イメージ、レジストリ、オーケストレータ、コンテナ、ホストOSという主要コンポーネントごとに、特定の製品に依存しない形でコンテナ環境の脅威と緩和策の考え方を体系的に示している

B　それはPCI DSSの説明

C　APIの仕様はKubernetesプロジェクトが公開するもの

D　それはGDPRの説明

正解：D

A　サービス組織の内部統制に関する保証報告の枠組みで、カード会員データ固有の要求ではない

B　情報セキュリティマネジメントシステムの認証規格で、カード会員データに特化した要求ではない

C　米国における医療情報の保護に関する法規制で、対象とするデータが異なる

D（正解）　正解。カード会員データを扱う環境に対し、ネットワークの分離、保存データの暗号化、アクセス制御、ログの保持などを具体的に要求する

正解：C

A　点の記録にすぎず、記録と記録の間の期間に生じた逸脱を検知できない

B　証跡が残らず再現性もないため、監査に耐えられない

C（正解）　正解。デプロイ前(CI)とデプロイ時(アドミッション)の両方に強制ポイントを置くことで、逸脱の発生自体を防ぎながら、検証結果が監査証跡として自動的に蓄積される

D　逸脱した状態が長期間放置されることを許容してしまう