KCSAクラウドネイティブセキュリティアソシエイト 模擬試験60問

A) Code B) Container C) Cluster D) Cloud

答え: D

解説: 4Cセキュリティモデルは Cloud（最も外側）→ Cluster → Container → Code（最も内側）の順です。Cloudレイヤーは IaaS インフラ、ネットワーク、ストレージのセキュリティを担います。各レイヤーは内側のレイヤーを保護し、外側のレイヤーが脆弱だと内側が安全でも意味がなくなります。

A) 1つの強力なセキュリティレイヤーに集中する B) 複数の独立したセキュリティレイヤーを実装し、1つが失敗しても他が保護できるようにする C) セキュリティを外部境界のみに集中する D) 暗号化だけですべてのセキュリティ要件を満たす

答え: B

解説: Defense in Depth（多層防御）は複数の独立したセキュリティ制御（レイヤー）を実装し、1つが失敗しても他が攻撃を防げるようにする原則です。Kubernetesではネットワークポリシー、RBAC、Pod Security Standards、イメージスキャンなど複数のレイヤーを組み合わせて適用します。

A) 内部ネットワークは信頼し、外部ネットワークのみ検証する B) 「絶対に信頼せず、常に検証する」 - 内外すべてのリクエストを認証し、権限を最小限に付与する C) VPNで接続したユーザーはすべて信頼する D) ファイアウォール内のトラフィックは自由に許可する

答え: B

解説: Zero Trustは「Never Trust, Always Verify」の原則で、ネットワークの場所に関わらず（内部/外部）すべてのリクエストを認証・認可します。最小権限、マイクロセグメンテーション、継続的なモニタリングが核心です。KubernetesではRBAC、mTLS、NetworkPolicyがZero Trustを実装します。

A) 脆弱性に対する一意識別子と公開データベース B) コンテナイメージ署名の標準 C) Kubernetesセキュリティ設定フレームワーク D) ネットワーク脆弱性スキャナーツール

答え: A

解説: CVEは公開された既知のソフトウェア脆弱性に付与される一意識別子です（例: CVE-2024-XXXX）。CVSS（Common Vulnerability Scoring System）は0.0〜10.0のスコアで深刻度を測定します（Critical: 9.0〜10.0、High: 7.0〜8.9、Medium: 4.0〜6.9、Low: 0.1〜3.9）。コンテナイメージスキャンツール（Trivy、Grype）はCVEデータベースに基づいて脆弱性を検出します。

A) X.509クライアント証明書 B) ServiceAccountトークン C) OIDC（OpenID Connect） D) MD5パスワードハッシュ

答え: D

解説: Kubernetes APIサーバーがサポートする認証メカニズムはX.509証明書、Bearer Token（ServiceAccount）、OIDC（Google、Dexなど）、Webhook、HTTP基本認証（非推奨）などです。MD5パスワードハッシュはKubernetesの認証方式に含まれていません。

A) etcdの処理速度を上げるため B) SecretなどLの機密データがetcdに平文で保存されるのを防ぐため C) ネットワーク転送中のデータを保護するため D) コンテナイメージを暗号化するため

答え: B

解説: Kubernetes Secretはデフォルトでbase64エンコード（暗号化ではない）でetcdに保存されます。etcdに直接アクセスできる攻撃者はすべてのSecretデータを読み取れます。Encryption at Restを設定すると、etcdに書き込まれるデータ（特にSecret）がAES-CBCまたはAES-GCMで暗号化されます。

A) 匿名認証を有効にするとkubelet APIが認証なしでアクセス可能になり、セキュリティリスクになる B) 匿名認証はパフォーマンスを低下させる C) 匿名認証はPodのスケジューリングを妨げる D) 匿名認証はコントロールプレーンとの通信をブロックする

答え: A

解説: Kubeletは10250ポートでAPIを提供します。--anonymous-auth=true（デフォルト）の場合、匿名リクエストがsystem:anonymousユーザーとして処理されます。これを悪用すると認証なしでノードのPodリスト確認、ログアクセス、コマンド実行が可能になります。--anonymous-auth=falseとWebhook認証の設定が推奨されます。

A) ClusterRoleはより強力な権限を持つ B) RoleL は特定のNamespace内のリソースにのみ適用され、ClusterRoleはクラスター全体またはクラスターレベルのリソースに適用される C) ClusterRoleはServiceAccountにのみバインドできる D) Roleはすべてのネームスペースで使用できる

答え: B

解説: Roleは特定のNamespace内のリソースに対する権限を定義し、RoleBindingで適用します。ClusterRoleはNamespaceに関係なくクラスター全体またはNode、PersistentVolumeのようなクラスターレベルのリソースの権限を定義し、ClusterRoleBindingで適用します。ClusterRoleをRoleBindingで特定のNamespaceにのみ適用することもできます。

A) クラスターにユーザーを追加する役割 B) APIリクエストがetcdに保存される前にリクエストを検証または修正するプラグイン C) コンテナランタイムを管理する役割 D) ネットワークトラフィックを監視する役割

答え: B

解説: Admission Controllerはkube-apiserverで認証/認可の後、etcd保存の前に実行されるプラグインです。Validating Admission Webhookはリクエストを検証（拒否可能）し、Mutating Admission Webhookはリクエストを修正（デフォルト値の注入、サイドカー注入など）します。OPA GatekeeperやKyvernoがこのメカニズムを活用します。

A) runAsNonRoot: true B) allowPrivilegeEscalation: false C) privileged: true D) seccompProfileの設定

答え: C

解説: Restrictedプロファイルは最も厳格なPod Security Standardです。runAsNonRoot: true、allowPrivilegeEscalation: false、readOnlyRootFilesystem: true（強く推奨）、seccompProfileの設定、ホスト名前空間の使用禁止などを要求します。privileged: trueはPrivilegedプロファイルでのみ許可され、Restrictedでは明示的に禁止されています。

A) kube-apiserverでネットワークオプションを無効にする B) 空のpodSelectorを持つNetworkPolicyを作成してすべてのトラフィックをブロックする C) 各ノードでファイアウォールルールを設定する D) containerdの設定でネットワークを無効にする

答え: B

解説: KubernetesのNetworkPolicyでDefault Denyを実装するには、空のpodSelector: {}（すべてのPodにマッチ）と空のingress: []（すべてのIngressをブロック）を持つNetworkPolicyをNamespaceに適用します。Egress Default Denyも別途設定できます。その後、必要なトラフィックのみを許可する追加NetworkPolicyを作成します。

A) Secretは完全に安全なので追加対策は不要 B) Secretはデフォルトでbase64エンコードのみなので、etcd暗号化+外部シークレット管理（Vault、ESO）を推奨 C) Secretを多く作成するほどセキュリティが強化される D) SecretはConfigMapより常に安全である

答え: B

解説: Kubernetes Secretのセキュリティ問題: 1) etcdにbase64（エンコード、暗号化ではない）で保存、2) RBACなしでNamespace内のすべてのユーザーがアクセス可能、3) ログや環境変数出力時の露出リスク。改善策: etcd Encryption at Restの有効化、RBAC最小権限の適用、HashiCorp Vault/External Secrets Operator（ESO）/Sealed Secretsの使用。

A) コンテナが読み取り操作のみを実行するよう制限 B) コンテナのルートファイルシステムを読み取り専用にし、ランタイム中のファイル変更を不可にする C) コンテナイメージのダウンロードをブロック D) Secretファイルを読み取り専用でマウント

答え: B

解説: readOnlyRootFilesystem: trueはコンテナのルートファイルシステムを読み取り専用に設定します。攻撃者がコンテナに侵入しても、ファイルシステムにマルウェアを書き込んだり設定を変更したりできません。書き込みが必要な場合は特定のパスにemptyDirボリュームをマウントして対応します。

A) すべてのPodにcluster-admin ClusterRoleを付与する B) automountServiceAccountToken: falseを設定し、必要な権限のみを明示的に付与する C) すべてのPodで同じServiceAccountを共有する D) ServiceAccountを使用しない

答え: B

解説: 最小権限の原則（Principle of Least Privilege）の適用: 1) Kubernetes APIへのアクセスが不要なPodにはautomountServiceAccountToken: falseを設定、2) アプリケーションごとに専用のServiceAccountを作成、3) 必要なリソース/verbのみを許可する細かいRBAC Roleを定義、4) default ServiceAccountの使用を最小化。

A) Security、Threats、Risk、Identity、Defense、Encryption B) Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilege C) System、Technology、Runtime、Infrastructure、Development、Environment D) Scanning、Testing、Review、Inspection、Detection、Enforcement

答え: B

解説: STRIDEはマイクロソフトが開発した脅威モデリングフレームワークです: Spoofing（なりすまし）、Tampering（データ改ざん）、Repudiation（否認）、Information Disclosure（情報漏洩）、Denial of Service（サービス妨害）、Elevation of Privilege（権限昇格）。Kubernetesのセキュリティ設計で各脅威に対応するコントロールを設計します。

A) runAsNonRoot: true B) privileged: true C) readOnlyRootFilesystem: true D) allowPrivilegeEscalation: false

答え: B

解説: privileged: trueはコンテナにホストノードとほぼ同等の権限を付与します。この設定があるコンテナはノードのすべてのデバイスアクセス、カーネルモジュールのロード、ネットワーク設定の変更が可能になり、コンテナの境界を脱出してホストノードを制御できます。Pod Security StandardsのBaselineレベル以上ではこの設定が禁止されています。

A) APIサーバーの公開はパフォーマンスにのみ影響する B) 認証の脆弱性があると攻撃者がクラスター全体を制御できる C) APIサーバーは常にパブリックに公開すべきである D) APIサーバーの公開はセキュリティ上の問題がない

答え: B

解説: kube-apiserverはクラスターの中央コントロールポイントです。外部公開+認証の脆弱性が組み合わさると、攻撃者が悪意のあるPodのデプロイ、RBAC操作、Secretの窃取、ノードの乗っ取りなどクラスター全体を制御できます。公開されたKubernetes APIサーバーをスキャンする攻撃が継続的に発生しています。APIサーバーは最低限IPホワイトリストと強力な認証で保護すべきです。

A) コンテナイメージの脆弱性スキャン B) ランタイムセキュリティ - システムコールレベルでコンテナ内の異常動作をリアルタイム検出 C) Kubernetesネットワークポリシーの自動生成 D) RBAC権限の自動設定

答え: B

解説: FalcoはCNCF GraduatedプロジェクトでLinuxカーネルのeBPF/カーネルモジュールを通じてシステムコールをリアルタイム監視します。ルールベースで異常動作（権限のないネットワーク接続、機密ファイルアクセス、シェル実行など）を検出してアラートを発します。イメージスキャン（静的解析）と異なり、ランタイム時の実際の動作を監視します。

A) ソフトウェアのライセンスコストを計算するツール B) ソフトウェアを構成するすべてのコンポーネント、ライブラリ、依存関係の一覧 - 脆弱性の把握とコンプライアンスに活用 C) コンテナイメージビルド自動化ツール D) コードデプロイを制御するポリシーエンジン

答え: B

解説: SBOM（ソフトウェア部品表）はソフトウェアを構成するすべてのコンポーネント、ライブラリ、依存関係とそのバージョン情報を列挙したリストです。CVE脆弱性発見時に影響を受けるソフトウェアを素早く把握し、オープンソースライセンス準拠の確認に活用されます。SPDXとCycloneDXが主要なSBOMフォーマットです。

A) コンテナランタイムセキュリティの監視 B) コンテナイメージとソフトウェアアーティファクトの署名と検証 - サプライチェーンセキュリティ C) Kubernetesクラスターの脆弱性スキャン D) ネットワークトラフィックの暗号化

答え: B

解説: SigstoreはLinux Foundationのプロジェクトで、Cosign（イメージ署名/検証）、Fulcio（コード署名証明書の発行）、Rekor（透明な署名ログ）で構成されます。開発者がコンテナイメージとソフトウェアアーティファクトに署名し、デプロイ時に署名を検証してサプライチェーン攻撃（イメージ改ざん）を防ぎます。Admission Controllerと連携して署名済みイメージのみを許可できます。

A) Kubernetesクラスター設定の監視 B) コンテナイメージ、ファイルシステム、Gitリポジトリの脆弱性（CVE）、シークレット、IaCの設定ミスのスキャン C) ランタイム時のシステムコール監視 D) サービスメッシュのmTLS管理

答え: B

解説: TrivyはAqua Securityが開発したオープンソースの脆弱性スキャナーです。コンテナイメージ、ファイルシステム、Gitリポジトリ、KubernetesクラスターでCVE脆弱性、露出したシークレット、Dockerfile/IaCの設定ミスを検出します。CI/CDパイプラインに統合してビルド時点で脆弱なイメージのデプロイをブロックできます。

A) コンテナイメージの署名検証 B) サービス間の双方向認証と暗号化 - 通信する両側が証明書でアイデンティティを証明 C) Pod間のトラフィックのロードバランシング D) データベース接続の暗号化

答え: B

解説: mTLS（相互TLS）は通常のTLSとは異なり、クライアントとサーバーの両方が証明書でアイデンティティを証明します。サービスメッシュ（Istio、Linkerd）ではすべてのサービス間通信に自動的にmTLSを適用し、内部ネットワークでの盗聴（eavesdropping）やMITM（Man-in-the-Middle）攻撃を防ぎます。Zero Trustネットワークの核心コンポーネントです。

A) Kubernetesクラスターのデプロイを管理するため B) 集中化されたシークレット管理 - 動的シークレット生成、自動有効期限、監査ログを提供 C) コンテナイメージレジストリとして使用するため D) Kubernetesネットワークポリシーを管理するため

答え: B

解説: HashiCorp Vaultはエンタープライズ級のシークレット管理ソリューションです。Kubernetesと連携する際: 動的データベース認証情報の生成（リクエストごとに有効な一時認証情報を発行）、自動的な有効期限/更新、アクセスログ、強力な暗号化を提供します。Vault AgentやExternal Secrets Operator（ESO）を通じてVaultのシークレットをKubernetes Secretに同期します。

A) Secretをファイルシステムから完全に削除する B) 公開鍵でSecretを暗号化したSealedSecretオブジェクトをGitに安全に保存し、クラスターのコントローラーが復号化する C) SecretをL外部サーバーにバックアップする D) SecretをLART複数のNamespaceに複製する

答え: B

解説: Sealed SecretsBitnami が開発したツールです。kubeseal CLIでクラスターの公開鍵を使用してSecretを暗号化したSealedSecretオブジェクトを作成すると、これをGitに安全に保存できます。クラスターのSealed Secretsコントローラーのみが秘密鍵で復号化できるため、GitOpsワークフローと相性が良いです。

A) Kubernetes認定試験準備ガイド B) Kubernetesクラスターのセキュリティ設定ベストプラクティスとハード닝ガイドラインを提供 C) クラウドプロバイダー別のKubernetesコスト最適化 D) Kubernetesのパフォーマンスベンチマーク測定

答え: B

解説: CIS Kubernetes BenchmarkはCISが開発したKubernetesセキュリティ設定ガイドラインです。APIサーバー設定、etcdセキュリティ、kubelet設定、RBAC、ロギングなど数百のセキュリティ推奨事項を含みます。kube-benchツールを使用してクラスターがCIS基準を満たしているか自動評価できます。

A) Kubernetesクラスターのデプロイ自動化 B) Policy as Code - Admission Controllerを通じてKubernetesリソース作成/変更時にポリシーを強制 C) コンテナランタイムの脆弱性検出 D) サービスメッシュ設定管理

答え: B

解説: OPA（Open Policy Agent）GatekeeperはCNCF GraduatedプロジェクトでKubernetes Admission Webhookを通じてポリシーを強制します。Rego言語で記述されたポリシー（ConstraintTemplate + Constraint）で「特権コンテナの禁止」、「最新イメージのみ許可」、「特定ラベルの必須」などのルールを宣言的に定義して自動強制できます。

A) Kyvernoはより複雑なポリシーをサポートする B) KyvernoはYAMLでポリシーを記述し（Kubernetesネイティブ）、OPA GatekeeperはRego言語を使用する C) OPA GatekeeperはKubernetesにのみ特化している D) 2つのツールは完全に同じ機能を提供する

答え: B

解説: KyvernoはKubernetesネイティブのポリシーエンジンで、YAMLでポリシーを記述するためKubernetesユーザーに馴染みやすいです。Validate、Mutate、Generateの3種類のポリシータイプをサポートします。OPA Gatekeeperは汎用ポリシーエンジンのOPAをKubernetesに統合したもので、Rego言語を使用してより複雑な論理表現が可能ですが学習曲線があります。

A) コンテナイメージの署名と検証（Sigstore/Cosign） B) 信頼できるベースイメージのみを使用 C) CI/CDパイプラインでの脆弱性スキャン D) Podにより多くのリソースlimitsを設定

答え: D

解説: サプライチェーンセキュリティの方法: イメージの署名と検証（Cosign）、信頼できるソースのベースイメージ使用、CI/CDでのTrivy/Grypeによる脆弱性スキャン、SBOMの生成、プライベートコンテナレジストリの使用、Admission Controllerで署名済みイメージのみを許可。リソースlimitsの設定はパフォーマンス/可用性に関連する設定でサプライチェーンセキュリティと直接の関係はありません。

A) Ingressはクラスターに入るトラフィック、Egressはクラスターから出るトラフィック B) IngressはPodへの着信トラフィックを制御し、EgressはPodからの発信トラフィックを制御する C) IngressはHTTPトラフィックのみ、EgressはTCPトラフィックのみ制御する D) IngressとEgressは同じルールである

答え: B

解説: NetworkPolicyでingressルールは特定のPodへの着信トラフィックを許可するソース（Pod、Namespace、IPブロック）を指定します。egressルールは特定のPodからの発信トラフィックの宛先を指定します。両方のルールを組み合わせると双方向トラフィックを詳細に制御してマイクロセグメンテーションを実装できます。

A) リソースを削除する権限 B) リソースの変更をリアルタイムでストリーミングして購読する権限 C) リソースを変更する権限 D) リソースの一覧を取得する権限

答え: B

解説: Kubernetes RBACの主なVerb: get（単一リソースの取得）、list（リスト取得）、watch（変更のリアルタイムストリーミング）、create、update（全体修正）、patch（部分修正）、delete。watchはコントローラーがリソースの変更をリアルタイムに検知するために使用されます。最小権限の原則で不必要なwatch権限の付与に注意が必要です。

A) enforce、audit、warnの3つのモード - enforceは違反時にPod作成をブロック、auditとwarnはログ/警告のみ生成 B) allow、deny、monitorの3つのモード C) strict、normal、permissiveの3つのモード D) active、passive、silentの3つのモード

答え: A

解説: PSA（Pod Security Admission）は3つのモードをサポートします: enforce（ポリシー違反時にPod作成をブロック）、audit（監査ログに違反を記録、作成は許可）、warn（ユーザーへの警告を返す、作成は許可）。Namespaceラベルで設定します（例: pod-security.kubernetes.io/enforce: restricted）。

A) すべてのServiceをClusterIPタイプに設定する B) APIサーバーの--anonymous-auth=falseオプションを設定する C) NetworkPolicyですべての外部トラフィックをブロックする D) PodにPodDisruptionBudgetを設定する

答え: B

解説: kube-apiserverに--anonymous-auth=falseを設定すると、認証されていないリクエストがsystem:anonymousとして処理されるのを防ぎます。RBACでsystem:anonymousとsystem:unauthenticatedグループに付与された権限を削除することも合わせて行う必要があります。CIS Kubernetes Benchmarkもこの設定を推奨しています。

A) 最小限のベースイメージを使用する（Alpine、Distroless） B) イメージでrootユーザーを使用しない C) イメージにSSHサーバーを含める D) マルチステージビルドでビルドツールを除外する

答え: C

解説: コンテナイメージのセキュリティベストプラクティス: 最小ベースイメージの使用（攻撃面の最小化）、Non-rootユーザーでの実行、マルチステージビルドでビルドツールを除外、脆弱性スキャン、イメージ署名。コンテナイメージにSSHサーバーを含めることはセキュリティ上の悪い習慣です。デバッグが必要な場合はkubectl execやephemeral containerを使用すべきです。

A) SOC2はKubernetesのパフォーマンス基準を定義する B) SOC2はセキュリティ、可用性、処理の整合性、機密性、個人情報保護の原則に基づき、KubernetesクラスターのセキュリティがSOC2要件を満たすのに貢献する C) SOC2はKubernetes専用のセキュリティ標準である D) SOC2準拠のためにKubernetesを必ず使用する必要がある

答え: B

解説: SOC2は米国公認会計士協会（AICPA）が開発したサービスプロバイダーのセキュリティ基準です。Trust Service Criteria（TSC）の5つの原則に基づいています。Kubernetes環境でRBAC、監査ログ、ネットワークポリシー、暗号化などのセキュリティ制御を実装するとSOC2要件の充足に役立ちます。

A) コンテナのstdout/stderrログの収集 B) 誰が、いつ、何を、どのような結果でAPIサーバーにリクエストしたかを記録 C) ノードのシステムリソース使用量の記録 D) コンテナ間のネットワークトラフィックの記録

答え: B

解説: Kubernetes監査ログはkube-apiserverへのすべてのリクエストを記録します。ポリシーファイルで記録レベル（None、Metadata、Request、RequestResponse）を設定します。セキュリティインシデントの調査、異常なAPIアクティビティの検出、コンプライアンス証明に不可欠です。ログにはリクエスト者（user）、タイムスタンプ、対象リソース、HTTPメソッド、レスポンスコードが含まれます。

A) コンテナがrootで実行できない B) コンテナプロセスが親プロセスより多くの権限を取得できない（setuid/setgidの防止） C) コンテナがホストネットワークを使用できない D) コンテナが他のコンテナと通信できない

答え: B

解説: allowPrivilegeEscalation: falseはコンテナプロセスが自身の親プロセスより多くの権限を得ること（setuid/setgidバイナリの実行）を防ぎます。例えばsudo、passwdのようなsetuidバイナリを通じた権限昇格をブロックします。Restricted Pod Security Standardではこの設定が必須です。

A) 平文のHTTP通信 B) TLS証明書ベースの通信 - 各コンポーネント（kube-apiserver、kubeletなど）間のTLS暗号化 C) SSHトンネリングのみ使用 D) VPNなしでインターネット経由で通信

答え: B

解説: Kubernetesのコンポーネント間通信はTLSで暗号化されます: kube-apiserver ↔ etcd、kube-apiserver ↔ kubelet、コントロールプレーン ↔ ワーカーノード。各コンポーネントはクラスターCA（Certificate Authority）が署名した証明書を使用します。kubeadmでクラスターを構築するとこのPKIインフラが自動的に設定されます。

A) PCI-DSSはクラウド環境に適用されない B) カード決済データを処理するクラウドネイティブアプリケーションはPCI-DSS要件を満たす必要がある C) PCI-DSSはKubernetes専用の標準である D) PCI-DSSはインターネットトラフィックにのみ適用される

答え: B

解説: PCI-DSSはクレジットカードデータを処理、保存、送信するすべての組織に適用されるセキュリティ標準です。クラウドネイティブ環境でもカードデータを扱う場合はPCI-DSSを遵守する必要があります。Kubernetesのセキュリティ制御（暗号化、アクセス制御、監査ログ、ネットワークセグメンテーション）がPCI-DSS要件の充足に貢献します。

A) プライベートレジストリの使用 B) イメージ脆弱性スキャンの自動化 C) 公開インターネットのすべてのイメージを無検証で使用 D) イメージの署名と検証

答え: C

解説: Container Registryのセキュリティベストプラクティス: プライベートレジストリの使用（外部依存の最小化）、イメージ脆弱性の自動スキャン、イメージの署名と検証（Cosign）、レジストリのアクセス制御（RBAC）、古いイメージのクリーンアップポリシー。公開インターネットのイメージを検証なしで使用することはサプライチェーン攻撃や悪意のあるイメージ実行のリスクがあります。

A) Podのパフォーマンスが低下する B) ノードのファイルシステムに直接アクセスして、ホストシステムを操作したり機密ファイル（kubelet設定、シークレットなど）にアクセスできる C) HostPathは完全に安全なボリュームタイプである D) HostPathを使用するとPodを再起動できない

答え: B

解説: HostPathボリュームはコンテナからノードのファイルシステムパスを直接マウントします。悪意のある、または侵害されたコンテナはHostPathを通じてノードの/etc、/var/lib/kubelet、/procなどの機密パスにアクセスまたは変更してコンテナ脱出とホスト乗っ取りが可能になります。Pod Security StandardsのRestrictedプロファイルではHostPathボリュームが禁止されています。

A) Kubernetes Secretを外部データベースに同期する B) 外部シークレット管理システム（Vault、AWS Secrets Managerなど）のシークレットをKubernetes Secretに同期する C) Kubernetesクラスターを外部クラスターと接続する D) 外部ユーザーのKubernetes APIアクセスを管理する

答え: B

解説: External Secrets Operator（ESO）はAWS Secrets Manager、HashiCorp Vault、GCP Secret Manager、Azure Key VaultなどさまざまなL外部シークレット管理システムとKubernetesを統合します。ExternalSecretオブジェクトで外部シークレットを参照すると、ESOが自動的にKubernetes Secretに同期・更新します。

A) Flannel B) Cilium（eBPFベース、L7 NetworkPolicy、暗号化サポート） C) Bridge D) Host networking

答え: B

解説: CiliumはeBPF（extended Berkeley Packet Filter）ベースの高性能ネットワークプラグインで、標準NetworkPolicyだけでなくL7（HTTPパス、メソッド）レベルのポリシー、ノード間暗号化（WireGuard/IPSec）、ネットワークトラフィックの可視化（Hubble）を提供します。CalicoもNetworkPolicyと暗号化をサポートする強力なセキュリティCNIです。Flannelは基本的なL3ネットワーキングのみ提供します。

A) トークンの有効期限制限はパフォーマンス向上のためである B) トークンが盗まれても有効期間が短ければ攻撃者が使用できる時間が制限される C) Kubernetesではトークンの有効期限はサポートされていない D) トークンの有効期限はセキュリティとは関係ない

答え: B

解説: サービスアカウントトークンが盗まれると、攻撃者がそれを使用してAPIサーバーにアクセスできます。有効期限を短く設定すると盗まれたトークンの有用性を最小化します。Kubernetes 1.22以降ではProjected ServiceAccount Tokensを通じて有効期限付きのバウンドトークンを自動的に使用します。TokenRequest APIで短期トークンを発行することがベストプラクティスです。

A) 各NamespaceにLAR異なるCNIプラグインをインストールする B) NetworkPolicyを使用して他のNamespaceのPodからのトラフィックをブロックする C) Namespaceを削除すると自動的にブロックされる D) kube-apiserverの設定でNamespaceを隔離する

答え: B

解説: デフォルトでKubernetesはNamespace間のトラフィックを許可します。NetworkPolicyでnamespaceSelectorを使用して特定のNamespaceのトラフィックのみを許可したり、他のNamespaceからのすべてのトラフィックをブロックするポリシーを適用できます。podSelector: {}（すべてのPod）と空のingressルールでNamespaceレベルのDefault Denyを実装した後、必要なトラフィックを許可します。

A) Plan、Design、Build、Test、Deploy B) Identify、Protect、Detect、Respond、Recover C) Scan、Patch、Monitor、Alert、Fix D) Authenticate、Authorize、Encrypt、Log、Review

答え: B

解説: NIST CSFの5つの機能: Identify（資産とリスクの識別）、Protect（保護制御の実装）、Detect（セキュリティイベントの検出）、Respond（インシデント対応）、Recover（復旧）。Kubernetesのセキュリティでこのフレームワークはセキュリティ戦略を体系的に構築するのに活用されます。

A) 環境変数として注入されたSecretは自動的に暗号化される B) 環境変数はプロセスダンプ、ログ出力、kubectl describeなどを通じて露出するリスクがある C) 環境変数として注入するとSecretが自動削除される D) 環境変数注入はボリュームマウントより常に安全である

答え: B

解説: 環境変数として注入されたSecretのリスク: 1) kubectl describe podで露出、2) アプリケーションのエラーログに含まれる可能性、3) プロセスメモリダンプで露出。ボリュームマウント（ファイル）の方式がより安全です。tmpfsでマウントするとディスクに書き込まれません。またSecret変更時のボリュームマウントは自動更新されますが、環境変数はPodの再起動が必要です。

A) すべてのコンテナにroot権限を付与する B) コンテナに必要な最小限のLinux capabilitiesのみを付与し、不要な権限を削除する C) すべてのコンテナをprivilegedモードで実行する D) すべてのServiceAccountにClusterAdmin役割を付与する

答え: B

解説: コンテナの最小権限の原則: Linuxのcapabilitiesを使用して必要な権限のみを付与します。例えばウェブサーバーはNET_BIND_SERVICE（1024未満のポートバインディング）のみが必要です。securityContext.capabilities.drop: ["ALL"]ですべてのcapabilitiesを削除した後、必要なものだけを追加することがベストプラクティスです。Restricted PSSではデフォルトですべてのcapabilitiesのドロップが必要です。

A) イメージを絶対に更新しない B) 毎回レジストリから最新イメージをプルして、改ざんされたローカルキャッシュイメージの使用を防ぐ C) イメージのダウンロードを無効にする D) ノード間でイメージを共有する

答え: B

解説: ImagePullPolicy: AlwaysはPod起動のたびにレジストリからイメージをダウンロードします。セキュリティの観点からローカルにキャッシュされた改ざんされたイメージの使用を防ぎます。latestタグの代わりに特定のダイジェスト（SHA256）を使用するとイメージの整合性をより確実に保証できます。ただし、レジストリ障害時にはPodの起動が失敗する場合があります。

A) Pod間のネットワークトラフィックを制御する B) 自発的な中断（ノードドレイン、アップグレード）中も最小限のPodの可用性を保証して可用性を維持する C) Podのセキュリティポリシーを定義する D) リソース使用量を制限する

答え: B

解説: PodDisruptionBudget（PDB）は自発的な中断（voluntary disruption）中に同時に中断できるPodの最大数を制限します。minAvailable（最小可用Pod数）またはmaxUnavailable（最大利用不可Pod数）で設定します。ノードドレイン、クラスターアップグレード、Pod自動再起動時のサービス可用性を保証します。

A) etcd保存 → 認証 → 認可 → Admission Control B) 認証 → 認可 → Mutating Admission → Validating Admission → etcd保存 C) Admission Control → 認証 → 認可 → etcd保存 D) 認可 → 認証 → etcd保存 → Admission Control

答え: B

解説: APIリクエスト処理順序: 1) Authentication（認証 - 誰か？）、2) Authorization（認可 - 何ができるか？ RBAC）、3) Mutating Admission Webhooks（リクエスト修正）、4) Object Schema Validation（オブジェクトスキーマ検証）、5) Validating Admission Webhooks（リクエスト検証）、6) etcd保存。MutatingがValidatingより先に実行されるのは修正後の最終状態を検証するためです。

A) kubectlで自動的に発行される B) CertificateSigningRequest（CSR）APIを通じてクラスターCAで署名した証明書を発行する C) 外部の認証機関からのみ発行できる D) ServiceAccountトークンで代替すれば証明書は不要

答え: B

解説: KubernetesはCertificateSigningRequest（CSR）オブジェクトを通じたユーザーX.509証明書発行をサポートします。ユーザーが秘密鍵とCSRを生成し、クラスター管理者がkubectl certificate approveで承認すると、クラスターCAが署名した証明書が発行されます。この証明書をkubeconfigに追加して使用します。

A) コンテナのCPU使用量を制限する B) コンテナプロセスが使用できるLinuxシステムコールを制限して攻撃面を縮小する C) コンテナ間のネットワーク暗号化 D) コンテナイメージの署名検証

答え: B

解説: seccomp（Secure Computing Mode）はプロセスが使用できるLinuxシステムコールをホワイトリスト/ブラックリストで制御します。コンテナにseccompProfile: RuntimeDefaultを設定すると、ほとんどの安全なシステムコールのみを許可し、危険な呼び出しをブロックします。Restricted PSSではseccompプロファイルの設定が要求されます。AppArmorと共にコンテナランタイムセキュリティの核心です。

A) NetworkPolicyオブジェクトを作成すると自動的に適用される B) NetworkPolicyを実際に強制するCNIプラグイン（Calico、Ciliumなど）がインストールされている必要がある C) kube-proxyがNetworkPolicyを自動的に処理する D) Ingress Controllerのインストールが必要

答え: B

解説: KubernetesのNetworkPolicyオブジェクトはAPIリソースとしてポリシーを定義します。しかし実際のネットワークルールを強制するのはCNI（Container Network Interface）プラグインです。NetworkPolicyをサポートするCNI: Calico、Cilium、Antrea、WeaveNet。サポートしないCNI: Flannel（デフォルト）。サポートするCNIなしではNetworkPolicyオブジェクトがあっても何の効果もありません。

A) コンテナをUID 0（root）で実行し、コンテナ脱出のリスクが高まる B) コンテナを最小権限ユーザーで実行する C) コンテナが実行されないようブロックする D) セキュリティに影響がない

答え: A

解説: runAsUser: 0はUID 0、つまりrootユーザーとしてコンテナを実行します。rootで実行されたコンテナはコンテナ脱出の脆弱性が発生した場合、ホストノードでもroot権限を得るリスクが高くなります。必ずrunAsNonRoot: trueとrunAsUser: 1000以上のUIDを使用すべきです。Restricted PSSではrootでの実行が禁止されています。

A) None B) Metadata C) Request D) RequestResponse

答え: D

解説: Kubernetes監査ログのレベル: None（記録なし）、Metadata（リクエスト者、タイムスタンプ、リソース、動詞のみ記録）、Request（メタデータ+リクエスト本文）、RequestResponse（メタデータ+リクエスト本文+レスポンス本文）。RequestResponseが最も詳細ですが、ログサイズが大幅に増加します。Secret関連のAPIは最低限Metadataレベルで記録することが推奨されます。

A) Podのネットワークパフォーマンスが低下する B) PodがノードのネットワークインターフェースにLART直接アクセスして、ノードのすべてのネットワークトラフィックを盗聴または変更できる C) ネットワークポリシーが自動的に強化される D) セキュリティリスクがない

答え: B

解説: hostNetwork: trueはPodをノードのネットワーク名前空間で実行します。Podがノードのすべてのネットワークインターフェースに直接アクセスできるため、ノードネットワークトラフィックの盗聴、ポートの競合、ネットワーク設定の変更が可能になります。システムレベルのPod（CNIなど）でのみ使用すべきです。Restricted PSSでは禁止されています。

A) すべてのユーザーにsecrets: ["*"]権限を付与する B) アプリケーションが必要とする特定のSecretの名前を明示してget権限のみを付与する C) すべてのNamespaceでSecretをlistできるClusterRoleを付与する D) ServiceAccountにcluster-admin権限を付与する

答え: B

解説: SecretのRBAC最小権限の原則: resourceNamesで特定のSecret名を指定して、そのSecretのみをgetまたはwatchできるように設定します。listとwatch権限はすべてのSecretを参照できるため危険です。Namespaceレベルのロールを使用してクラスター全体のアクセスを制限します。

A) ビルド速度を上げるため B) 脆弱なイメージが本番環境にデプロイされる前に早期に検出してブロックする C) コンテナイメージのサイズを削減するため D) Kubernetesクラスターの設定を自動化するため

答え: B

解説: CI/CDパイプラインでのイメージ脆弱性スキャン（Trivy、Grype、Snykなど）の統合は「Shift Left Security」を実現します。開発の初期段階で脆弱性を発見すると修正コストが低く、本番環境での侵害リスクを大幅に削減できます。CVSSスコアの閾値を設定してHigh/Criticalな脆弱性があるイメージのビルドを自動的にブロックできます。

A) 新バージョンはパフォーマンスのみを向上させる B) 新バージョンには既知のCVEセキュリティ脆弱性のパッチが含まれている C) アップグレードはセキュリティとは関係ない D) アップグレードは常にセキュリティを弱める

答え: B

解説: Kubernetesは定期的にセキュリティパッチを含む新バージョンをリリースします。古いバージョンのKubernetesクラスターは既知のCVE脆弱性にさらされる可能性があります。Kubernetesのサポートポリシーは最新の3つのマイナーバージョンのみメンテナンスパッチを提供します。サポートされているバージョンにクラスターを維持することがセキュリティの基本です。

A) kubeconfigファイルをGitリポジトリにコミットする B) ファイル権限の制限（chmod 600）、暗号化されたストレージの使用、最小権限kubeconfigの使用 C) すべてのチームメンバーが同じ管理者kubeconfigを共有する D) kubeconfigファイルにセキュリティリスクはない

答え: B

解説: kubeconfigはクラスターアクセス認証情報を含み、特にcluster-admin権限のkubeconfigは非常に機密です。セキュリティのベストプラクティス: chmod 600 ~/.kube/config（所有者のみ読み書き）、Gitへのコミット厳禁（.gitignoreに追加）、各チームメンバーへの最小権限kubeconfigの発行、認証情報の有効期限の定期的な確認。チーム共有アカウントより個人サービスアカウントの使用を推奨します。