KEP-5040: Remove gitRepo volume driver. #5039
Conversation
vinayakankugoyal
commented
Jan 14, 2025
•
vinayakankugoyal
commented
- One-line PR description: Initial KEP to remove support for gitRepo volume driver.
- Issue link: Remove gitRepo volume driver #5040
- Other comments:
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
kind/kep
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
Can you open an enhancement issue? Are you planning to target Alpha in 1.33? |
#5040. Yeah we are planning to target Alpha in 1.33 |
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
a7dca39 to
faf4ffe
Compare
vinayakankugoyal
changed the title
|
/ok-to-test |
k8s-ci-robot
added
the
ok-to-test
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
faf4ffe to
b39ccb0
Compare
|
/retest |
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
b39ccb0 to
430203c
Compare
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
430203c to
07fa827
Compare
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
07fa827 to
a4b48b0
Compare
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
a4b48b0 to
34acb88
Compare
| We propose removing support for the in-tree gitRepo volume driver. | ||
|
|
||
| We acknowledge that this is highly unusual, but there are mitigating circumstances: | ||
| * gitRepo volume types can be exploited to gain remote code execution as root on the nodes as shown in [CVE-2024-10220](https://nvd.nist.gov/vuln/detail/cve-2024-10220) | ||
| * gitRepo has perfectly workable alternatives: | ||
| * Using [git-sync](https://github.com/kubernetes/git-sync) | ||
| * Using an initContainer. See https://kubernetes.io/docs/concepts/storage/volumes/#gitrepo for more details | ||
| * gitRepo has been deprecated for a long time and is unmaintained | ||
| * gitRepo has low usage (based on limited data) | ||
| * there exists precedent for removing volume drivers which were unmaintained like [glusterfs](https://kubernetes.io/docs/concepts/storage/volumes/#glusterfs) | ||
|
|
||
| Given this, we think kubernetes should EOL this feature with urgency. |
There was a problem hiding this comment.
💭 Who's “we“? KEPs are usually written in the persona of the Kubernetes project, or maybe of a lead SIG.
There was a problem hiding this comment.
We here and in other locations is meant to represent the author(s). Would you like me to say the following instead?
"Give this, Kubernetes thinks it should EOL this feature with urgency."
|
@saad-ali I support this change, but the KEP document is not not ready to merge as implementable. It needs work. |
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
fbbcb5d to
c7efe3c
Compare
k8s-ci-robot
removed
the
lgtm
|
New changes are detected. LGTM label has been removed. |
vinayakankugoyal
force-pushed
the
gitRepo
branch
3 times, most recently
from
42ef30b to
bb72740
Compare
| **For non-optional features moving to GA, the graduation criteria must include | ||
| [conformance tests].** | ||
|
|
||
| [conformance tests]: https://git.k8s.io/community/contributors/devel/sig-architecture/conformance-tests.md |
There was a problem hiding this comment.
Noting: We do not have a conformance test for this volume type: https://github.com/kubernetes/kubernetes/blob/master/test/conformance/testdata/conformance.yaml
node_e2e tests are not conformance tests, and I think for this "feature" it's reasonable to not have one.
There was a problem hiding this comment.
Hmm.. I see that the following test in node_e2e saying NodeConformance.
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
bb72740 to
1f51a71
Compare
|
|
||
| ### Validating Admission Policy | ||
|
|
||
| Users can prevent workloads with gitRepo volumes from being admitted |
There was a problem hiding this comment.
Should we discuss creating a git repo to hold VAPs like this?
There was a problem hiding this comment.
Should we just put the VAP in the gitRepo volume documentation here?
There was a problem hiding this comment.
@thockin I think we should, and we should try to make that allow for a future, more rich way to manage add ons.
I know maybe WAGNI (we ain't gonna need it), but at least some demand is there.
Should we just put the VAP in the gitRepo volume documentation here?
No, partly because of kubernetes/website#42590 (the detailed list of volume types doesn't really belong in that page) and partly because I wouldn't put it there.
We could put the VAP in the removal announcement and make it evergreen; after we do that, other pages can hyperlink there. Hyperlinking to more detail is the right approach.
There was a problem hiding this comment.
We could put the VAP in the removal announcement and make it evergreen;
Fotr the less clueful, what does that mean concretely?
There was a problem hiding this comment.
[evergreen]
See https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#guidelines-and-expectations and kubernetes/website#31934
Also https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#technical-considerations-for-submitting-a-blog-post for what front matter you set.
@thockin I noted your encyclopedic knowledge on many things Kubernetes and inferred you'd know this detail. Sorry about that.
There was a problem hiding this comment.
Definitely arch, perhaps security given at least the first one we'd propose there?
I imagine cluster lifecycle would appreciate at least FYI as well, though that may steer things into the addon-management topic :+)
There was a problem hiding this comment.
[Also, this is not a blocker for the KEP, I think it's a good idea to publish a VAP, and we need to find an appropriate home, but I don't think the repo needs to be a hard requirement]
There was a problem hiding this comment.
I'd want to block off-by-default on having this in place. But not a merge of this PR.
There was a problem hiding this comment.
Yeah, I think we should plan to publish a VAP somewhere, and that should exist by off-by-default, but for alpha it can be a detail we're working out.
There was a problem hiding this comment.
Added that we plan to publish the VAPs to a public repository both in the VAP section and in the graduation criteria section.
vinayakankugoyal
force-pushed
the
gitRepo
branch
6 times, most recently
from
8169ca0 to
e99c213
Compare
| Recall that end users cannot usually observe component logs or access metrics. | ||
| --> | ||
|
|
||
| - [ ] Events |
There was a problem hiding this comment.
Should kubelet issue an event that it used an insecure volume?
There was a problem hiding this comment.
Is there precedent for doing that?
There was a problem hiding this comment.
I don't think so, but that doesn't make a bad idea out of hand :)
There was a problem hiding this comment.
Didn't mean to suggest that it was a bad idea, actually sounds like a good idea, I'm just not sure if its possible because I don't know enough about how those events are generated.
There was a problem hiding this comment.
I'm not saying it's a great idea either :) - it's an idea, please consider it and apply your context and wisdom.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: saad-ali, thockin, vinayakankugoyal The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
e99c213 to
dd78b09
Compare
k8s-ci-robot
added
size/XL
vinayakankugoyal
force-pushed
the
gitRepo
branch
2 times, most recently
from
f89e04e to
0ca41e9
Compare
vinayakankugoyal
force-pushed
the
gitRepo
branch
2 times, most recently
from
53125eb to
ba70c27
Compare
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
ba70c27 to
b4f2af2
Compare
