/sig cli
/priority important-soon

/retest

/lgtm
But I have to say --privileged is a dangerous flag and has security risks, I would like to hear more from the community.

/lgtm
But I have to say --privileged is a dangerous flag and has security risks, I would like to hear more from the community.

Agreed it is not a production use thing, or should not be.

The functionally already exists if you create your pod using yaml. This just adds a way to use it from the command line.

I too am interested if others have opinions on if this is too dangerous to make convenient.

/retest

/assign @mengqiy

This doesn't really add or change any new security-related functionality, it just makes it more convenient to do what you can already do.

For example:

The existing way to do this is:

kubectl run wanmap-fake-wan --image=bradmwalker/wanmap -it --rm --overrides='{"spec": {"metadata": {"name": "wanmap-fake-wan"}, "template": {"spec": {"containers": [{"name": "wanmap-fake-wan", "image": "bradmwalker/wanmap", "command": ["/bin/sh"], "tty": true, "stdin": true, "securityContext": {"privileged": true} }]}}}}'

This PR lets you just do this instead:

kubectl run wanmap-fake-wan --image=bradmwalker/wanmap -it --rm --privileged

@zhouya0 do you have anyone else in mind who might have some thoughts on this? I can add them.

/cc @mengqiy

Looks great, but I believe @mengqiy is not available since he is not active for a long time. You may ask more approvers to review this.

Rebased

/retest

/assign @soltysh

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brianpursley, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/test pull-kubernetes-e2e-gce-ubuntu-containerd

is this adding privileged to the debug container or just the default deployment that gets created with run ?

Copying ideas from docker should always be questioned.

I spend a lot of time explaining to developers that there docker compose files are inherently insecure. Most of the time the host system is modified on their laptops. Most time the containers use privileges. Now you copied this mess into kubernetes.

Adding privileges with a simple flag will cause real damages in production.
This is the most stupid idea since allowing to run applications on windows as admin.

This will keep me busy for the next ten years.

What you really should do is add PSP as a default everywhere.

Worried about the impact? You can suggest a revision against the dev-1.19 branch in k/website with a cautionary note where it makes sense.

(BTW, if you want to update the generated reference docs, those are based on the upstream code).

@krmayankk This flag just does the equivalent of setting privleged: true in your container's security context.

So for example, if I do this:

kubectl run test --image=nginx --privileged

And then look at the pod...

kubectl get pod test -o yaml

It shows:

...
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: test
    resources: {}
    securityContext:
      privileged: true
...

Starting in Kubernetes 1.19, run no longer will create a deployment (you would use kubectl create deployment for that now). So to your question about whether it affects deployments, no it would not.

Just to be clear, this flag only enables, via a command-line flag, what you were already able to do using yaml, and it only does this for kubectl run which is for running one-off pods, not intended for deploying production workloads.

@thomasfricke If you are worrying about windows privileged problems, it's not related to this PR because windows pods must have:

    securityContext:
        windowsOptions:

to enable admin.

Shouldn't it at least spit out a big fat warning?
This option makes insecure deployments easier, so let's ensure as much as possible that this is not done unconsciously.

I wouldn't be worried about your concern @garloff, currently kubectl run can only create pods, not deployments nor higher level resources. This is more like an entry-level command to help come up to speed for users coming from docker/podman/other container engine where that options is available. We rarely if at all spit warnings and using this requires explicit --privileged flag usage. Also, I'd expect privileged is properly limited at the cluster level so that not everyone has access to it, by default. We are targeting local devs with this, rather than production clusters.

Hackers will probably avoid this because the documentation clearly says it's for debugging purposes. We all know, hackers are the first to read the docs and will always abide by it.

@erikbgithub It is mentioned in this issue that you can already do this with convoluted command. This change won't affect people with malicious intent but help people adopt Kubernetes faster. There are lots of workloads needs to be run on privileged mode, mostly legacy ones and I believe this will only increase adoption.