Rewrite PodSecurityPolicy guide #6378

tallclair · 2017-11-20T01:57:54Z

This is an almost complete rewrite. Summary of changes:

Add an end-to-end example
Reorganize reference section, and add some missing features (seccomp, apparmor, ...)
Add recommendations, where appropriate (e.g. pair MustRunAsNonRoot with AllowPrivilegeEscalation=false, bind to service accounts, etc.)
Add section on PSP ordering
Remove sections on create / edit / delete, as those are common to all k8s resources.

/cc @liggitt @php-coder

This change is

k8s-ci-robot · 2017-11-20T01:57:55Z

@tallclair: GitHub didn't allow me to request PR reviews from the following users: php-coder.

Note that only kubernetes members can review this PR, and authors cannot review their own PRs.

In response to this:

This is an almost complete rewrite. Summary of changes:

Add an end-to-end example

Reorganize reference section, and add some missing features (seccomp, apparmor, ...)

Add recommendations, where appropriate (e.g. pair MustRunAsNonRoot with AllowPrivilegeEscalation=false, bind to service accounts, etc.)

Add section on PSP ordering

Remove sections on create / edit / delete, as those are common to all k8s resources.

/cc @liggitt @php-coder

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.

k8sio-netlify-preview-bot · 2017-11-20T01:59:56Z

Deploy preview ready!

Built with commit 5d39cfe

https://deploy-preview-6378--kubernetes-io-master-staging.netlify.com

liggitt · 2017-11-20T02:05:56Z

+100
thanks for taking this on. Will review as soon as I can
cc @pweil-

tengqm · 2017-11-20T03:15:11Z

docs/concepts/policy/pod-security-policy.md


-### FSGroup
+Once a PodSecurityPolicy resource has been created, it does nothing. In order to


”Once“ -> ”Initially when" ?

Went with when

tengqm · 2017-11-20T03:31:27Z

docs/concepts/policy/pod-security-policy.md

+First, a `Role` or `ClusterRole` needs to grant access to `use` the desired
+policies. The rules to grant access look like this:
+
+```yaml


Better make this snippet a complete manifest for users, i.e. add apiVersion, kind, metadata.

tengqm · 2017-11-20T05:20:11Z

docs/concepts/policy/pod-security-policy.md

+   used.
+2. Otherwise, the first valid policy in alphabetical order is used.
+
+## Example


Since the example presented here is a full story by itself, I'd suggest separating it out from the "concepts" page by creating a "task".

I don't see the value in that. Personally I find it much more useful to have a example alongside the documentation, so that I have access to both when I click the first search result.

If you're worried about the length of this page, I could be convinced to separate out the reference section.

I'm mostly okay with simple examples e.g. a manifest showing users how things look like.
This "example" is a little bit long. It is actually an exercise for users. They will need to create a separate namespace.
This is just my own feelings. I understand people have different reading habits. :)

I'm curious what other's think about this. Is your goal to keep tutorials & reference docs separate, or just to shrink this page? I personally like having a thorough example alongside the reference docs, but we should go for consistency.

I like the idea but I'd suggest to postpone it and merge this PR as-is.

tengqm · 2017-11-20T05:22:07Z

docs/concepts/policy/pod-security-policy.md

+
+```shell
+$ kubectl create namespace psp-example
+$ kubectl create serviceaccount -n psp-example fake-user


rename 'fake-user' to 'fake-sa' or 'fake-account' for clarity?

But it's a real service account, and a fake user :)
I think fake-user communicates the intent better, which is that we are using this account to act as an unprivileged (fake) user.

tengqm · 2017-11-20T08:20:26Z

docs/concepts/policy/pod-security-policy.md

+defaults to allowed.
+
+**DefaultAllowPrivilegeEscalation** - Sets the default for the
+`AllowPrivilegeEscalation` option. The default behavior is to allow privilege


Better clarify the AllowPrivilegeEscalation here. Does it mean the field of PodSecurityPolicy or the field 'pod.spec.container[i].securityContext.allowPrivilegeEscalation' ?

It's explained above the fields, since it applies to both fields. Would you prefer I give the full path instead of container option?

"sets the default for the AllowPrivilegeEscalation option" <-- when reading this, I was a bit confused.

Let me try again. This field works only when both the following conditions are met. The admission controller mutates the Pod spec by injecting the value of this field as the allowPrivilegeEscalation property for the container's security context.

the AllowPrivilegeEscalation field of the PodSecurityPolicy is unspecified

the container's security context has left allowPrivilegeEscalation unspecified

Sorry if I failed making it clear again... taxes to pay for a non-native speaker.

I tried to clarify it. Better?

the AllowPrivilegeEscalation field of the PodSecurityPolicy is unspecified

If it's set to true, this field can still be used to default it to false.

tallclair

Thanks, comments addressed.

tallclair · 2017-11-20T18:30:25Z

docs/concepts/policy/pod-security-policy.md


-### FSGroup
+Once a PodSecurityPolicy resource has been created, it does nothing. In order to


Went with when

tallclair · 2017-11-20T18:32:57Z

docs/concepts/policy/pod-security-policy.md

+First, a `Role` or `ClusterRole` needs to grant access to `use` the desired
+policies. The rules to grant access look like this:
+
+```yaml


tallclair · 2017-11-20T18:34:11Z

docs/concepts/policy/pod-security-policy.md

+   used.
+2. Otherwise, the first valid policy in alphabetical order is used.
+
+## Example


I don't see the value in that. Personally I find it much more useful to have a example alongside the documentation, so that I have access to both when I click the first search result.

If you're worried about the length of this page, I could be convinced to separate out the reference section.

tallclair · 2017-11-20T18:35:22Z

docs/concepts/policy/pod-security-policy.md

+
+```shell
+$ kubectl create namespace psp-example
+$ kubectl create serviceaccount -n psp-example fake-user


But it's a real service account, and a fake user :)
I think fake-user communicates the intent better, which is that we are using this account to act as an unprivileged (fake) user.

tallclair · 2017-11-20T18:37:09Z

docs/concepts/policy/pod-security-policy.md

+defaults to allowed.
+
+**DefaultAllowPrivilegeEscalation** - Sets the default for the
+`AllowPrivilegeEscalation` option. The default behavior is to allow privilege


It's explained above the fields, since it applies to both fields. Would you prefer I give the full path instead of container option?

tengqm · 2017-11-21T06:19:02Z

docs/concepts/policy/pod-security-policy.md

+$ kubectl-admin delete ns psp-example
+namespace "psp-example" deleted
+```
+


To be concise, I was suggesting moving line 145-321 into a task. The example by itself has 180 lines in total.

tengqm · 2017-11-21T06:38:54Z

docs/concepts/policy/pod-security-policy.md

+defaults to allowed.
+
+**DefaultAllowPrivilegeEscalation** - Sets the default for the
+`AllowPrivilegeEscalation` option. The default behavior is to allow privilege


"sets the default for the AllowPrivilegeEscalation option" <-- when reading this, I was a bit confused.

Let me try again. This field works only when both the following conditions are met. The admission controller mutates the Pod spec by injecting the value of this field as the allowPrivilegeEscalation property for the container's security context.

the AllowPrivilegeEscalation field of the PodSecurityPolicy is unspecified

the container's security context has left allowPrivilegeEscalation unspecified

Sorry if I failed making it clear again... taxes to pay for a non-native speaker.

php-coder · 2017-11-22T16:12:56Z

docs/concepts/policy/example-psp.yaml

@@ -11,10 +13,5 @@ spec:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
-  hostPorts:
-  - min: 8000
-    max: 8080
  volumes:
  - '*'


That make it still permissive (as it allows hostPath volume type). Consider limiting the number of allowed types to fixed number (AFAIR we had a recommended list somewhere..)

I was trying to keep this policy as minimal as possible, just to demonstrate that it is being applied in the example. The restricted policy (restricted-psp.yaml) is the one that actually applies the recommended best practices.

"unprivileged" still makes it sound like it will be restrictive... not sure a better name for what this does

Went with just "example".

php-coder · 2017-11-22T16:17:46Z

docs/concepts/policy/restricted-psp.yaml

+      - min: 1
+        max: 65535
+  fsGroup:
+    rule: 'RunAsAny'


Why we disallow adding the root group in supplemental groups and permit this group here?

Oops, fixed locally & forgot to push. Done.

BTW - I filed kubernetes/kubernetes#56173 for this case. Unfortunately these rules as written default to applying the 1 GID to every container.

php-coder · 2017-11-22T16:23:41Z

As you have renamed yaml file and have added a couple new ones, don't forget to also update a test for them:

website/test/examples_test.go

Lines 237 to 239 in a0d1143

    
           "../docs/concepts/policy": { 
        
           	"psp": {&extensions.PodSecurityPolicy{}}, 
        
           },

P.S. This should fix build on TravisCI:

--- FAIL: TestExampleObjectSchemas (0.13s)
	examples_test.go:356: ../docs/concepts/policy/example-psp.yaml: example-psp does not have a test case defined
	examples_test.go:356: ../docs/concepts/policy/privileged-psp.yaml: privileged-psp does not have a test case defined
	examples_test.go:356: ../docs/concepts/policy/restricted-psp.yaml: restricted-psp does not have a test case defined

php-coder · 2017-11-22T16:40:18Z

Reorganize reference section, and add some missing features (seccomp, apparmor, ...)

The last time when I tried to document them, we had no strong opinion about whether we should document annotations or we shouldn't. I'd be glad to hear that our vision has been changed.

If we're going to document them, I'd suggest to also include security.alpha.kubernetes.io/sysctls (see #3174).

php-coder · 2017-11-22T17:35:32Z

docs/concepts/policy/pod-security-policy.md

+| Allocating an FSGroup that owns the pod's volumes   | [`fsGroup`](#volumes-and-file-systems)      |
+| Requiring the use of a read only root file system   | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
+| The user and group IDs of the container             | [`runAsUser`, `supplementalGroups`](#users-and-groups) |
+| Restricting root privileges                         | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) |


Perhaps, it's better to rephrase "Restricting root privileges" to emphasize the fact that it not about root but about getting root privs.

What's about "Restricting obtaining of root privileges", "Restricting getting the root privileges"?

php-coder · 2017-11-22T17:37:00Z

docs/concepts/policy/pod-security-policy.md

-`seLinuxOptions`.
- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be
-specified.
+Pod security policy control is implemented as an optional [admission


I'm a bit surprised that admission plugin is optional. How the control will work without it?

I'm not sure I understand your question. If the plugin is not enabled, then PodSecurityPolicy won't be enforced, but the cluster will still work.

So, it means, that there will be no control and all pods will be accepted.

I'd rather remove "optional" word from here because in reality nothing will work without admission plugin as we expect.

I think the phrasing is more that it is optional but highly encouraged for production environments. You don't have to run it, you just have to accept the risk.

It's not enabled by default, it's in beta, and until recently wasn't tested in any e2e environments. I don't think we can claim it's not optional, but I added a note that it's recommended.

php-coder · 2017-11-22T17:39:16Z

docs/concepts/policy/pod-security-policy.md

+
+{% include code.html language="yaml" file="example-psp.yaml" ghlink="/docs/concepts/policy/example-psp.yaml" %}
+
+And create it with the standard `kubectl` command:


s/the standard kubectl command/our kubectl wrapper/ ?

How about just 'create it with kubectl:`

php-coder · 2017-11-22T17:40:40Z

docs/concepts/policy/pod-security-policy.md

+
+Now, as the unprivileged user, try to create a simple pod:
+
+```


Please, add ```shell here to highlight the fragment.

php-coder · 2017-11-22T17:42:22Z

docs/concepts/policy/pod-security-policy.md

+1m         2m          15        pause-7774d79b5   ReplicaSet                            Warning   FailedCreate            replicaset-controller                   Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
+```
+
+**What happened?** We already bound the psp:unprivileged role for our fake-user,


Maybe we need to stand out psp:unprivileged and fake-user here.

I'm not sure what you mean by "stand out". Did you mean add the inline-code backticks?

Yes, I did.

php-coder · 2017-11-22T17:44:42Z

docs/concepts/policy/pod-security-policy.md

+### Host namespaces
+
+**HostPID** - Controls whether the pod containers can share the host process ID
+namespace. Note that when paired with ptrace this can be used to escalate


Good point about ptrace!

But in order to use ptrace we need to have CAP_SYS_PTRACE capability, correct?

Correct. Clarified that it's not enabled by default.

php-coder · 2017-11-22T17:45:30Z

docs/concepts/policy/pod-security-policy.md

+traditionally associated with the superuser. Some of these capabilities can be
+used to escalate privileges or for container breakout, and may be restricted by
+the PodSecurityPolicy. For more details on Linux capabilities, see
+[Capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html).


s/Capabilities(7)/capabilities(7)/

php-coder · 2017-11-22T17:47:02Z

docs/concepts/policy/pod-security-policy.md


-This command will open a default text editor where you will be able to modify policy.
+- *MustRunAs* - Requires `seLinuxOptions` to be configured if not using
+pre-allocated values. Uses `seLinuxOptions` as the default. Validates against


AFAIK there is no "pre-allocated values" and this sentence is wrong.

I'm actually not familiar with SELinux support at all. This was copied from the previous version of this page. Can you suggest a replacement?

I suggest the following:

*MustRunAs* - Requires `seLinuxOptions` to be configured. Uses `seLinuxOptions` as the default and as the value to validate against.

@pweil- @liggitt Please, confirm that there is no "pre-allocated values" in Kubernetes.

php-coder · 2017-11-22T17:48:11Z

docs/concepts/policy/pod-security-policy.md

+**AllowedCapabilities** - Provides a whitelist of capabilities that may be added
+to a container. The default set of capabilities are implicitly allowed. The
+empty set means that no additional capabilities may be added beyond the default
+set.


I think that we also could mention about * here.

php-coder · 2017-11-22T17:49:56Z

docs/concepts/policy/pod-security-policy.md

-defines a host path to match. The value cannot be "`*`" though.
-An example is shown below:
+**AllowedHostPaths** - This specifies a whitelist of host paths that are allowed
+to be used by HostPath volumes. An empty list means there is no restriction on


Consider replacing HostPath by hostPath in this paragraph.

php-coder · 2017-11-22T17:50:53Z

docs/concepts/policy/pod-security-policy.md

@@ -125,141 +399,153 @@ to the volume sources that are defined when creating a volume:
 The recommended minimum set of allowed volumes for new PSPs are
 configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.


I'd highlight the recommended volume types.

liggitt · 2017-11-23T03:30:07Z

docs/concepts/policy/pod-security-policy.md

+Define the example PodSecurityPolicy object in a file. This is a policy that
+simply prevents the creation of privileged pods.
+
+{% include code.html language="yaml" file="example-psp.yaml" ghlink="/docs/concepts/policy/example-psp.yaml" %}


things I didn't know we could do

liggitt · 2017-11-23T03:35:42Z

docs/concepts/policy/pod-security-policy.md

+
+- *MustRunAs* - Requires at least one range to be specified. Uses the
+minimum value of the first range as the default. Validates against the
+first ID in the first range.


I thought validation required the groups to fall within one of the specified ranges. Where are you seeing validation use the first id in the first range?

Copied from the old docs, but I think it was a typo. Changed so MustRunAs docs are consistent.

liggitt · 2017-11-23T03:38:50Z

docs/concepts/policy/pod-security-policy.md

+of the range as the default. Validates against the configured range.
+- *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero
+`runAsUser` or have the `USER` directive defined (using a numeric UID) in the
+image. No default provided. Setting `AllowPrivilegeEscalation=false` is strongly


allowPrivilegeEscalation to match API json field?

liggitt · 2017-11-23T03:39:02Z

docs/concepts/policy/pod-security-policy.md

+
+### Privilege Escalation
+
+These options control the `AllowPrivilegeEscalation` container option. This bool


allowPrivilegeEscalation

oh, misunderstood... thought this was the pod API field

liggitt · 2017-11-23T03:42:00Z

docs/concepts/policy/pod-security-policy.md

+against [the secured API port](/docs/admin/accessing-the-api/), and must not
+have superuser permissions. Otherwise requests would bypass authentication and
+authorization modules, all PodSecurityPolicy objects would be allowed,
+and user will be able to create privileged containers.


s/user will/users would/

liggitt · 2017-11-23T03:43:13Z

docs/concepts/policy/pod-security-policy.md

+
+- The [Controller Manager](/docs/admin/kube-controller-manager/) must be run
+against [the secured API port](/docs/admin/accessing-the-api/), and must not
+have superuser permissions. Otherwise requests would bypass authentication and


can mention --use-service-account-credentials in combination with RBAC as a good way of making the controller loops run with bounded permissions.

liggitt · 2017-11-23T03:56:20Z

docs/concepts/policy/pod-security-policy.md

+above, plus `*` to allow all profiles. Absence of this annotation means that the
+default cannot be changed.
+
+## Troubleshooting


should probably hoist this up into the authorizing policies section... reading all the way to the bottom to see the "here's how to make sure you're not accidentally insecure" isn't great

liggitt · 2017-11-23T03:59:50Z

docs/concepts/policy/restricted-psp.yaml

+  # This is redundant with non-root + disallow privilege escalation,
+  # but we can provide it for defense in depth.
+  requiredDropCapabilities:
+    - ALL


is dropping all capabilities best practice? does that cause problems for most images?

See the comment above. Running as non-root drops all capabilities from the effective set (I don't think there's a way around this?) and no_new_privs disables file capabilities, so there is no way to access the bounding set. This is what I meant about it being redundant, but the capabilities might as well be dropped (e.g. if a kernel bug lead to a root privilege escalation, maybe it would still have 0 capabilities).

pweil- · 2017-11-27T15:00:23Z

docs/concepts/policy/pod-security-policy.md

 ```

-## Admission
+**What happened?** Although the PodSecurityPolicy was created, neither the
+created pod nor `fake-user` have permission to use the new policy:


a little confusing since pods do not get permission to use the policy

pweil- · 2017-11-27T15:35:54Z

docs/concepts/policy/pod-security-policy.md

+
+**AllowPrivilegeEscalation** - Gates whether or not a user is allowed to set the
+security context of a container to `allowPrivilegeEscalation=true`. This
+defaults to allowed. When set to false, the container's `allPrivilegeEscalation`


allPrivilegeEscalation -> allowPrivilegeEscalation

tallclair

Comments addressed. Thanks!

tallclair · 2017-11-27T19:49:58Z

docs/concepts/policy/pod-security-policy.md

+
+- *MustRunAs* - Requires at least one range to be specified. Uses the
+minimum value of the first range as the default. Validates against the
+first ID in the first range.


Copied from the old docs, but I think it was a typo. Changed so MustRunAs docs are consistent.

tallclair · 2017-11-27T19:51:47Z

docs/concepts/policy/example-psp.yaml

@@ -11,10 +13,5 @@ spec:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
-  hostPorts:
-  - min: 8000
-    max: 8080
  volumes:
  - '*'


Went with just "example".

tallclair · 2017-11-27T19:51:56Z

docs/concepts/policy/pod-security-policy.md

-minimum value of the first range as the default. Validates against the
-first ID in the first range.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
+Most Kubernetes pods are not created directly by user. Instead, they are


tallclair · 2017-11-27T19:52:00Z

docs/concepts/policy/pod-security-policy.md

+[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), or other
+templated controller via the controller manager. Granting the controller access
+to the policy would grant access for *all* pods created by that the controller,
+so the preferable method for authorizing policies is to grant access to the


tallclair · 2017-11-27T19:52:16Z

docs/concepts/policy/pod-security-policy.md

+
+In addition to restricting pod creation and update, pod security policies can
+also be used to provide default values for many of the fields that it
+controls. However, this presents a problem when multiple policies are available


tallclair · 2017-11-27T19:56:12Z

docs/concepts/policy/pod-security-policy.md

+above, plus `*` to allow all profiles. Absence of this annotation means that the
+default cannot be changed.
+
+## Troubleshooting


tallclair · 2017-11-27T20:00:27Z

docs/concepts/policy/pod-security-policy.md

+
+- The [Controller Manager](/docs/admin/kube-controller-manager/) must be run
+against [the secured API port](/docs/admin/accessing-the-api/), and must not
+have superuser permissions. Otherwise requests would bypass authentication and


tallclair · 2017-11-27T20:00:57Z

docs/concepts/policy/pod-security-policy.md

+against [the secured API port](/docs/admin/accessing-the-api/), and must not
+have superuser permissions. Otherwise requests would bypass authentication and
+authorization modules, all PodSecurityPolicy objects would be allowed,
+and user will be able to create privileged containers.


tallclair · 2017-11-27T20:03:46Z

docs/concepts/policy/restricted-psp.yaml

+  # This is redundant with non-root + disallow privilege escalation,
+  # but we can provide it for defense in depth.
+  requiredDropCapabilities:
+    - ALL


See the comment above. Running as non-root drops all capabilities from the effective set (I don't think there's a way around this?) and no_new_privs disables file capabilities, so there is no way to access the bounding set. This is what I meant about it being redundant, but the capabilities might as well be dropped (e.g. if a kernel bug lead to a root privilege escalation, maybe it would still have 0 capabilities).

tallclair · 2017-11-27T20:18:58Z

docs/concepts/policy/pod-security-policy.md

-`seLinuxOptions`.
- *RunAsAny* - No default provided. Allows any `seLinuxOptions` to be
-specified.
+Pod security policy control is implemented as an optional [admission


It's not enabled by default, it's in beta, and until recently wasn't tested in any e2e environments. I don't think we can claim it's not optional, but I added a note that it's recommended.

pweil-

LGTM

aasmall · 2017-11-27T22:02:58Z

Review status: 0 of 5 files reviewed at latest revision, 37 unresolved discussions, some commit checks failed.

docs/concepts/policy/pod-security-policy.md, line 154 at r4 (raw file):

Otherwise, the first valid policy in alphabetical order is used.
I'd rather the docs not specify and guaranteed ordering after non-altering policies. It's unlikely "alphabetical" will last long and I'd hate for people to take dependency. Better, I think, to state that it is not deterministic.

Comments from Reviewable

aasmall · 2017-11-27T22:15:44Z

Reviewed 2 of 5 files at r1, 1 of 2 files at r3, 3 of 3 files at r4.
Review status: all files reviewed at latest revision, 37 unresolved discussions, some commit checks failed.

Comments from Reviewable

tallclair · 2017-11-27T23:30:03Z

Review status: all files reviewed at latest revision, 37 unresolved discussions, some commit checks failed.

docs/concepts/policy/pod-security-policy.md, line 154 at r4 (raw file):

Previously, aasmall (Aaron Small) wrote…

Otherwise, the first valid policy in alphabetical order is used.
I'd rather the docs not specify and guaranteed ordering after non-altering policies. It's unlikely "alphabetical" will last long and I'd hate for people to take dependency. Better, I think, to state that it is not deterministic.

This fix was explicitly made to make it deterministic (it used to actually be non-deterministc, which broke things). I would say that at this point the alpbabetical ordering is a part of the API, and won't change (unless the API version changes too). We may add explicit priorities in the future that would override alphabetic, but I think alphabetic would still be the tie-breaker.

Comments from Reviewable

aasmall · 2017-11-28T00:16:13Z

Review status: all files reviewed at latest revision, 37 unresolved discussions, some commit checks failed.

docs/concepts/policy/pod-security-policy.md, line 154 at r4 (raw file):

Previously, tallclair (Tim Allclair (St. Clair)) wrote…

This fix was explicitly made to make it deterministic (it used to actually be non-deterministc, which broke things). I would say that at this point the alpbabetical ordering is a part of the API, and won't change (unless the API version changes too). We may add explicit priorities in the future that would override alphabetic, but I think alphabetic would still be the tie-breaker.

OK

Comments from Reviewable

php-coder · 2017-11-28T16:07:42Z

docs/concepts/policy/pod-security-policy.md

+    - name:  pause
+      image: gcr.io/google-containers/pause
+EOF
+Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: no providers available to validate pod request


BTW the error message has been changed:
s/no providers available to validate pod request/unable to validate against any pod security policy: []/

tallclair · 2017-12-01T23:44:52Z

Squashed & rebased.

tammersaleh · 2019-01-17T22:21:43Z

docs/concepts/policy/pod-security-policy.md


-PodSecurityPolicy authorization uses the union of all policies available to the
-user creating the pod and
-[the service account specified on the pod](/docs/tasks/configure-pod-container/configure-service-account/).


I feel like this information is very useful, and the subtlety of how this works was lost in this rewrite. Can we add it back in somehow?

tammersaleh · 2019-01-17T22:21:55Z

docs/concepts/policy/pod-security-policy.md

-For pods created on behalf of a user, in most cases by Controller Manager,
-access should be given to the service account specified on the pod spec
-template. Examples of resources that create pods on behalf of a user are
-Deployments, ReplicaSets, etc.


I feel like this information is very useful, and the subtlety of how this works was lost in this rewrite. Can we add it back in somehow?

@tammersaleh I think this is covered by the second paragraph under authorizing policies. Do you disagree?

@tallclair Reading through that again, I want to say it's sufficient. But I'd read that document a few times as I was figuring this stuff out, and still somehow missed it. I'm happy to chalk this up to just inattention on my part.

tallclair added Needs Docs Review labels Nov 20, 2017

tallclair assigned pweil- Nov 20, 2017

k8s-ci-robot requested a review from liggitt November 20, 2017 01:57

k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Nov 20, 2017

tallclair force-pushed the psp-docs branch from 9f552fd to e7a92b4 Compare November 20, 2017 02:06

tengqm reviewed Nov 20, 2017

View reviewed changes

tallclair commented Nov 20, 2017

View reviewed changes

tengqm reviewed Nov 21, 2017

View reviewed changes

php-coder reviewed Nov 22, 2017

View reviewed changes

liggitt reviewed Nov 23, 2017

View reviewed changes

liggitt mentioned this pull request Nov 23, 2017

podSecurityPolicy missing documentation for creating pod-creating objects kubernetes/kubernetes#49024

Closed

php-coder mentioned this pull request Nov 23, 2017

Allow Pod Security Policy to manage access to the Flexvolumes kubernetes/kubernetes#53179

Merged

pweil- reviewed Nov 27, 2017

View reviewed changes

tallclair commented Nov 27, 2017

View reviewed changes

pweil- approved these changes Nov 27, 2017

View reviewed changes

wanghaoran1988 mentioned this pull request Nov 28, 2017

New fields in Pod Security Policy not documented #6447

Closed

php-coder reviewed Nov 28, 2017

View reviewed changes

steveperry-53 added Tech Review: Open Issues and removed Needs Tech Review labels Nov 29, 2017

Rewrite PodSecurityPolicy guide

5d39cfe

tallclair force-pushed the psp-docs branch from 6b9c60b to 5d39cfe Compare December 1, 2017 23:44

tengqm merged commit f7543a3 into kubernetes:master Dec 2, 2017

chenopis mentioned this pull request Dec 15, 2017

add back example-psp.yaml #6683

Closed

php-coder mentioned this pull request Mar 6, 2018

pod-security-policy.md: minor fix #7659

Merged

tammersaleh reviewed Jan 17, 2019

View reviewed changes


		### FSGroup
		Once a PodSecurityPolicy resource has been created, it does nothing. In order to


		{% include code.html language="yaml" file="example-psp.yaml" ghlink="/docs/concepts/policy/example-psp.yaml" %}

		And create it with the standard `kubectl` command:


		Now, as the unprivileged user, try to create a simple pod:

		```

		@@ -125,141 +399,153 @@ to the volume sources that are defined when creating a volume:
		The recommended minimum set of allowed volumes for new PSPs are
		configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.


		### Privilege Escalation

		These options control the `AllowPrivilegeEscalation` container option. This bool

Rewrite PodSecurityPolicy guide #6378

Rewrite PodSecurityPolicy guide #6378

Conversation

tallclair commented Nov 20, 2017 • edited by k8s-reviewable Loading

k8s-ci-robot commented Nov 20, 2017

k8sio-netlify-preview-bot commented Nov 20, 2017 • edited Loading

liggitt commented Nov 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tallclair left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

php-coder commented Nov 22, 2017 • edited Loading

php-coder commented Nov 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

php-coder Nov 22, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tallclair commented Nov 20, 2017 •

edited by k8s-reviewable

Loading

k8sio-netlify-preview-bot commented Nov 20, 2017 •

edited

Loading

php-coder commented Nov 22, 2017 •

edited

Loading

php-coder Nov 22, 2017 •

edited

Loading