Support rotating certs in running pods instead of restarting them
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- kubernetes, rust
调研方向
Start by tracing the CSIDriver configuration and the NodePublishVolume implementation, then find where the replace time is computed for the restarter annotation. The issue proposes opt-in per-volume certificate renewal, safe replacement of files in mounted volumes, and retaining restart behavior as a fallback. Done would include renewal on republish without exposing partially written certificates; the issue names no files or tests.
由索引模型根据 Issue 内容生成。
描述
Description
Right now, when a cert from the secret-operator gets close to expiring, the restarter just kills the pod based on the annotation set by secret-op (I think). That works, but it’s annoying for things that are slow to come back up or don't handle restarts well (looking at you, NiFi!), and it means short cert lifetimes come with a lot of restarts.
Some products can already reload certs from disk on their own. For example NiFi does this with nifi.security.autoreload.enabled. For products like that, it’d be nice if we could swap the cert in the volume and let the product take it from there, without forcing an unneeded restart on the pod.
The CSI lifecyle in Kubernetes has a hook for this: if we set requiresRepublish: true on our CSIDriver, the kubelet keeps calling NodePublishVolume for volumes that are already mounted. We can use that to check whether the cert is past its replace time and, if so, issue a new one and write it into the existing volume. We already compute that time for the restarter annotation, so we’d mainly need to keep it somewhere cheap to check, for example in memory with a small file in the volume as a fallback after the driver restarts.
This would have to be opt-in per volume, since products that don’t reload would just keep using the old cert until it expires. We’d probably also keep the restarter annotation as a safety net in case reissuing fails.
Bit of file handling to investigate since we don't want half-written certs being read, so probably need to come up with some symlink or mv magic, but that should be doable.
- 主要语言
- Rust
- 星标
- 14
- 派生
- 8
- 平均合并
- 1 天 12 小时
- 30 天内合并 PR
- 9
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
stackabletech/secret-operator 的其他 Issue
-
type/bug
难度 4/5 3-5 天 新手友好度 45/100
stackabletech/secret-operator#754 ·
维护者通常 1 天内回复
-
autoTls: bound certificate lifetime by the CA that will actually sign it, not the configured caCertificateLifetime可能已有人在做 @xeniape 于 20 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 48/100
stackabletech/secret-operator#753 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
skip the PodListeners lookup when the served Pod is being deleted可能已有人在做 @soenkeliebau 于 4 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 72/100
stackabletech/secret-operator#720 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
customer-request type/bug
难度 3/5 1-2 天 新手友好度 38/100
stackabletech/secret-operator#666 · 2 条评论 ·
维护者通常 1 天内回复
-
Allow certificates to contain subjects with allowed external names可能重新可做 @NickLarsenNZ 于 446 天前认领，目前没有进行中的 PR。 未关闭customer-request type/feature-improvement
stackabletech/secret-operator#630 · 7 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 stackabletech/secret-operator 的全部 Issue
相似的 Issue
-
yara-x fails to build with rsa 0.10.0: unresolved import rsa::Pkcs1v15Sign可能已有人在做 @CfirTsabari 今天认领。 未关闭
难度 1/5 1 小时以内 新手友好度 87/100
VirusTotal/yara-x#865 ·
维护者通常 1 天内回复
-
good first issue help wanted program
难度 2/5 1-3 小时 新手友好度 83/100
hffgzktbcc-blip/ounce-core#297 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
nautechsystems/nautilus_trader#5631 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 69/100
bytecodealliance/rustix#1736 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
longbridge/gpui-kit#3871 ·
维护者通常 1 天内回复