whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update with master content resolving merge conflicts

Browse Source
This commit is contained in:
MAKOSCAFEE
2019-06-19 19:10:18 +03:00
parent b42f019aae 42cbe1256e
commit 8781518d32
1439 changed files with 70927 additions and 43295 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/access-authn-authz/abac.md
+4
View File
@@ -8,6 +8,10 @@ title: Using ABAC Authorization
content_template: templates/concept
weight: 80
---
{{< note >}}
{{< feature-state state="deprecated" for_k8s_version="1.6" >}}
The ABAC Authorization feature has been considered deprecated from the Kubernetes 1.6 release.
{{< /note >}}
{{% capture overview %}}
Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together.
content/en/docs/reference/access-authn-authz/admission-controllers.md
+18 -31
View File
@@ -89,10 +89,10 @@ To see which admission plugins are enabled:
kube-apiserver -h | grep enable-admission-plugins
```
In 1.13, they are:
In 1.14, they are:
```shell
NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeClaimResize,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,Priority
NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota
```
## What does each admission controller do?
@@ -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
@@ -218,7 +218,7 @@ add these tolerations.
### ImagePolicyWebhook {#imagepolicywebhook}
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.
#### Configuration File Format
@@ -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
@@ -280,19 +280,19 @@ Note that webhook API objects are subject to the same versioning compatibility r
An example request body:
```json
{
{
"apiVersion":"imagepolicy.k8s.io/v1alpha1",
"kind":"ImageReview",
"spec":{
"containers":[
{
"spec":{
"containers":[
{
"image":"myrepo/myimage:v1"
},
{
{
"image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
}
],
"annotations":[
"annotations":[
"mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
],
"namespace":"mynamespace"
@@ -339,13 +339,6 @@ Examples of information you might put here are:
In any case, the annotations are provided by the user and are not validated by Kubernetes in any way. In the future, if an annotation is determined to be widely useful, it may be promoted to a named field of ImageReviewSpec.
### Initializers {#initializers} {{< feature-state for_k8s_version="v1.13" state="alpha" >}}
The admission controller determines the initializers of a resource based on the existing
`InitializerConfiguration`s. It sets the pending initializers by modifying the
metadata of the resource to be created.
For more information, please check [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/).
### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology}
This admission controller denies any pod that defines `AntiAffinity` topology key other than
@@ -481,8 +474,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
@@ -513,7 +506,7 @@ plugin configuration file as the node selector.
Conflicts result in rejection.
{{< note >}}
PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction
PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction
admission plugin, which allows preventing pods from running on specifically tainted nodes.
{{< /note >}}
@@ -533,8 +526,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
@@ -606,7 +599,7 @@ This admission controller will deny any pod that attempts to set certain escalat
This admission controller implements automation for [serviceAccounts](/docs/user-guide/service-accounts).
We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
### Storage Object in Use Protection
### StorageObjectInUseProtection
The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information.
@@ -629,18 +622,12 @@ versions 1.9 and later).
## Is there a recommended set of admission controllers to use?
Yes.
For Kubernetes version 1.10 and later, we recommend running the following set of admission controllers using the `--enable-admission-plugins` flag (**order doesn't matter**).
Yes. For Kubernetes version 1.10 and later, the recommended admission controllers are enabled by default (shown [here](/docs/reference/command-line-tools-reference/kube-apiserver/#options)), so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**).
{{< note >}}
`--admission-control` was deprecated in 1.10 and replaced with `--enable-admission-plugins`.
{{< /note >}}
```shell
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,Priority,ResourceQuota
```
For Kubernetes 1.9 and earlier, we recommend running the following set of admission controllers using the `--admission-control` flag (**order matters**).
* v1.9
content/en/docs/reference/access-authn-authz/rbac.md
+14 -17
View File
@@ -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
@@ -193,13 +193,12 @@ rules:
```
Resources can also be referred to by name for certain requests through the `resourceNames` list.
When specified, requests using the "get", "delete", "update", and "patch" verbs can be restricted
to individual instances of a resource. To restrict a subject to only "get" and "update" a single
configmap, you would write:
When specified, requests can be restricted to individual instances of a resource. To restrict a
subject to only "get" and "update" a single configmap, you would write:
```yaml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: configmap-updater
@@ -210,10 +209,8 @@ rules:
verbs: ["update", "get"]
```
Notably, if `resourceNames` are set, then the verb must not be list, watch, create, or deletecollection.
Because resource names are not present in the URL for create, list, watch, and deletecollection API requests,
those verbs would not be allowed by a rule with `resourceNames` set, since the `resourceNames` portion of the
rule would not match the request.
Note that `create` requests cannot be restricted by resourceName, as the object name is not known at
authorization time. The other exception is `deletecollection`.
### Aggregated ClusterRoles
@@ -222,8 +219,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 +235,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 +256,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:
content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+1 -1
View File
@@ -61,7 +61,7 @@ It acts synchronously to modify pods as they are created or updated. When this p
Starting from v1.13, you can migrate a service account volume to a projected volume when
the `BoundServiceAccountTokenVolume` feature gate is enabled.
The service account token will expire after 1 hour or the pod is deleted. See more details about [projected volume](docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection).
The service account token will expire after 1 hour or the pod is deleted. See more details about [projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
### Token Controller