-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KEP-5040: Remove gitRepo volume driver. #5039
base: master
Are you sure you want to change the base?
Conversation
vinayakankugoyal
commented
Jan 14, 2025
•
edited
Loading
edited
- One-line PR description: Initial KEP to remove support for gitRepo volume driver.
- Issue link: Remove gitRepo volume driver #5040
- Other comments:
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 |
a7dca39
to
faf4ffe
Compare
/ok-to-test |
faf4ffe
to
b39ccb0
Compare
/retest |
b39ccb0
to
430203c
Compare
430203c
to
07fa827
Compare
07fa827
to
a4b48b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am LGTM on technicals - need th testing and release and PRR sections.
a4b48b0
to
34acb88
Compare
dbd3cfa
to
fbbcb5d
Compare
/lgtm |
sig-storage officially owns this, but to save you effort, I will apply the leads label -- stop me if you disagree! |
Thanks Tim and Vinayak. We are supportive of this plan from the SIG Storage side of things. /lgtm |
/assign @jpbetz |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💭 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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."
pod with an appropriate error message guiding users to either use an alternative | ||
or setting the feature-gate `GitRepoVolumeDriver` to `true`. | ||
|
||
### Timeline: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
### Timeline: | |
### Timeline |
This is the delivery plan, not a design detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the delivery plan, not a design detail.
I am not seeing a concrete suggestion here. Do you prefer this section be dropped or moved out of Design Details?
replaces: | ||
|
||
# The target maturity stage in the current dev cycle for this KEP. | ||
stage: alpha |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check that this is right. You might mean “deprecated”.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure what values this can take.
But based on your feedback about using “deprecated” in the graduation criteria maybe it makes sense to change this to "removed with opt-out"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a discussion on adding Deprecated but that PR didn't merge, let me go look for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out it was waiting for me. Oops. #4898
Since we are jumping to off-by-default, I think the Stage you want is "disabled"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, Ill wait for #4898 to be merged before updating this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT nothing is validating this, so don't block on it :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😭
"map[/home/prow/go/src/github.com/kubernetes/enhancements/keps/sig-storage/5040-remove-gitrepo-driver/kep.yaml:[getting PRR approver for diabled stage: invalid stage: diabled, should be one of [alpha beta stable]]]"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #5049 to fix validation.
@saad-ali I support this change, but the KEP document is not not ready to merge as implementable. It needs work. |
fbbcb5d
to
c7efe3c
Compare
New changes are detected. LGTM label has been removed. |
[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 |
42ef30b
to
bb72740
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[took a first pass as PRR Shadow]
Independently: personal +1 for this effort overall, thank you.
|
||
This removal is similar to removal of support for | ||
[glusterfs](https://kubernetes.io/docs/concepts/storage/volumes/#glusterfs) | ||
which was deprecated in v1.25 and removed in v1.26. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was there a KEP for this? Did we offer any migration like CSI migration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there was a KEP. I searched for the "glusterfs" under /keps/ and got only one hit but that KEP had nothing to do with removal.
**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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. I see that the following test in node_e2e saying NodeConformance.
<!-- | ||
What signals should users be paying attention to when the feature is young | ||
that might indicate a serious problem? | ||
--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably the user could monitor for pods being rejected?
(If there isn't a suitable signal, there's a section for that below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We aren't removing the gitRepo volume from the API so pods won't be rejected by kube-apiserver, kubelet will fail to start them. Maybe the recommendation should be around Pods that are failing to start?
bb72740
to
1f51a71
Compare
using the following Validating Admission Policy (VAP). | ||
|
||
```yaml | ||
apiVersion: admissionregistration.k8s.io/v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The VAP I have locally is a little different, perhaps @jpbetz or @cici37 can clarify which is more idiomatic or preferred? I think you started from an earlier draft of mine, because I had forgotten ReplicationController, too.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: "deny-git-repo-volumes"
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["podtemplates", "replicationcontrollers"]
- apiGroups: ["apps"]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["daemonsets", "deployments", "replicasets", "statefulsets"]
- apiGroups: ["batch"]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["jobs", "cronjobs"]
validations:
- expression: |
(object.kind == "Pod" &&
object.spec.?volumes.orValue([]).all(v, !has(v.gitRepo))) ||
(object.kind == "PodTemplate" &&
object.template.spec.?volumes.orValue([]).all(v, !has(v.gitRepo))) ||
(["DaemonSet","Deployment","ReplicaSet",'StatefulSet','Job','ReplicationController'].filter(kind, object.kind == kind) != [] &&
object.spec.template.spec.?volumes.orValue([]).all(v, !has(v.gitRepo))) ||
(object.kind == "CronJob" &&
object.spec.jobTemplate.spec.template.spec.?volumes.orValue([]).all(v, !has(v.gitRepo)))
message: "gitRepo volumes are forbidden"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
name: "deny-git-repo-volumes"
spec:
policyName: "deny-git-repo-volumes"
validationActions: [Deny]
# empty matchResources means match all
Your uses multiple expressions, which I am assuming is a logical AND? Mine uses postive polarity, but that results in OR.
Mine includes ReplicationController which yours misses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The VAP I have locally is a little different, perhaps @jpbetz or @cici37 can clarify which is more idiomatic or preferred? I think you started from an earlier draft of mine, because I had forgotten ReplicationController, too.
I used this as a starting point. I looks like they forgot ReplicationController as well 😅
Your uses multiple expressions, which I am assuming is a logical AND? Mine uses postive polarity, but that results in OR.
I tend to always use multiple expression other wise things become really hard to read and yes these are ANDed. According to the documentation
"If an expression evaluates to false, the validation check is enforced according to the spec.failurePolicy field."
Also verified this with some tests.
|
||
### Validating Admission Policy | ||
|
||
Users can prevent workloads with gitRepo volumes from being admitted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we discuss creating a git repo to hold VAPs like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we just put the VAP in the gitRepo volume documentation here?
5cef8d7
to
8cb44f9
Compare
8cb44f9
to
8169ca0
Compare