KCSA 模拟考 A

云原生安全的4C模型中，从内到外的正确顺序是什么？

• 代码 → 容器 → 集群 → 云
• 容器→代码→云→集群
• 云→集群→容器→代码
• 集群→云→代码→容器

在共享责任模型中，以下哪项是托管 Kubernetes 用户仍然负责的领域？

• 控制平面节点上的操作系统补丁
• etcd 实例的物理安全
• 工作负载的 RBAC 设置和 Pod 安全级别
• 修复 apiserver 二进制文件中的漏洞

将最小权限原则应用于 Kubernetes 的最佳示例是什么？

• 为所有 pod 提供 cluster-admin，但跟踪审核日志
• 为每个工作负载创建专用的 ServiceAccount，并仅允许必要的动词和资源。
• 拥有一个命名空间并管理其中的所有工作负载
• 给予足够的权力，出现问题时减少权力。

Kubernetes 中深度防御的最佳示例是什么？

• 选择最强大的控制并将您的投资集中在它上面。
• 覆盖图像扫描、准入策略、Pod 安全标准、网络策略和运行时检测
• 如果阻止从外部访问集群，则省略其他控制。
• 发现漏洞后建立响应程序

在 Kubernetes 中，有什么很难被视为增加攻击面的设置？

• 按原样将 apiserver 暴露到 Internet
• 打开匿名访问（--anonymous-auth=true）
• 在节点上保持 SSH 打开并共享密钥
• 每个工作负载都有一个单独的命名空间

SBOM 在供应链安全中最准确的作用是什么？

• 通过签署构建管道来防止伪造
• 保留工件中包含的组件和版本的列表，以便您在披露新漏洞时可以立即找到影响范围。
• 监控正在运行的容器的系统调用以检测异常行为
• 加密图像以防止从注册表中读取其内容

在集群内应用零信任的最合适方法是什么？

• 进入集群的流量被认为已经经过验证，并且内部通信保持开放。
• 每个请求都是根据身份和策略而不是位置来判断的，并且内部通信也经过身份验证和授权。
• 阻止所有外部访问，仅允许内部用户使用集群。
• 通过严格组织防火墙规则来加强边界

当响应集群安全事件并发现受感染的节点时，最合适的顺序是什么？

• 立即删除该节点以清理痕迹并附加新节点。
• 封锁节点，保留证据，然后移动工作负载并检索凭证。
• 重新启动节点以恢复正常状态并排查原因。
• 先重新安装整个集群，稍后再看日志

如果 apiserver 的 --authorization-mode 中包含 AlwaysAllow，会发生什么？

• 无论 RBAC 规则如何，所有成功进行身份验证的请求都会被允许。
• 仅允许未经身份验证的请求；经过身份验证的请求遵循 RBAC。
• 仅在没有 RBAC 规则时才允许，如果有规则则遵循
• 仅允许审核日志中记录的主题

kubelet 的--anonymous-auth=true危险的最准确原因是什么？

• 由于 kubelet 匿名连接 apiserver，节点注册失败。
• 打开无需凭据即可访问节点的 kubelet API 的路径。
• Pod 的 ServiceAccount 令牌未颁发
• 容器运行时不会验证镜像签名

哪种保护 etcd 的措施效果最差？

• 为客户端和对等通信强制执行双向 TLS
• 仅在控制平面节点之间打开 etcd 端口并阻止其他端口
• 保存时打开加密，以便 Secret 不会保留为纯文本。
• 更改 etcd 数据目录的文件名以降低其可读性。

关于 Kubernetes 中的静态加密，以下哪项是正确的？

• apiserver 在写入 etcd 之前进行加密，并在读取时进行解密。
• etcd 自身加密，不涉及 apiserver。
• 在 kubelet 挂载 pod 之前立即解密。
• 客户端 kubectl 在传输之前对其进行加密。

使用 KMS 提供程序进行静态加密比aescbc等本地密钥方法更好吗？

• 加密算法更快，减少apiserver延迟。
• 由于数据加密密钥由外部 KMS 包装，因此该密钥不会以纯文本形式保留在配置文件中。
• 自动解密etcd备份文件。
• Secret 以外的资源会自动包含在加密目标中。

Kubernetes 不提供什么作为 apiserver 身份验证方法？

• 客户证书
• OIDC 代币
• 服务帐户令牌
• 特定于资源的访问控制列表 (ACL) 文件

为什么绑定的 ServiceAccount 令牌（投影令牌）比传统的基于 Secret 的令牌更安全？

• 很难猜测，因为令牌是一个较长的字符串。
• 它有有效期，并且与特定的 Pod 和受众绑定，因此一旦发生泄漏，使用范围和期限都很窄。
• 由于令牌未存储在 etcd 中，因此 apiserver 也无法验证它。
• 令牌仅在 pod 内创建，因此 apiserver 不参与发行。

为什么建议kube-scheduler和kube-controller-manager中的--bind-address环回？

• 其他节点需要访问该组件，但为了节省带宽，
• 防止指标和调试端点暴露为可在节点外部访问。
• 减少组件连接到 apiserver 时的延迟
• 尝试为每个节点独立执行领导者选举

为什么我们告诉您关闭控制平面组件中的--profiling=true操作？

• 这是因为打开分析后不会留下审核日志。
• 因为分析端点可以揭示内部状态并导致开销。
• 因为分析的目的是绕过身份验证
• 这是因为打开分析会重置 RBAC 规则。

kubelet中--read-only-port和--authorization-mode=Webhook之间的正确关系是什么？

• 只读端口不经过授权 Webhook，因此即使您打开 Webhook，也必须单独关闭该端口。
• 当您打开授权 Webhook 时，甚至只读端口也会自动受到保护。
• 如果关闭只读端口，授权 Webhook 将不起作用。
• 这两个设置是互斥的，不能一起使用。

准入控制器与身份验证/授权最准确的区别是什么？

• 通过仔细检查请求者是谁来双重验证身份
• 通过查看请求的内容并修改或拒绝它来强制对象必须遵守的条件。
• 该请求存储在 etcd 中，随后进行检查以报告违规行为。
• 它只负责通过限制请求速率来防止过载。

ValidatingAdmissionWebhook 中的failurePolicy: Ignore会带来哪些风险？

• 如果 webhook 没有响应，则请求会在不进行检查的情况下通过，并且策略会被悄悄清除。
• 如果 Webhook 没有响应，则对集群的所有写入都会停止。
• 被 webhook 拒绝的请求也会被强制通过。
• Webhooks 现在可以改变对象，存储意外的值

为什么静态 Pod 清单目录的写入权限在控制平面节点上很重要？

• 如果您可以在该目录中写入文件，则无需通过 apiserver 即可运行所需的 pod。
• 如果该目录损坏，etcd 数据也会随之丢失。
• 该目录的权限决定了 Pod 的默认 securityContext。
• 集群的审计策略是通过该目录分发的。

在 Pod 规范中使用automountServiceAccountToken: false最合适的理由是什么？

• 令牌不会放置在不调用 API 的工作负载中，从而无需在被劫持的情况下使用。
• 提高 Pod 连接到 API 服务器的速度
• 完全无需创建 ServiceAccount
• 允许 Pod 从其他命名空间读取 Secret

未创建 NetworkPolicy 的命名空间的默认通信状态是什么？

• 仅允许在同一命名空间内进行通信
• 所有 pod 都可以自由地与所有 pod 通信
• 所有通信均被阻止，必须通过策略打开
• 入口开放，仅出口被封锁

NetworkPolicy 无法阻止什么？

• 来自具有特定标签的 Pod 的入口
• 指定 CIDR 之外的出站
• 已接受连接内 HTTP 请求正文的内容。
• 特定端口和协议上的传入连接

如果仅设置securityContext.runAsNonRoot: true并且创建映像以 root 身份运行会怎样？

• kubelet 会自动将用户更改为以非特权用户身份运行。
• 容器拒绝启动且 Pod 不运行
• 仅留下警告，并以 root 身份运行。
• 映像将被重建并运行，仅更改用户。

allowPrivilegeEscalation: false实际上可以防止什么？

• 容器使用主机的网络命名空间
• 子进程通过 setuid 二进制文件等获得比父进程更多的特权。
• Pod 从其他命名空间读取对象
• 容器写入卷

处理 Linux 功能的推荐方法是什么？

• 删除所有内容并仅添加您需要的内容
• 保留默认值不变，如果出现问题则将其删除。
• 通过提前添加NET_ADMIN和SYS_ADMIN来排除异常。
• 开启特权，这样您就不必担心功能

设置hostPID: true的 Pod 将具有哪些功能？

• 您可以查看节点上的所有进程，并向它们发送信号（如果它们可访问）。
• 可以读写节点的整个文件系统
• 节点的网络接口可以按原样使用。
• 可以加载节点内核模块

建议将 Secret 安装为卷而不是环境变量的最合适理由是什么？

• 这是因为环境变量由子进程继承，并且很容易作为故障转储或进程信息公开。
• 这是因为作为环境变量注入的值未加密，但卷已加密。
• 这是因为环境变量有长度限制，不能包含证书。
• 这是因为当作为环境变量注入时，apiserver 以纯文本形式存储 Secret。

Kubernetes Secret的base64编码的正确理解是什么？

• 它是一种对称密钥加密，因此没有密钥就无法读取。
• 因为它是一种简单的编码，任何人都可以反转它，并且它不提供机密性。
• 因为是哈希函数，所以无法恢复原来的。
• 它是一种保护传输部分的签名方法。

在RBAC中允许所有get、list、watch时需要特别注意什么？

• list 和 watch 返回整个对象，因此即使您不知道名称也可以读取整个内容。
• 如果只有get的话，即使知道名字也看不到内容。
• watch 被归类为写作动词，而不是阅读动词
• 当受资源名称限制时，所有三个动词的行为相同

哪个级别的审计日志同时记录请求体和响应体？

• 元数据
• 要求
• 请求响应
• 没有任何

从安全角度来看，为什么要使用ResourceQuota和LimitRange？

• 防止一个命名空间独占集群资源并导致其他工作负载匮乏
• 防止 Pod 从其他命名空间读取对象
• 检查容器镜像是否存在漏洞
• 限制 Pod 之间的网络通信

仅将审核日志保留为 apiserver 节点上的本地文件有哪些缺点？

• 控制该节点的攻击者可以删除他的踪迹。
• 由于审核日志填满 etcd，集群停止
• 由于审计日志是明文的，因此在传输过程中会被截获。
• 审计日志的时区因节点而异。

控制 Kubernetes 应对 STRIDE 的欺骗威胁最合适的方式是什么？

• 使用 ResourceQuota 限制命名空间的使用
• 将请求记录在审核日志中
• 使用 readOnlyRootFilesystem 防止文件修改
• 通过双向 TLS 和强身份验证验证请求者的身份

哪种设置最有可能导致容器逃逸？

• 如果您没有为 pod 指定资源限制
• 当 Pod 作为 ClusterIP 服务公开时
• 如果 Pod 以特权运行并安装了主机路径：
• 当一个 pod 只有一个副本时

当攻击者在 Pod 内成功执行代码时，他们首先要瞄准的目标是什么？

• 在环境变量中安装了 ServiceAccount 令牌和凭据
• 容器镜像层结构及构建视觉信息
• 系统信息，例如节点的内核版本和发行版名称。
• 来自附加到 Pod 的标签和注释的元数据

为什么要阻止 Pod 访问云元数据服务？

• 这是因为元数据服务将 pod 的日志传输到外部。
• 这是因为元数据服务劫持了 Pod 的 DNS 解析。
• 这是因为元数据服务访问会消耗大量节点的CPU。
• 这是因为您可以从元数据服务接收附加到节点的云角色的凭据，并访问集群外部的资源。

哪条权限提升路径对应于“通过节点访问进行提升”？

• 使用 RBAC 的绑定动词将更强的 ClusterRole 连接到您自己。
• 注册一个准入 webhook 来改造新创建的 Pod
• 注册 CRD 以添加新的资源类型
• 从 kubelet 目录中读取节点上调度的其他 Pod 的 Secret Volume。

什么最准确地描述了供应链攻击中的“依赖性混乱”？

• 构建服务器被感染，并且恶意代码被插入到输出中。
• 替换图像标签以分发不同的图像
• 将与仅内部包同名的包放在公共存储库上并从中提取构建
• 窃取注册表凭据以秘密下载图像

为什么寻求确保集群持久性的攻击者会瞄准准入 Webhook？

• 这是因为 webhooks 不会留下审核日志，因此痕迹会消失。
• 因为webhooks可以直接访问etcd。
• 这是因为 webhook 可以更改节点的内核参数。
• 这是因为webhooks可以修改所有新创建的对象，因此即使删除了它们也可以重新种植。

即使在镜像上附加了漏洞扫描，哪些风险也很容易被忽略？

• 应用程序依赖项中的已知 CVE
• 图像中提交的秘密值，例如凭证。
• 图像中包含易受攻击的解释器版本

使用临时容器进行调试时有哪些安全注意事项？

• 由于目标 pod 的命名空间是共享的，因此您可以访问 pod 的进程和文件。
• 当目标 Pod 重新启动时，服务会短暂中断。
• 目标 Pod 的镜像被替换，使得原始版本未知。
• 使用历史记录无法跟踪，因为它没有记录在审核日志中。

运行时检测工具与构建时检查相比可以捕获哪些不同的内容？

• 镜像中存在漏洞的包版本
• 清单中的 securityContext 设置无效
• 在执行期间，容器启动 shell 或访问意外文件。
• Dockerfile 中留下的硬编码令牌

Pod 安全准入的三种模式中，warn是做什么的？

• 拒绝有问题的 Pod 并在响应中包含原因
• 违规行为仅作为注释记录在审核日志中。
• 将向请求者返回有关违规的警告消息，但允许创建。
• 违规 Pod 将被创建并在一段时间后被删除。

Pod 安全标准中的三个配置文件中哪一个是baseline的正确位置？

• 这是最宽松的配置文件，没有任何限制。
• 它是最严格的，要求非特权执行和能力删除。
• 这是一个中间配置文件，旨在阻止已知的权限升级，但允许最常见的工作负载通过。
• 它是必须为每个 Pod 单独指定的配置文件，而不是命名空间。

将 PSA 应用为命名空间标签时，以下哪项是限制？

• 当您创建新的命名空间时，标签会自动消失。
• 即使您添加了标签，kubelet 也可能会忽略它。
• 命名空间中只能指定一种模式。
• 无法检查 Pod 安全标准之外的条件，例如图像源或注册表

在准入阶段强制进行图像签名验证有什么好处？

• 图像中的漏洞被自动删除
• 减小映像大小可加快部署速度
• 非可信管道创建的镜像不会进入集群
• 即使图像在执行过程中被篡改，也会立即被检测到。

即使连接到外部秘密管理系统（Vault等），仍然存在哪些风险？

• 外部系统不加密存储该值
• Kubernetes不支持外部系统，因此无法集成。
• 如果您使用外部系统，则无法进行秘密轮换。
• 如果有权检索该值的工作负载受到损害，则最终会获得明文秘密。

加强节点本身最合适的措施是什么？

• 通过为节点上的开发人员创建 SSH 帐户来为调查做好准备。
• 保持特权容器始终在节点上运行，以便可以立即修复问题。
• 删除不必要的包和服务，并缩小 kubelet 配置文件的权限。
• 关闭节点的防火墙以便于诊断。

为什么要使用 gVisor 或 Kata Containers 等沙箱运行时？

• 减小容器镜像的大小
• 加快容器启动时间
• 将多个节点上的容器作为一个整体进行管理
• 通过在主机内核和工作负载之间添加附加层来减少内核漏洞的影响。

RuntimeClass的正确作用是什么？

• 确定 Pod 可以使用的最大 CPU 和内存
• 确定Pod可以访问的网络带宽
• 选择 pod 将使用哪些容器运行时设置来运行
• 确定从哪个注册表接收 pod 映像

在多租户集群中加强租户之间隔离的最合适组合是什么？

• 仅划分命名空间，其余部分保留默认值。
• 将所有租户放在一个命名空间中，仅通过标签区分
• 仅向每个租户分发单独的 kubeconfig 文件。
• 命名空间、RBAC、NetworkPolicy、配额，甚至节点分离（如果需要）一起使用。

为什么我们需要在 PSA 之上使用像 OPA Gatekeeper 或 Kyverno 这样的策略引擎？

• 这是因为 PSA 在入院阶段不运作。
• 这是因为 PSA 不是针对每个命名空间应用的。
• 这是因为 PSA 无法处理 Pod 和特定于组织的规则之外的资源。
• 这是因为 PSA 无法拒绝违规行为，只能发出警告。

什么最准确地描述了 CIS Kubernetes 基准？

• 它是一个将攻击者的行为分为战术和技术的知识库。
• 这是统计 Kubernetes 漏洞数量的官方数据库。
• 这些是云提供商必须遵守的法律法规。
• 用于检查集群组件配置的逐项建议和验证程序的集合。

NSA/CISA Kubernetes 强化指南所强调的很难看到的轴是什么？

• 增强 Pod 安全性和网络隔离
• 身份验证、授权和审计日志记录
• 持续更新和漏洞检查
• 通过引入单一供应商产品实现标准化

在实践中使用 MITRE ATT&CK for Container 最合适的方式是什么？

• 将其用作检查表来检查每个项目，以查看集群设置是否满足条件。
• 用作计算漏洞严重性评分的公式
• 根据已知攻击技术列表绘制我们的检测和控制能力范围。
• 用作确定审计日志保留期限的规定

合规性自动化工具在集群上最合适的做法是什么？

• 自动修复发现的违规行为，使集群立即恢复标准
• 直接向监管机构提交报告
• 如果发现违规，则删除相应的工作负载。
• 根据既定标准定期检查当前设置并留下通过/失败的证据

设计审计政策时常见的错误有哪些？

• 记录读取请求并排除写入请求
• 为每个命名空间指定不同的级别
• 通过对所有资源应用最详细的级别，存储成本会激增，甚至敏感值会泄漏到日志中。
• 在日志中包含身份验证失败请求

尽管有报告称已通过安全标准，但最令人信服的原因是什么？

• 这是因为安全标准包含矛盾的项目。
• 如果您通过了标准，则无需留下任何日志。
• 通过标准的集群被排除在监视之外。
• 这是因为标准仅保证检查时的设置，并不涵盖标准之外的后续变更和风险。