From a1e774fd091f1c9540653ece3feb4c906437f1fe Mon Sep 17 00:00:00 2001 From: Kohei Toyoda Date: Fri, 10 May 2019 10:15:58 +0900 Subject: [PATCH] fix orders of yaml for access-authn-authz (#14195) --- .../admission-controllers.md | 10 +++++----- .../docs/reference/access-authn-authz/rbac.md | 20 +++++++++---------- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index a870744994..873475c07b 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/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 diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 8f6ad335f6..2dce36c9b1 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/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: