Use PSP from policy API group

docs/admin/authorization/index.md

@@ -67,7 +67,7 @@ DELETE    | delete (for individual resources), deletecollection (for collections
 
 Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
 
-* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `extensions` API group.
+* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `policy` API group.
 * [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization 
 of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
 * [Authentication](/docs/admin/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.

docs/concepts/policy/example-psp.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: policy/v1beta1
 kind: PodSecurityPolicy
 metadata:
   name: example

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

@@ -49,7 +49,7 @@ controller](/docs/admin/admission-controllers/#how-do-i-turn-on-an-admission-con
 but doing so without authorizing any policies **will prevent any pods from being
 created** in the cluster.
 
-Since the pod security policy API (`extensions/v1beta1/podsecuritypolicy`) is
+Since the pod security policy API (`policy/v1beta1/podsecuritypolicy`) is
 enabled independently of the admission controller, for existing clusters it is
 recommended that policies are added and authorized before enabling the admission
 controller.
@@ -84,7 +84,7 @@ apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: <role name>
 rules:
-- apiGroups: ['extensions']
+- apiGroups: ['policy']
   resources: ['podsecuritypolicies']
   verbs:     ['use']
   resourceNames:

docs/concepts/policy/privileged-psp.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: policy/v1beta1
 kind: PodSecurityPolicy
 metadata:
   name: privileged

docs/concepts/policy/restricted-psp.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: policy/v1beta1
 kind: PodSecurityPolicy
 metadata:
   name: restricted

docs/tutorials/clusters/apparmor.md

@@ -317,14 +317,13 @@ node with the required profile.
 ### Restricting profiles with the PodSecurityPolicy
 
 If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
-enable the PodSecurityPolicy, two flags must be set on the `apiserver`:
+enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:
 
 ```
 --admission-control=PodSecurityPolicy[,others...]
---runtime-config=extensions/v1beta1/podsecuritypolicy[,others...]
 ```
 
-With the extension enabled, the AppArmor options can be specified as annotations on the PodSecurityPolicy:
+The AppArmor options can be specified as annotations on the PodSecurityPolicy:
 
 ```yaml
 apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>