change deprecated Kubelet --allow-privileged flag default to true #63442
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This enables a smooth transition to PSP. Today, users would have to manually set --allow-privileged to true before transitioning to PSP, which isn't a smooth deprecation path for the flag (we want people to *stop* setting it). This PR makes the default behavior isomorphic with what will happen after the flag is removed. Defaulting --allow-privileged to true should be safe, because it simply allows a superset of Pods to run (all workloads continue to work). WRT kubernetes#58010 (comment) the --allow-privileged flag is effectively useless for security, so this shouldn't be a concern from that perspective. I also bumped the deprecation timeline in the comment to 1.13.0, so that we give people the full period of time to stop setting --allow-privileged, now that the behavior makes it possible to do so.
mtaufen
added
kind/bug
k8s-ci-robot
added
size/XS
|
@mtaufen in 1.7 i can create privileged containers without my kubelet having this flag, am i missing something ? |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/retest |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mtaufen, Random-Liu, tallclair 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 |
k8s-ci-robot
added
the
approved
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/test all [submit-queue is verifying that this PR is safe to merge] |
|
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here. |
k8s-github-robot
pushed a commit
that referenced
this pull request
Jun 20, 2018
…d-true Automatic merge from submit-queue (batch tested with PRs 65032, 63471, 64104, 64672, 64427). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. changed the default value for allow-privileged for the kubelet (kuber… **What this PR does / why we need it**: This PR modifies the default value for the kubernetes-worker: it sets the allow-privileged kubelet value to true, based on this issue:[https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/579](https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/579). The original PR was here: [#63442 which included this change for the k8s 1.10 release. This PR incorporates this fix into the Canonical distribution of Kubernetes. **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: Fixes # This change fixes two issues: [https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/579](https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/579) [rancher/rancher#13612 **Special notes for your reviewer**: Waiting review from Canonical Kubernetes charm tea. **Release note**: ```release-note The new default value for the --allow-privileged parameter of the Kubernetes-worker charm has been set to true based on changes which went into the Kubernetes 1.10 release. Before this change the default value was set to false. If you're installing Canonical Kubernetes you should expect this value to now be true by default and you should now look to use PSP (pod security policies). ```
mikkeloscar
added a commit
to zalando-incubator/kubernetes-on-aws
that referenced
this pull request
Aug 27, 2018
Remove the `--allow-privileged` flag from the kubelet since it now defaults to `true` and has been marked deprecated and will be removed in v1.13. kubernetes/kubernetes#63442 Signed-off-by: Mikkel Oscar Lyderik Larsen <mikkel.larsen@zalando.de>
BugRoger
added a commit
to sapcc/kubernikus
that referenced
this pull request
Apr 16, 2019
This enables a smooth transition to PSP. Today, users would have to manually set --allow-privileged to true before transitioning to PSP, which isn't a smooth deprecation path for the flag (we want people to stop setting it). This PR makes the default behavior isomorphic with what will happen after the flag is removed. kubernetes/kubernetes#63442
|
good |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enables a smooth transition to PSP. Today, users would have to
manually set --allow-privileged to true before transitioning to PSP,
which isn't a smooth deprecation path for the flag (we want people
to stop setting it). This PR makes the default behavior isomorphic
with what will happen after the flag is removed.
Defaulting --allow-privileged to true should be safe, because it simply
allows a superset of Pods to run (all workloads continue to work).
WRT #58010 (comment)
the --allow-privileged flag is effectively useless for security, so this
shouldn't be a concern from that perspective.
I also bumped the deprecation timeline in the comment to 1.13.0, so that
we give people the full period of time to stop setting
--allow-privileged, now that the behavior makes it possible to do so.