fix orders of yaml for access-authn-authz (#14195)

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -173,8 +173,8 @@ event requests. The cluster admin can specify event rate limits by:
    server's command line flag `--admission-control-config-file`:
 
 ```yaml
-kind: AdmissionConfiguration
 apiVersion: apiserver.k8s.io/v1alpha1
+kind: AdmissionConfiguration
 plugins:
 - name: EventRateLimit
   path: eventconfig.yaml
@@ -192,8 +192,8 @@ There are four types of limits that can be specified in the configuration:
 Below is a sample `eventconfig.yaml` for such a configuration:
 
 ```yaml
-kind: Configuration
 apiVersion: eventratelimit.admission.k8s.io/v1alpha1
+kind: Configuration
 limits:
 - type: Namespace
   qps: 50
@@ -241,8 +241,8 @@ imagePolicy:
 Reference the ImagePolicyWebhook configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:
 
 ```yaml
-kind: AdmissionConfiguration
 apiVersion: apiserver.k8s.io/v1alpha1
+kind: AdmissionConfiguration
 plugins:
 - name: ImagePolicyWebhook
   path: imagepolicyconfig.yaml
@@ -481,8 +481,8 @@ podNodeSelectorPluginConfig:
 Reference the `PodNodeSelector` configuration file from the file provided to the API server's command line flag `--admission-control-config-file`:
 
 ```yaml
-kind: AdmissionConfiguration
 apiVersion: apiserver.k8s.io/v1alpha1
+kind: AdmissionConfiguration
 plugins:
 - name: PodNodeSelector
   path: podnodeselector.yaml
@@ -533,8 +533,8 @@ controller is recommended, too. This admission controller prevents resizing of a
 For example: all `PersistentVolumeClaim`s created from the following `StorageClass` support volume expansion:
 
 ```yaml
-kind: StorageClass
 apiVersion: storage.k8s.io/v1
+kind: StorageClass
 metadata:
   name: gluster-vol-default
 provisioner: kubernetes.io/glusterfs

content/en/docs/reference/access-authn-authz/rbac.md

@@ -40,8 +40,8 @@ A `Role` can only be used to grant access to resources within a single namespace
 Here's an example `Role` in the "default" namespace that can be used to grant read access to pods:
 
 ```yaml
-kind: Role
 apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
 metadata:
   namespace: default
   name: pod-reader
@@ -62,8 +62,8 @@ The following `ClusterRole` can be used to grant read access to secrets in any p
 or across all namespaces (depending on how it is [bound](#rolebinding-and-clusterrolebinding)):
 
 ```yaml
-kind: ClusterRole
 apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
 metadata:
   # "namespace" omitted since ClusterRoles are not namespaced
   name: secret-reader
@@ -86,9 +86,9 @@ This allows "jane" to read pods in the "default" namespace.
 `roleRef` is how you will actually create the binding.  The `kind` will be either `Role` or `ClusterRole`, and the `name` will reference the name of the specific `Role` or `ClusterRole` you want. In the example below, this RoleBinding is using `roleRef` to bind the user "jane" to the `Role` created above named `pod-reader`.
 
 ```yaml
+apiVersion: rbac.authorization.k8s.io/v1
 # This role binding allows "jane" to read pods in the "default" namespace.
 kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: read-pods
   namespace: default
@@ -112,9 +112,9 @@ For instance, even though the following `RoleBinding` refers to a `ClusterRole`,
 namespace (the namespace of the `RoleBinding`).
 
 ```yaml
+apiVersion: rbac.authorization.k8s.io/v1
 # This role binding allows "dave" to read secrets in the "development" namespace.
 kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: read-secrets
   namespace: development # This only grants permissions within the "development" namespace.
@@ -133,9 +133,9 @@ namespaces. The following `ClusterRoleBinding` allows any user in the group "man
 secrets in any namespace.
 
 ```yaml
+apiVersion: rbac.authorization.k8s.io/v1
 # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
 kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: read-secrets-global
 subjects:
@@ -181,8 +181,8 @@ this in an RBAC role, use a slash to delimit the resource and subresource. To al
 to read both pods and pod logs, you would write:
 
 ```yaml
-kind: Role
 apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
 metadata:
   namespace: default
   name: pod-and-pod-logs-reader
@@ -198,8 +198,8 @@ to individual instances of a resource. To restrict a subject to only "get" and "
 configmap, you would write:
 
 ```yaml
-kind: Role
 apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
 metadata:
   namespace: default
   name: configmap-updater
@@ -222,8 +222,8 @@ permissions of aggregated ClusterRoles are controller-managed, and filled in by
 ClusterRole that matches the provided label selector. An example aggregated ClusterRole:
 
 ```yaml
-kind: ClusterRole
 apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
 metadata:
   name: monitoring
 aggregationRule:
@@ -238,8 +238,8 @@ rules can be added to the "monitoring" ClusterRole by creating another ClusterRo
 `rbac.example.com/aggregate-to-monitoring: true`.
 
 ```yaml
-kind: ClusterRole
 apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
 metadata:
   name: monitoring-endpoints
   labels:
@@ -259,8 +259,8 @@ For example, the following ClusterRoles let the "admin" and "edit" default roles
 "CronTabs" and the "view" role perform read-only actions on the resource.
 
 ```yaml
-kind: ClusterRole
 apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
 metadata:
   name: aggregate-cron-tabs-edit
   labels: