Since the PSP plugin will deny all requests until PSP objects are created it is not enabled by default. Once we're satisfied with bootstrapped RBAC roles we can enable a cluster wide "do anything" PSP that is also bootstrapped in but I worry that enabling it with no PSP api objects is just a bad experience.

@php-coder FYI

This is similar to RBAC. We can't change the default behavior of kube-up. This would have to be part of an opt-in secure profile.

cc @smarterclayton @liggitt

there are lots of APIs that are inert until an external component uses the data:

• ingresses (requires ingress controller deployed separately paying attention to the data)
• storageclasses (requires PV provisioner deployed separately paying attention to the data)
• rbac (requires RBAC authorizer in use, most deployments don't enable by default)
• network policies

Agree that we wouldn't enable the admission plugin in kube-up without opt-in

why is this considered a 1.6 blocker? I'm unclear about what is being advocated for 1.6.

I would propose that we don't enable the PSP object by default if we aren't going to enable the PSP admission controller by default (along w/ the necessary bootstrap policy or something).

It is effectively "not enabled" today, but we will happily create objects for you. I think it will cause confusion to be halfway on.

We can debate enablement, but I don't think this qualifies as a bug

Are we blocking for this issue?

I don't actually see the issue. Enabling the admission plugin (which we expose as a configurable cluster option) lets you use PodSecurityPolicies:

export ADMISSION_CONTROL=...,PodSecurityPolicy,...
./cluster/kube-up.sh

How is this any different from other APIs that support features some deployments don't enable?

The e2e aspect is unfortunate, but is a consequence of the fact that our e2e framework doesn't let you test configurations that require server restarts (e.g. different admission configurations). We don't have a precedent (to my knowledge) for admission plugin specific e2e jobs. We're in a similar spot with NetworkPolicy.

I would propose that we don't enable the PSP object by default if we aren't going to enable the PSP admission controller by default

I don't think that's a reasonable bar. The admission plugin default enablement will likely only be part of a "multitenant"-type security profile even when the API reaches v1

Agree that we should not block on this and it is opt-in behavior. The enablement was to fall in line with the api guidelines that state beta api objects should be enabled by default and PSP was not compliant, requiring extra steps to enable the API AND the admission plugin. (https://kubernetes.io/docs/concepts/overview/kubernetes-api/).

Ok, now that I better understand the state, I think there is no code issue that needs to be fixed now. We discussed having a "secure profile" in SIG Auth, and this would clearly fall under that umbrella.

However, the documentation for PSP is inadequate. I don't see this admission controller listed in the admission control docs, and the documentation about enablement in the PSP guide wasn't updated AFAICT.

https://github.com/kubernetes/kubernetes.github.io/blob/release-1.6/docs/user-guide/pod-security-policy/index.md
https://github.com/kubernetes/kubernetes.github.io/blob/release-1.6/docs/admin/admission-controllers.md

@liggitt @pweil- Could you please clarify the state of e2e testing?

Could you please clarify the state of e2e testing

current state is inadequate, we need an e2e test that runs with enabled RBAC and tests the permissions and denial of particular settings.

I will note, though, that the vast majority (if not all) of the individual admit/deny settings are covered in the admission unit test.

@php-coder can you take a stab at updating the docs and looking at an e2e test?

@php-coder don't forget the use case of MustRunAsNonRoot UID which has an additional kubelet check if no RunAsUser is set and surfaces as an error in the state - it's not all admit/deny. That's the only tricky one I can think off of the top of my head.

can you take a stab at updating the docs and looking at an e2e test?

@pweil- Yes, I can.

These tests should have been already completed, this should not block 1.6

Though I realize it's the status quo now, in the future we should disable inert APIs. The API discovery mechanism needs to be able to be used to accurately determine the availability of features. Additionally, allowing people to create resources that don't do anything creates a potential time bomb (for another time bomb example, see #30819).

Additionally, the test coverage of PSP is very weak, since it isn't active by default in GCE, GKE, and AWS which are the platforms for which are continuously tested, by the submit queue and in the PR builder.

#46064 is working to enable/test this, but will come in 1.8

Though I realize it's the status quo now, in the future we should disable inert APIs. The API discovery mechanism needs to be able to be used to accurately determine the availability of features. Additionally, allowing people to create resources that don't do anything creates a potential time bomb (for another time bomb example, see #30819).

@bgrant0607 - A counter argument is that creating the PSP objects before enabling the controller can smooth the transition. Turning on the controller without creating any PSPs & bindings will prevent the creation of all pods, so we're going to recommend creating the necessary bindings first.

[MILESTONENOTIFIER] Milestone Removed

@cjcullen @liggitt @tallclair

Important: This issue was missing labels required for the v1.9 milestone for more than 3 days:

kind: Must specify exactly one of kind/bug, kind/cleanup or kind/feature.

PSP is on in CI now, with e2e tests