-
Notifications
You must be signed in to change notification settings - Fork 40k
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
DisableServiceLinks admission controller #122631
DisableServiceLinks admission controller #122631
Conversation
|
Welcome @jmcgrath207! |
Hi @jmcgrath207. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
// newDisableServiceLinks creates a new instance of the DisableServiceLinks admission controller. | ||
func newDisableServiceLinks() *plugin { | ||
return &plugin{ | ||
Handler: admission.NewHandler(admission.Create, admission.Update), |
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 think this should operate only on Create, IIUIC Updates to a Pod will not recreate the environment variables
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.
Good Catch!
I did some testing in kind and found those fields are immutable when updating a pod. I removed admission.Update
in my commit.
$ kubectl apply -f simple-pod.yaml
The Pod "nginx" is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`,`spec.initContainers[*].image`,`spec.activeDeadlineSeconds`,`spec.tolerations` (only additions to existing tolerations),`spec.terminationGracePeriodSeconds` (allow it to be set to 1 if it was previously negative)
core.PodSpec{
... // 26 identical fields
RuntimeClassName: nil,
Overhead: nil,
- EnableServiceLinks: &true,
+ EnableServiceLinks: &false,
TopologySpreadConstraints: nil,
OS: nil,
... // 2 identical fields
}
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.
Supporting update might be a no-op today, but could be future-safe
/test pull-kubernetes-e2e-kind-ipv6 |
return errors.NewBadRequest(fmt.Sprintf("expected *core.Pod but got %T", attributes.GetObject())) | ||
} | ||
|
||
pod.Spec.EnableServiceLinks = ptr.To(false) |
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.
if we don't find a way to differentiate between defaulted by the apiserver or set by the user adding Always to the plugin name may be more accurate, AlwaysDisableServiceLinks
is just a thought wait for discussion of other reviewers
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.
Do we want to make this "smarter" (dubious judgement) and respect cases where the user actually set it, or do we want it to be unilateral and ALWAYS disable it?
This is a semantic decision. If it was easy, I'd say let's respect the user's input but it's not. It's not very complicated, but it's not trivial. Is it worthwhile?
Notes:
2 ways to do it:
-
Look at managed fields info to see what was defaulted. ISTR there is not actually enough info to determine this?
-
Let plugins see it as
nil
.
PrepareForCreate() is called from BeforeCreate() is called from staging/src/k8s.io/apiserver/pkg/registry/generic/registry/store.go Store.create().
createValidation (which includes admission plugins) is called AFTER callingBeforeCreate().
This means that we can't set the default in PrepareForCreate. We'd need a hook AFTER BeforeCreate() but before e.Storage.Create() to set defaults
one last comment #122631 (comment) and one doubt #122631 (comment) but LGTM |
@carlory Ah, I misunderstood. I've updated the release note description. Does this work for you? |
I'll approve and hold, if you want to re-add Update or rename it, ping me. Else just clear the hold. /approve |
da39708
to
edb0287
Compare
Thanks @thockin I've added the noop for If there is nothing else, I am ready to merge. |
Ugh, I missed this ping in the code freeze chaos. It will have to wait for 1.31. |
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.
/lgtm
/approve
LGTM label has been added. Git tree hash: 669ad6c4d821f5d6ccdc9dfe59cc94652caf86da
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jmcgrath207, thockin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
IMO this PR is the wrong approach, and we should consider reverting it before we release v1.31. kubernetes/enhancements#3962 should give users the ability to tweak the default as they desire though the Kube API, and we don't need to create one off admission plugins for every wrong default we have (especially since admission config isn't available to users on some environments). |
I don't have any philosophical preference for this sort of laser-focused admission plugins over MAP, except that MAP is alpha. At the time this proposal was in flgiht I wasn't so aware of MAP. That said, the interplay between default values and admission control sequencing leaves me scratching my head still. In a MAP or mutating webhook, I can't tell if a value was specified by a user or by the defaulting logic. This PR would probably consider that if it could, but it can't, so it doesn't. This issue is not so urgent that it can't wait for MAP, though I hope it's not TOOO long. So I guess I agree with @enj - are there any major reasons why we couldn't back this out and pivot the solution to MAP? |
ping to @jmcgrath207 one more time |
Hey All, Sorry for the late response. I went ahead and reviewed KEP-3962, and I agree this meets my needs. I feel it's best to revert my commit and move forward with the KEP-3962 solution to prevent a deprecation scenario. The Alpha part doesn't bother me since both solutions would require a control-plane config change. As for urgency, users can use a policy controller like kyverno that I mentioned here here or it can just edit the manifest. I assume I am in the minority here with heavy restrictions on image approval running in their environment. |
Do you want to send a revert or shall I? |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Adds an optional admission controller to disable EnableServiceLinks for new Pods without the need for a third-party mutating webhook.
Which issue(s) this PR fixes:
Fixes # #121787
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Thios PR was reverted in #125002.
The original relnote, for posterity: Added
DisableServiceLinks
admission controller: An optional mutating controller that will setSpec.EnableServiceLinks: False
for all pods manifests in the cluster before scheduling.Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
Agreement to solve this issue with an optional admission controller.
REF: #121787 (comment)