测验：Secret 的保存

Kubernetes Secret 的值为什么使用 base64？

• 编码后值变短，可节省 etcd 容量
• 固定长度字符串使 RBAC 判定更快
• 在保存到 etcd 前加密数值
• 让任意二进制数据能安全放入文本字段

在 EncryptionConfiguration 的 providers 列表中把 identity 放在第一位，会怎样？

• 优先级最高，因此使用最强加密
• identity 只能放在最后，配置会被拒绝
• 写入时使用 identity，恢复为明文存储
• 写入仍加密，只有读取时按明文处理

启用静态加密后，旧 Secret 在底层存储中仍是明文。原因是什么？

• 值被 base64 包裹，所以密文看起来像明文
• 配置文件没有被 apiserver 读取，加密实际上未启用
• 必须重启 etcd 才能读取该配置
• 加密发生在写入时，旧对象必须重新写入一次

哪项正确描述 KMS 信封加密？

• etcd 在写入磁盘前使用自身密钥加密
• kubelet 在节点挂载前解密数据
• 直接用 KMS 主密钥加密每个对象
• 数据由数据密钥加密，数据密钥再由主密钥加密

Role 同时配置 resourceNames: ["db-password"] 和 verbs: ["get", "list"]。结果是什么？

• 同时使用 resourceNames 和 list 会使 Role 被拒绝
• 名称限制会使 list 请求始终返回 403
• get 和 list 都被限制为仅访问 db-password
• 只有 get 被限制；list 会返回该命名空间的全部 Secret

如何修改设为 immutable: true 的 Secret 值？

• 用 patch 强制修改
• 先将 immutable 改回 false，再修改
• 创建新名称的 Secret，并迁移引用
• 重新创建命名空间

采用 External Secrets 后，哪些问题消失，哪些仍然存在？

• 值只在集群外的保管库中，因此 etcd 不再存储 Secret
• 清单和集群中都没有值，所以不再需要 RBAC 或静态加密
• 清单中不再保存值，但操作器创建的集群 Secret 仍需 RBAC 和静态加密保护
• 操作器持有保管库权限，所以无需设计集群 RBAC

发现凭据已被提交到 Git，首先应做什么？

• 将仓库改为私有，以缩小暴露范围
• 先确定提交者和时间，调查影响范围
• 立即撤销该凭据并更换新值
• 用 git filter-repo 从历史中删除该值