kubernetes 启用删除API对象的功能,即使存储级别的解密工作不正常,

ijnw1ujt  于 4个月前  发布在  Kubernetes
关注(0)|答案(9)|浏览(68)

发生了什么:

用户无法删除密钥管理服务(KMS)提供者(最初加密这些密钥的提供者)无法解密它们时,无法删除密钥。KMS提供者可能无法解密密钥的原因有很多,最常见的原因是用户删除/禁用了用于最初加密密钥的密钥版本。

您期望发生的情况:

删除密钥。

如何尽可能精确地重现它:

  1. 使用您选择的KMS提供者设置一个集群。
  2. 创建一个密钥,验证该密钥已加密。
  3. 重启集群(这是清除Key Encryption Keys缓存所必需的)。
  4. 禁用第2步中由提供者用于加密密钥的密钥或密钥版本。
  5. 尝试删除密钥。您应该会收到一个 Package 了kms-plugin特定错误的内部错误(错误将根据插件而有所不同)。
    注意:这个问题可能不仅仅局限于KMS提供者,但当用于加密密钥的密钥不再可用时,任何提供者都会表现出来。

我们需要了解其他信息吗?:

我认为这种行为的原因是在删除之前需要更新对象的元数据,这意味着需要从存储中进行转换。然而,由于KEK不可用,这样的转换是不可能的。
为了解决这个问题,即使KEK不可用,我们也需要在处理删除操作时读取对象的元数据——毕竟,在删除过程中,我们不关心有效负载。
因此,要启用这种情况,我们需要远离对整个对象进行加密。具体来说,部分元数据应保持明文。
我意识到这会引起很多问题,我可以跟进这个议题并提交一个KEP。

环境:

  • Kubernetes版本(使用 kubectl version ):

1.14

slsn1g29

slsn1g291#

预计无法从存储中读取(包括对存储的任何必需解密)将阻止对对象(包括读、写和删除请求)的访问。
删除路径需要检查诸如终结器之类的事物,而终结控制器可以通过API执行任意操作(读取和更新对象)。
为部分对象加密添加支持将是一项增强功能,而非真正的bug修复,并且肯定需要提出建议。

u5i3ibmn

u5i3ibmn2#

我将为此制定一个KEP。

oaxa6hgo

oaxa6hgo3#

问题在90天不活跃后过期。
使用 /remove-lifecycle stale 将问题标记为新鲜。
过期的问题在30天不活跃后开始腐烂并最终关闭。
如果现在可以安全地关闭此问题,请使用 /close 进行操作。
向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
生命周期:过期

uttx8gqw

uttx8gqw4#

过期的问题在30天不活动后会变质。
使用 /remove-lifecycle rotten 将问题标记为新鲜。
腐烂的问题在额外的30天不活动后关闭。
如果现在可以安全地关闭此问题,请使用 /close 进行操作。
将反馈发送给sig-testing, kubernetes/test-infra 和/或 fejta
生命周期腐烂

km0tfn4u

km0tfn4u5#

以下是文本内容的翻译结果:

腐烂的问题在30天不活动后关闭。
使用 /reopen 重新打开问题。
使用 /remove-lifecycle rotten 将问题标记为新鲜。
向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
/close

w6lpcovy

w6lpcovy6#

关闭此问题。
对此的回应:
腐烂的问题在30天内无活动后关闭。
使用 /reopen 重新打开问题。
使用 /remove-lifecycle rotten 将问题标记为新鲜。
向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
/close
使用 PR 评论与我互动的说明已提供 here 。如果您对我的行为有任何疑问或建议,请针对 kubernetes/test-infra 存储库提出问题。

sc4hvdpw

sc4hvdpw7#

@enj:重新打开这个问题。
对此的回应:
/reopen
使用PR评论与我互动的说明已提供。如果您对我的行为有任何问题或建议,请针对kubernetes/test-infra仓库提出一个问题。

z31licg0

z31licg08#

/triage accepted
/assign @stlaz@ibihim
这是在最近一次SIG auth会议中讨论的一个高层次的问题。大致的想法是提出一个KEP(Standa和Krzysztof已经自愿报名了😛),该KEP将添加两个功能:

  1. 让API服务器以结构化的方式返回哪个资源无法解密/解码,作为返回的API状态错误的一部分
  2. 在删除选项中创建一个新字段,允许表达“我想删除这个,如果有解密/解码错误”的意思(也许可以支持某种形式的试运行?)
    这将使外部工具(kubectl插件?)得以创建(也可以是一个SIG Auth子项目),允许具有足够访问Kubernetes API(可能是集群管理员)的最终用户恢复一个无法解密/解码某些子集的项目(尽管也许该工具可以通过请求来自watch缓存的数据来尝试部分恢复?)。一个重要的方面是,“坏状态是否永久/终止”的决定将由最终用户来做(而不是API服务器代表用户做出决定)。
    目前,需要直接访问etcd才能删除这种状态的项目。
jecbmhm3

jecbmhm39#

这个问题已经超过一年没有更新了,应该重新进行优先级评估。
你可以:

  • 确认这个问题仍然与 /triage accepted (仅组织成员)相关
  • /close 关闭这个问题

有关优先级评估过程的更多详细信息,请参见 https://www.kubernetes.dev/docs/guide/issue-triage/
已接受移除优先级评估

相关问题