🐛 Envtest: Allow creating objects with privileged container specs

[alvaroaleman]

Currently it is not possible to use envtest to create things with privileged containers in them, because the --allow-privileged flag on the kube-apiserver defaults to false. Attempting to do so causes a Deployment.apps \"deployment-name\" is invalid: spec.template.spec.containers[0].securityContext.privileged: Forbidden: disallowed by cluster policy".

This PR changes that.

[alvaroaleman]

/assign @DirectXMan12

[DirectXMan12]

Not to nitpick this too much, but is there a compelling reason to make this default vs just overriding it when you need it by adding to the API server flags?

[alvaroaleman]

Not to nitpick this too much, but is there a compelling reason to make this default vs just overriding it when you need it by adding to the API server flags?

Yeah, thats how I got my tests going :) Mostly adding this to share, before I ran into this I was not aware that such a flag exists on the kube-apisever and I am reasonable sure I have never worked with a cluster that kept it at the default.

[DirectXMan12]

ah, ok. Perhaps we should add this to FAQs? Not that it makes much different having it here or not because you can't actually run pods with envtest ;-)

[alvaroaleman]

ah, ok. Perhaps we should add this to FAQs? Not that it makes much different having it here or not because you can't actually run pods with envtest ;-)

It seems simpler to me to just add it by default, because it is a de-facto default and required for anything that uses it as part of a PodSpecTemplate, like Deployments, Statefulsets and Daemonsets.

A common use-case for it is e.G. CNI or CSI.
I disagree, I think it does make a difference because this doesn't just prevent privileged pod creation, it already prevents creation of anything that has PodSpecTemplate

[DirectXMan12]

Ack, ok. I'm editing the title to avoid freaking anyone out, but that seems like a reasonable argument

[DirectXMan12]

/lgtm
/approve

[DirectXMan12]

/hold

[DirectXMan12]

whoops. Can you get rid of boolptr? I hate that library an unhealthy amount.

[alvaroaleman]

whoops. Can you get rid of boolptr? I hate that library an unhealthy amount.

Done. What makes you prefer func myTypePtr() everywhere if I may ask?

[DirectXMan12]

oh, I usually just do

definitelyTrue := true
...
thingThatNeedsABoolPointer: &definitelyTrue

or somesuch.

It's mostly that it's yet another dependency that will arbitrarily break in incompatible ways at some point in the future, and I really don't want to have to deal with incompatibilities while upgrading cause of a few calls to BoolPtr or something.

It's not actually as huge a deal as I make it sound, and half of my grumbling is probably because I really just want to write Some(true) and be done with it :-P

[DirectXMan12]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alvaroaleman, DirectXMan12

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:

• OWNERS [DirectXMan12]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[alvaroaleman]

/hold cancel