Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

autoTls: bound certificate lifetime by the CA that will actually sign it, not the configured caCertificateLifetime

未关闭
  • 哪里不对？
#753 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
kubernetes, rust
领域
infrastructure, security

调研方向

从 TlsGenerate::get_or_create_k8s_certificate 开始；NodePublishVolume 构建后端时会调用它，然后检查 ca::Manager::load_or_create，以加载 Secret 的 CA 证书。使用 CA 中最晚的过期时间实现有效期上限，同时保留现有的硬失败行为：当没有 CA 能覆盖当前时间加上重启缓冲时间时失败。检查现有的警告或条件行为，并通过相关测试验证证书有效期和失败边界情况。

由索引模型根据 Issue 内容生成。

描述

get_or_create_k8s_certificate clamps maxCertificateLifetime to (caCertificateLifetime - caCertificateRetirementDuration) / 4.
That is good in general, bad when someone brings their own CA as secret operator never looks at the actual CA that is provided. It just looks at what is in the CR:

    ca:
        secret:
          name: secret-provisioner-tls-ca
          namespace: default
        autoGenerate: false
        caCertificateLifetime: 700d
        caCertificateRetirementDuration: 1d

maxCertificateLifetime = (700 - 1) / 4 = 174 (or 175, not sure, doesn't matter here)

That clamps to 174d . But we have no idea what's really in the CA.

If it has 200 days left:

  • above 174 days remaining: works
  • 174 down to 139: flip-flops, because jitter puts each cert somewhere in 139-174d and only some of them still fit
  • below 139: every mount fails

That is not great.
It only happens when autoGenerate is false, but still....

Scope

  • Calculate the clamp by looking at the CA in the Secret that expires last
  • Keep it a hard failure where no CA covers now + restartBuffer
  • Warning Event and/or condition on the Pod when the cert had to be shortened because of the CA's remaining lifetime?
    • Open question....do we do this elsewhere? Easy to do? I think it'd be good.

[!NOTE]
This next bit is complicated and I'm not 100% sure it is all correct. I think it makes sense but I have a nagging feeling that something is still off. It is 100% written by hand but I'm not sure if the new steps 3 & 4 are correct to be honest. So many edge cases.

When a pod mounts a TLS volume, NodePublishVolume builds the backend for that SecretClass.
For autoTls that is TlsGenerate::get_or_create_k8s_certificate, which does, in this order:

  1. safe_max_cert_lifetime = (caCertificateLifetime - caCertificateRetirementDuration) / 4, from the CR fields
  2. max_cert_lifetime = min(maxCertificateLifetime, safe_max_cert_lifetime). This is the clamp.
  3. ca::Manager::load_or_create, which reads the CA certificates from the Secret

We need to load the CAs (step 3) before computing the clamp (step 2), and additionally bound it (the max cert lifetime) by the remaining lifetime (not_after - now, minus caCertificateRetirementDuration) of the CA that expires last. This way we never create certificates that can outlive the last expiring CA.

  1. ca::Manager::load_or_create, reads the CA certificates from the Secret
  2. safe_max_cert_lifetime = (caCertificateLifetime - caCertificateRetirementDuration) / 4, from the CR, unchanged
  3. ca_bound = not_after(CA that expires last) - now - caCertificateRetirementDuration, from the loaded certificates. This is new.
  4. max_cert_lifetime = min(maxCertificateLifetime, safe_max_cert_lifetime, ca_bound)

[!NOTE]
Do we even still need safe_max_cert_lifetime? I believe it makes sure that all Pods can still talk to each other even if some already have a new CA and others don't but 🤯

Open questions

  • Check the existing warnings whether they are correctly calculated and/or whether we want something new
  • Event or Pod condition or both? An Event per mount is noisy on a large StatefulSet, otoh we might want noisy in this case?
  • I believe it'd be easy to fold #94 into this. If you agree and it adds less than a day you're welcome to do so. Otherwise skip.
    • I understand that this is underspecified but at least a log line and maybe another condition woudl be good here?

Out of scope

  • Validating the SecretClass on admission

Expected effort

1-2 days. If it takes longer, stop and flag it.

主要语言
Rust
星标
13
派生
8
平均合并
1 天 6 小时
30 天内合并 PR
8

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

stackabletech/secret-operator 的其他 Issue

查看 stackabletech/secret-operator 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。