Apply templates and fix dead links under "/docs/reference/access-authn-authz/" (#9202)
* fix double bullets in TOC and apply an tempalte. * fix url prefix * anchor link with lower strings * fix another url prefixpull/9206/head
makocchi
k8s-ci-robot
parent
91396cb44d
commit
203391835d
|
|
@ -7,11 +7,15 @@ reviewers:
|
|||
- janetkuo
|
||||
- thockin
|
||||
title: Using Admission Controllers
|
||||
content_template: templates/concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
This page provides an overview of Admission Controllers.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## What are they?
|
||||
|
||||
An admission controller is a piece of code that intercepts requests to the
|
||||
|
|
@ -79,11 +83,11 @@ kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...
|
|||
|
||||
## What does each admission controller do?
|
||||
|
||||
### AlwaysAdmit (DEPRECATED)
|
||||
### AlwaysAdmit (DEPRECATED) {#alwaysadmit}
|
||||
|
||||
Use this admission controller by itself to pass-through all requests. AlwaysAdmit is DEPRECATED as no real meaning.
|
||||
|
||||
### AlwaysPullImages
|
||||
### AlwaysPullImages {#alwayspullimages}
|
||||
|
||||
This admission controller modifies every new Pod to force the image pull policy to Always. This is useful in a
|
||||
multitenant cluster so that users can be assured that their private images can only be used by those
|
||||
|
|
@ -93,11 +97,11 @@ scheduled onto the right node), without any authorization check against the imag
|
|||
is enabled, images are always pulled prior to starting containers, which means valid credentials are
|
||||
required.
|
||||
|
||||
### AlwaysDeny (DEPRECATED)
|
||||
### AlwaysDeny (DEPRECATED) {#alwaysdeny}
|
||||
|
||||
Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning.
|
||||
|
||||
### DefaultStorageClass
|
||||
### DefaultStorageClass {#defaultstorageclass}
|
||||
|
||||
This admission controller observes creation of `PersistentVolumeClaim` objects that do not request any specific storage class
|
||||
and automatically adds a default storage class to them.
|
||||
|
|
@ -112,7 +116,7 @@ This admission controller ignores any `PersistentVolumeClaim` updates; it acts o
|
|||
See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentation about persistent volume claims and
|
||||
storage classes and how to mark a storage class as default.
|
||||
|
||||
### DefaultTolerationSeconds
|
||||
### DefaultTolerationSeconds {#defaulttolerationseconds}
|
||||
|
||||
This admission controller sets the default forgiveness toleration for pods to tolerate
|
||||
the taints `notready:NoExecute` and `unreachable:NoExecute` for 5 minutes,
|
||||
|
|
@ -120,7 +124,7 @@ if the pods don't already have toleration for taints
|
|||
`node.kubernetes.io/not-ready:NoExecute` or
|
||||
`node.alpha.kubernetes.io/unreachable:NoExecute`.
|
||||
|
||||
### DenyExecOnPrivileged (deprecated)
|
||||
### DenyExecOnPrivileged (deprecated) {#denyexeconprivileged}
|
||||
|
||||
This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.
|
||||
|
||||
|
|
@ -129,7 +133,7 @@ commands in those containers, we strongly encourage enabling this admission cont
|
|||
|
||||
This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec).
|
||||
|
||||
### DenyEscalatingExec
|
||||
### DenyEscalatingExec {#denyescalatingexec}
|
||||
|
||||
This admission controller will deny exec and attach commands to pods that run with escalated privileges that
|
||||
allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and
|
||||
|
|
@ -139,7 +143,7 @@ If your cluster supports containers that run with escalated privileges, and you
|
|||
restrict the ability of end-users to exec commands in those containers, we strongly encourage
|
||||
enabling this admission controller.
|
||||
|
||||
### EventRateLimit (alpha)
|
||||
### EventRateLimit (alpha) {#eventratelimit}
|
||||
|
||||
This admission controller mitigates the problem where the API server gets flooded by
|
||||
event requests. The cluster admin can specify event rate limits by:
|
||||
|
|
@ -183,7 +187,7 @@ limits:
|
|||
See the [EventRateLimit proposal](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md)
|
||||
for more details.
|
||||
|
||||
### ExtendedResourceToleration
|
||||
### ExtendedResourceToleration {#extendedresourcetoleration}
|
||||
|
||||
This plug-in facilitates creation of dedicated nodes with extended resources.
|
||||
If operators want to create dedicated nodes with extended resources (like GPUs, FPGAs etc.), they are expected to
|
||||
|
|
@ -192,7 +196,7 @@ name as the key. This admission controller, if enabled, automatically
|
|||
adds tolerations for such taints to pods requesting extended resources, so users don't have to manually
|
||||
add these tolerations.
|
||||
|
||||
### ImagePolicyWebhook
|
||||
### ImagePolicyWebhook {#imagepolicywebhook}
|
||||
|
||||
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.
|
||||
|
||||
|
|
@ -315,14 +319,14 @@ 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 (alpha)
|
||||
### Initializers (alpha) {#initializers}
|
||||
|
||||
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/admin/extensible-admission-controllers/).
|
||||
|
||||
### InitialResources (experimental)
|
||||
### InitialResources (experimental) {#initialresources}
|
||||
|
||||
This admission controller observes pod creation requests. If a container omits compute resource requests and limits,
|
||||
then the admission controller auto-populates a compute resource request based on historical usage of containers running the same image.
|
||||
|
|
@ -333,12 +337,12 @@ The annotations added contain the information on what compute resources were aut
|
|||
|
||||
See the [InitialResources proposal](https://git.k8s.io/community/contributors/design-proposals/autoscaling/initial-resources.md) for more details.
|
||||
|
||||
### LimitPodHardAntiAffinityTopology
|
||||
### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology}
|
||||
|
||||
This admission controller denies any pod that defines `AntiAffinity` topology key other than
|
||||
`kubernetes.io/hostname` in `requiredDuringSchedulingRequiredDuringExecution`.
|
||||
|
||||
### LimitRanger
|
||||
### LimitRanger {#limitranger}
|
||||
|
||||
This admission controller will observe the incoming request and ensure that it does not violate any of the constraints
|
||||
enumerated in the `LimitRange` object in a `Namespace`. If you are using `LimitRange` objects in
|
||||
|
|
@ -348,7 +352,7 @@ applies a 0.1 CPU requirement to all Pods in the `default` namespace.
|
|||
|
||||
See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/administer-cluster/memory-default-namespace/) for more details.
|
||||
|
||||
### MutatingAdmissionWebhook (beta in 1.9)
|
||||
### MutatingAdmissionWebhook (beta in 1.9) {#mutatingadmissionwebhook}
|
||||
|
||||
This admission controller calls any mutating webhooks which match the request. Matching
|
||||
webhooks are called in serial; each one may modify the object if it desires.
|
||||
|
|
@ -379,7 +383,7 @@ versions >= 1.9).
|
|||
is finalized, not all possible webhook behaviors will be guaranteed to be supported
|
||||
indefinitely.
|
||||
|
||||
### NamespaceAutoProvision
|
||||
### NamespaceAutoProvision {#namespaceautoprovision}
|
||||
|
||||
This admission controller examines all incoming requests on namespaced resources and checks
|
||||
if the referenced namespace does exist.
|
||||
|
|
@ -387,12 +391,12 @@ It creates a namespace if it cannot be found.
|
|||
This admission controller is useful in deployments that do not want to restrict creation of
|
||||
a namespace prior to its usage.
|
||||
|
||||
### NamespaceExists
|
||||
### NamespaceExists {#namespaceexists}
|
||||
|
||||
This admission controller checks all requests on namespaced resources other than `Namespace` itself.
|
||||
If the namespace referenced from a request doesn't exist, the request is rejected.
|
||||
|
||||
### NamespaceLifecycle
|
||||
### NamespaceLifecycle {#namespacelifecycle}
|
||||
|
||||
This admission controller enforces that a `Namespace` that is undergoing termination cannot have new objects created in it,
|
||||
and ensures that requests in a non-existent `Namespace` are rejected. This admission controller also prevents deletion of
|
||||
|
|
@ -401,14 +405,14 @@ three system reserved namespaces `default`, `kube-system`, `kube-public`.
|
|||
A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that
|
||||
namespace. In order to enforce integrity of that process, we strongly recommend running this admission controller.
|
||||
|
||||
### NodeRestriction
|
||||
### NodeRestriction {#noderestriction}
|
||||
|
||||
This admission controller limits the `Node` and `Pod` objects a kubelet can modify. In order to be limited by this admission controller,
|
||||
kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:<nodeName>`.
|
||||
Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node.
|
||||
Future versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly.
|
||||
|
||||
### OwnerReferencesPermissionEnforcement
|
||||
### OwnerReferencesPermissionEnforcement {#ownerreferencespermissionenforcement}
|
||||
|
||||
This admission controller protects the access to the `metadata.ownerReferences` of an object
|
||||
so that only users with "delete" permission to the object can change it.
|
||||
|
|
@ -416,7 +420,7 @@ This admission controller also protects the access to `metadata.ownerReferences[
|
|||
of an object, so that only users with "update" permission to the `finalizers`
|
||||
subresource of the referenced *owner* can change it.
|
||||
|
||||
### PersistentVolumeLabel (DEPRECATED)
|
||||
### PersistentVolumeLabel (DEPRECATED) {#persistentvolumelabel}
|
||||
|
||||
This admission controller automatically attaches region or zone labels to PersistentVolumes
|
||||
as defined by the cloud provider (for example, GCE or AWS).
|
||||
|
|
@ -426,7 +430,7 @@ If the admission controller doesn't support automatic labelling your PersistentV
|
|||
may need to add the labels manually to prevent pods from mounting volumes from
|
||||
a different zone. PersistentVolumeLabel is DEPRECATED and labeling persistent volumes has been taken over by [cloud controller manager](/docs/tasks/administer-cluster/running-cloud-controller/).
|
||||
|
||||
### PodNodeSelector
|
||||
### PodNodeSelector {#podnodeselector}
|
||||
|
||||
This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.
|
||||
|
||||
|
|
@ -482,7 +486,7 @@ This admission controller has the following behavior:
|
|||
admission plugin, which allows preventing pods from running on specifically tainted nodes.
|
||||
{{< /note >}}
|
||||
|
||||
### PersistentVolumeClaimResize
|
||||
### PersistentVolumeClaimResize {#persistentvolumeclaimresize}
|
||||
|
||||
This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests.
|
||||
|
||||
|
|
@ -511,16 +515,16 @@ parameters:
|
|||
allowVolumeExpansion: true
|
||||
```
|
||||
|
||||
For more information about persistent volume claims, see ["PersistentVolumeClaims"](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
|
||||
For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
|
||||
|
||||
### PodPreset
|
||||
### PodPreset {#podpreset}
|
||||
|
||||
This admission controller injects a pod with the fields specified in a matching PodPreset.
|
||||
See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and
|
||||
[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset)
|
||||
for more information.
|
||||
|
||||
### PodSecurityPolicy
|
||||
### PodSecurityPolicy {#podsecuritypolicy}
|
||||
|
||||
This admission controller acts on creation and modification of the pod and determines if it should be admitted
|
||||
based on the requested security context and the available Pod Security Policies.
|
||||
|
|
@ -531,7 +535,7 @@ extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
|
|||
See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
|
||||
for more information.
|
||||
|
||||
### PodTolerationRestriction
|
||||
### PodTolerationRestriction {#podtolerationrestriction}
|
||||
|
||||
This admission controller first verifies any conflict between a pod's tolerations and its
|
||||
namespace's tolerations, and rejects the pod request if there is a conflict.
|
||||
|
|
@ -549,11 +553,11 @@ Tolerations to a namespace are assigned via the
|
|||
`scheduler.alpha.kubernetes.io/tolerationsWhitelist`
|
||||
annotation keys.
|
||||
|
||||
### Priority
|
||||
### Priority {#priority}
|
||||
|
||||
The priority admission controller uses the `priorityClassName` field and populates the integer value of the priority. If the priority class is not found, the Pod is rejected.
|
||||
|
||||
### ResourceQuota
|
||||
### ResourceQuota {#resourcequota}
|
||||
|
||||
This admission controller will observe the incoming request and ensure that it does not violate any of the constraints
|
||||
enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota`
|
||||
|
|
@ -562,20 +566,20 @@ objects in your Kubernetes deployment, you MUST use this admission controller to
|
|||
See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
|
||||
|
||||
|
||||
### SecurityContextDeny
|
||||
### SecurityContextDeny {#securitycontextdeny}
|
||||
|
||||
This admission controller will deny any pod that attempts to set certain escalating [SecurityContext](/docs/tasks/configure-pod-container/security-context/) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/concepts/policy/pod-security-policy/) to restrict the set of values a security context can take.
|
||||
|
||||
### ServiceAccount
|
||||
### ServiceAccount {#serviceaccount}
|
||||
|
||||
This admission controller implements automation for [serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/).
|
||||
We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects.
|
||||
|
||||
### Storage Object in Use Protection (beta)
|
||||
### StorageObjectInUseProtection (beta) {#storageobjectinuseprotection}
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
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.
|
||||
|
||||
### ValidatingAdmissionWebhook (alpha in 1.8; beta in 1.9)
|
||||
### ValidatingAdmissionWebhook (alpha in 1.8; beta in 1.9) {#validatingadmissionwebhook}
|
||||
|
||||
This admission controller calls any validating webhooks which match the request. Matching
|
||||
webhooks are called in parallel; if any of them rejects the request, the request
|
||||
|
|
@ -596,15 +600,17 @@ versions 1.9 and later).
|
|||
|
||||
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**).
|
||||
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**).
|
||||
|
||||
Note: ```--admission-control``` was deprecated in 1.10 and replaced with ```--enable-admission-plugins```.
|
||||
{{< note >}}
|
||||
**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,ResourceQuota
|
||||
```
|
||||
|
||||
For Kubernetes 1.9 and earlier, we recommend running the following set of admission controllers using the ```--admission-control``` flag (**order matters**).
|
||||
For Kubernetes 1.9 and earlier, we recommend running the following set of admission controllers using the `--admission-control` flag (**order matters**).
|
||||
|
||||
* v1.9
|
||||
|
||||
|
|
@ -644,3 +650,4 @@ admission controllers ran in the exact order specified.
|
|||
```shell
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,PersistentVolumeLabel,ResourceQuota
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -6,11 +6,15 @@ reviewers:
|
|||
- deads2k
|
||||
- liggitt
|
||||
title: Authenticating
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
This page provides an overview of authenticating.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Users in Kubernetes
|
||||
|
||||
All Kubernetes clusters have two categories of users: service accounts managed
|
||||
|
|
@ -90,12 +94,15 @@ The API server reads bearer tokens from a file when given the `--token-auth-file
|
|||
changed without restarting API server.
|
||||
|
||||
The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
|
||||
followed by optional group names. Note, if you have more than one group the column must be
|
||||
double quoted e.g.
|
||||
followed by optional group names.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you have more than one group the column must be double quoted e.g.
|
||||
|
||||
```conf
|
||||
token,user,uid,"group1,group2,group3"
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
#### Putting a Bearer Token in a Request
|
||||
|
||||
|
|
@ -182,9 +189,11 @@ mounted into pods at well-known locations, and allow in-cluster processes to
|
|||
talk to the API server. Accounts may be explicitly associated with pods using the
|
||||
`serviceAccountName` field of a `PodSpec`.
|
||||
|
||||
NOTE: `serviceAccountName` is usually omitted because this is done automatically.
|
||||
{{< note >}}
|
||||
**Note:** `serviceAccountName` is usually omitted because this is done automatically.
|
||||
{{< /note >}}
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: apps/v1 # this apiVersion is relevant as of Kubernetes 1.9
|
||||
kind: Deployment
|
||||
metadata:
|
||||
|
|
@ -236,7 +245,9 @@ metadata:
|
|||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
|
||||
Note: values are base64 encoded because secrets are always base64 encoded.
|
||||
{{< note >}}
|
||||
**Note:** Values are base64 encoded because secrets are always base64 encoded.
|
||||
{{< /note >}}
|
||||
|
||||
The signed JWT can be used as a bearer token to authenticate as the given service
|
||||
account. See [above](#putting-a-bearer-token-in-a-request) for how the token is included
|
||||
|
|
@ -393,8 +404,8 @@ Webhook authentication is a hook for verifying bearer tokens.
|
|||
* `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.
|
||||
|
||||
The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
file format. Within the file "users" refers to the API server webhook and
|
||||
"clusters" refers to the remote service. An example would be:
|
||||
file format. Within the file `users` refers to the API server webhook and
|
||||
`clusters` refers to the remote service. An example would be:
|
||||
|
||||
```yaml
|
||||
# clusters refers to the remote service.
|
||||
|
|
@ -506,7 +517,7 @@ For example, with this configuration:
|
|||
|
||||
this request:
|
||||
|
||||
```
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
X-Remote-User: fido
|
||||
X-Remote-Group: dogs
|
||||
|
|
@ -694,7 +705,7 @@ To authenticate against the API:
|
|||
|
||||
### Configuration
|
||||
|
||||
Credential plugins are configured through [`kubectl` config files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
Credential plugins are configured through [kubectl config files](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
as part of the user fields.
|
||||
|
||||
```yaml
|
||||
|
|
@ -818,3 +829,4 @@ is triggered each time the tool using the plugin is invoked.
|
|||
}
|
||||
}
|
||||
```
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ policies using the supported authorization modules.
|
|||
{{% capture body %}}
|
||||
In Kubernetes, you must be authenticated (logged in) before your request can be
|
||||
authorized (granted permission to access). For information about authentication,
|
||||
see [Accessing Control Overview](/docs/admin/accessing-the-api/).
|
||||
see [Accessing Control Overview](/docs/reference/access-authn-authz/controlling-access/).
|
||||
|
||||
Kubernetes expects attributes that are common to REST API requests. This means
|
||||
that Kubernetes authorization works with existing organization-wide or
|
||||
|
|
@ -44,10 +44,10 @@ Kubernetes reviews only the following API request attributes:
|
|||
|
||||
* **user** - The `user` string provided during authentication.
|
||||
* **group** - The list of group names to which the authenticated user belongs.
|
||||
* **"extra"** - A map of arbitrary string keys to string values, provided by the authentication layer.
|
||||
* **extra** - A map of arbitrary string keys to string values, provided by the authentication layer.
|
||||
* **API** - Indicates whether the request is for an API resource.
|
||||
* **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz`.
|
||||
* **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see **Determine the request verb** below.
|
||||
* **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see [Determine the request verb](/docs/reference/access-authn-authz/authorization/#determine-whether-a-request-is-allowed-or-denied) below.
|
||||
* **HTTP request verb** - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests.
|
||||
* **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
|
||||
* **Subresource** - The subresource that is being accessed (for resource requests only).
|
||||
|
|
@ -70,17 +70,17 @@ 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 `policy` API group.
|
||||
* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization
|
||||
* [RBAC](/docs/reference/access-authn-authz/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.
|
||||
* [Authentication](/docs/reference/access-authn-authz/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.
|
||||
|
||||
## Authorization Modules
|
||||
* **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/admin/authorization/node/).
|
||||
* **ABAC** - 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. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/admin/authorization/abac/).
|
||||
* **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/admin/authorization/rbac/)
|
||||
* When specified "RBAC" (Role-Based Access Control) uses the "rbac.authorization.k8s.io" API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
|
||||
* **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/reference/access-authn-authz/node/).
|
||||
* **ABAC** - 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. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/reference/access-authn-authz/abac/).
|
||||
* **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/reference/access-authn-authz/rbac/)
|
||||
* When specified RBAC (Role-Based Access Control) uses the `rbac.authorization.k8s.io` API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
|
||||
* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
|
||||
* **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/admin/authorization/webhook/).
|
||||
* **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/reference/access-authn-authz/webhook/).
|
||||
|
||||
#### Checking API Access
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ $ kubectl auth can-i create deployments --namespace prod
|
|||
no
|
||||
```
|
||||
|
||||
Administrators can combine this with ["user impersonation"](/docs/admin/authentication/#user-impersonation)
|
||||
Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation)
|
||||
to determine what action other users can perform.
|
||||
|
||||
```bash
|
||||
|
|
@ -159,14 +159,6 @@ The following flags can be used:
|
|||
You can choose more than one authorization module. Modules are checked in order
|
||||
so an earlier module has higher priority to allow or deny a request.
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/admin/accessing-the-api/).
|
||||
* To learn more about Admission Control, see [Using Admission Controllers](/docs/admin/admission-controllers/).
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
## Privilege escalation via pod creation
|
||||
|
||||
Users who have the ability to create pods in a namespace can potentially
|
||||
|
|
@ -183,3 +175,9 @@ maps in the namespace; and impersonate any service account in the namespace and
|
|||
take any action the account could take. This applies regardless of authorization
|
||||
mode.
|
||||
{{< /caution >}}
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
|
||||
* To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -2,19 +2,21 @@
|
|||
reviewers:
|
||||
- jbeda
|
||||
title: Authenticating with Bootstrap Tokens
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Overview
|
||||
|
||||
{{% capture overview %}}
|
||||
Bootstrap tokens are a simple bearer token that is meant to be used when
|
||||
creating new clusters or joining new nodes to an existing cluster. It was built
|
||||
to support [`kubeadm`](/docs/admin/kubeadm/), but can be used in other contexts
|
||||
to support [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), but can be used in other contexts
|
||||
for users that wish to start clusters without `kubeadm`. It is also built to
|
||||
work, via RBAC policy, with the [Kubelet TLS
|
||||
Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) system.
|
||||
Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Bootstrap Tokens Overview
|
||||
|
||||
Bootstrap Tokens are defined with a specific type
|
||||
(`bootstrap.kubernetes.io/token`) of secrets that lives in the `kube-system`
|
||||
|
|
@ -117,10 +119,10 @@ rejected when used for authentication and ignored during ConfigMap signing.
|
|||
The expiry value is encoded as an absolute UTC time using RFC3339. Enable the
|
||||
`tokencleaner` controller to automatically delete expired tokens.
|
||||
|
||||
## Token Management with `kubeadm`
|
||||
## Token Management with kubeadm
|
||||
|
||||
You can use the `kubeadm` tool to manage tokens on a running cluster. See the
|
||||
[`kubeadm token` docs](/docs/admin/kubeadm/#manage-tokens) for details.
|
||||
[kubeadm token docs](/docs/reference/setup-tools/kubeadm/kubeadm-token/) for details.
|
||||
|
||||
## ConfigMap Signing
|
||||
|
||||
|
|
@ -176,10 +178,13 @@ verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
|
|||
`07401b.f395accd246ae52d`) as the shared secret. Users _must_ verify that HS256
|
||||
is used.
|
||||
|
||||
WARNING: Any party with a bootstrapping token can create a valid signature for that
|
||||
{{< warning >}}
|
||||
**Warning:** Any party with a bootstrapping token can create a valid signature for that
|
||||
token. When using ConfigMap signing it's discouraged to share the same token with
|
||||
many clients, since a compromised client can potentially man-in-the middle another
|
||||
client relying on the signature to bootstrap TLS trust.
|
||||
{{< /warning >}}
|
||||
|
||||
Consult the [kubeadm security model](/docs/reference/generated/kubeadm/#security-model)
|
||||
section for more information.
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -4,9 +4,15 @@ reviewers:
|
|||
- erictune
|
||||
- lavalamp
|
||||
title: Controlling Access to the Kubernetes API
|
||||
content_template: templates/concept
|
||||
weight: 5
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
This page provides an overview of controlling access to the Kubernetes API.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
Users [access the API](/docs/tasks/access-application-cluster/access-cluster/) using `kubectl`,
|
||||
client libraries, or by making REST requests. Both human users and
|
||||
[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
|
||||
|
|
@ -52,7 +58,7 @@ is available to subsequent steps to use in their decisions. Some authenticators
|
|||
also provide the group memberships of the user, while other authenticators
|
||||
do not.
|
||||
|
||||
While Kubernetes uses "usernames" for access control decisions and in request logging,
|
||||
While Kubernetes uses `usernames` for access control decisions and in request logging,
|
||||
it does not have a `user` object nor does it store usernames or other information about
|
||||
users in its object store.
|
||||
|
||||
|
|
@ -156,4 +162,4 @@ When the cluster is created by `kube-up.sh`, on Google Compute Engine (GCE),
|
|||
and on several other cloud providers, the API server serves on port 443. On
|
||||
GCE, a firewall rule is configured on the project to allow external HTTPS
|
||||
access to the API. Other cluster setup methods vary.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -6,14 +6,12 @@ reviewers:
|
|||
- caesarxuchao
|
||||
- deads2k
|
||||
title: Dynamic Admission Control
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Overview
|
||||
|
||||
The [admission controllers documentation](/docs/admin/admission-controllers/)
|
||||
{{% capture overview %}}
|
||||
The [admission controllers documentation](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
introduces how to use standard, plugin-style admission controllers. However,
|
||||
plugin admission controllers are not flexible enough for all use cases, due to
|
||||
the following:
|
||||
|
|
@ -26,16 +24,18 @@ address these limitations. They allow admission controllers to be developed
|
|||
out-of-tree and configured at runtime.
|
||||
|
||||
This page describes how to use Admission Webhooks and Initializers.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Admission Webhooks
|
||||
|
||||
### What are admission webhooks?
|
||||
|
||||
Admission webhooks are HTTP callbacks that receive admission requests and do
|
||||
something with them. You can define two types of admission webhooks,
|
||||
[validating admission Webhook](/docs/admin/admission-controllers/#validatingadmissionwebhook-alpha-in-18-beta-in-19)
|
||||
[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)
|
||||
and
|
||||
[mutating admission webhook](/docs/admin/admission-controllers/#mutatingadmissionwebhook-beta-in-19).
|
||||
[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9).
|
||||
With validating admission Webhooks, you may reject requests to enforce custom
|
||||
admission policies. With mutating admission Webhooks, you may change requests to
|
||||
enforce custom defaults.
|
||||
|
|
@ -44,7 +44,7 @@ enforce custom defaults.
|
|||
|
||||
Admission webhooks are essentially part of the cluster control-plane. You should
|
||||
write and deploy them with great caution. Please read the [user
|
||||
guides](https://github.com/kubernetes/website/pull/6836/files)(WIP) for
|
||||
guides](/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server) for
|
||||
instructions if you intend to write/deploy production-grade admission webhooks.
|
||||
In the following, we describe how to quickly experiment with admission webhooks.
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ In the following, we describe how to quickly experiment with admission webhooks.
|
|||
|
||||
* Ensure that MutatingAdmissionWebhook and ValidatingAdmissionWebhook
|
||||
admission controllers are enabled.
|
||||
[Here](/docs/admin/admission-controllers.md#is-there-a-recommended-set-of-admission-controllers-to-use)
|
||||
[Here](/docs/reference/access-authn-authz/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use)
|
||||
is a recommended set of admission controllers to enable in general.
|
||||
|
||||
* Ensure that the admissionregistration.k8s.io/v1beta1 API is enabled.
|
||||
|
|
@ -119,8 +119,10 @@ webhooks:
|
|||
caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
|
||||
```
|
||||
|
||||
*Note*: When using `clientConfig.service`, the server cert must be valid for
|
||||
{{< note >}}
|
||||
**Note:** When using `clientConfig.service`, the server cert must be valid for
|
||||
`<svc_name>.<svc_namespace>.svc`.
|
||||
{{< /note >}}
|
||||
|
||||
When an apiserver receives a request that matches one of the `rules`, the
|
||||
apiserver sends an `admissionReview` request to webhook as specified in the
|
||||
|
|
@ -130,7 +132,7 @@ After you create the webhook configuration, the system will take a few seconds
|
|||
to honor the new configuration.
|
||||
|
||||
{{< note >}}
|
||||
**Note** When the webhook plugin is deployed into the Kubernetes cluster as a
|
||||
**Note:** When the webhook plugin is deployed into the Kubernetes cluster as a
|
||||
service, it has to expose its service on the 443 port. The communication
|
||||
between the API server and the webhook service may fail if a different port
|
||||
is used.
|
||||
|
|
@ -220,13 +222,15 @@ and are not visible in the API unless specifically requested by using the query
|
|||
### When to use initializers?
|
||||
|
||||
Initializers are useful for admins to force policies (e.g., the
|
||||
[AlwaysPullImages](/docs/admin/admission-controllers/#alwayspullimages)
|
||||
[AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)
|
||||
admission controller), or to inject defaults (e.g., the
|
||||
[DefaultStorageClass](/docs/admin/admission-controllers/#defaultstorageclass)
|
||||
[DefaultStorageClass](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
|
||||
admission controller), etc.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If your use case does not involve mutating objects, consider using
|
||||
external admission webhooks, as they have better performance.
|
||||
{{< /note >}}
|
||||
|
||||
### How are initializers triggered?
|
||||
|
||||
|
|
@ -304,3 +308,4 @@ the pods will be stuck in an uninitialized state.
|
|||
|
||||
Make sure that all expansions of the `<apiGroup, apiVersions, resources>` tuple
|
||||
in a `rule` are valid. If they are not, separate them in different `rules`.
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -5,13 +5,15 @@ reviewers:
|
|||
- liggitt
|
||||
- ericchiang
|
||||
title: Using Node Authorization
|
||||
content_template: templates/concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture overview %}}
|
||||
Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Overview
|
||||
|
||||
The Node authorizer allows a kubelet to perform API operations. This includes:
|
||||
|
|
@ -41,11 +43,11 @@ have the minimal set of permissions required to operate correctly.
|
|||
In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as
|
||||
being in the `system:nodes` group, with a username of `system:node:<nodeName>`.
|
||||
This group and user name format match the identity created for each kubelet as part of
|
||||
[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/).
|
||||
[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
|
||||
|
||||
To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
|
||||
|
||||
To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/admin/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
|
||||
To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
|
||||
|
||||
## Migration considerations
|
||||
|
||||
|
|
@ -68,7 +70,7 @@ since the default node identifier implementation would not consider that a node
|
|||
|
||||
### Upgrades from previous versions using RBAC
|
||||
|
||||
Upgraded pre-1.7 clusters using [RBAC](/docs/admin/authorization/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
|
||||
Upgraded pre-1.7 clusters using [RBAC](/docs/reference/access-authn-authz/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
|
||||
|
||||
If a cluster admin wishes to start using the `Node` authorizer and `NodeRestriction` admission plugin
|
||||
to limit node access to the API, that can be done non-disruptively:
|
||||
|
|
@ -80,7 +82,7 @@ to limit node access to the API, that can be done non-disruptively:
|
|||
|
||||
### RBAC Node Permissions
|
||||
|
||||
In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/admin/authorization/rbac/).
|
||||
In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/).
|
||||
|
||||
In 1.7, the automatic binding of the `system:nodes` group to the `system:node` role is deprecated
|
||||
because the node authorizer accomplishes the same purpose with the benefit of additional restrictions
|
||||
|
|
@ -91,3 +93,4 @@ In 1.8, the binding will not be created at all.
|
|||
|
||||
When using RBAC, the `system:node` cluster role will continue to be created,
|
||||
for compatibility with deployment methods that bind other users or groups to that role.
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -4,12 +4,16 @@ reviewers:
|
|||
- deads2k
|
||||
- liggitt
|
||||
title: Using RBAC Authorization
|
||||
content_template: templates/concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise.
|
||||
{{% /capture %}}
|
||||
|
||||
Role-Based Access Control ("RBAC") uses the "rbac.authorization.k8s.io" API group
|
||||
{{% capture body %}}
|
||||
`RBAC` uses the `rbac.authorization.k8s.io` API group
|
||||
to drive authorization decisions, allowing admins to dynamically configure policies
|
||||
through the Kubernetes API.
|
||||
|
||||
|
|
@ -150,7 +154,7 @@ Most resources are represented by a string representation of their name, such as
|
|||
appears in the URL for the relevant API endpoint. However, some Kubernetes APIs involve a
|
||||
"subresource", such as the logs for a pod. The URL for the pods logs endpoint is:
|
||||
|
||||
```
|
||||
```http
|
||||
GET /api/v1/namespaces/{namespace}/pods/{name}/log
|
||||
```
|
||||
|
||||
|
|
@ -332,7 +336,7 @@ Subjects can be groups, users or service accounts.
|
|||
Users are represented by strings. These can be plain usernames, like
|
||||
"alice", email-style names, like "bob@example.com", or numeric IDs
|
||||
represented as a string. It is up to the Kubernetes admin to configure
|
||||
the [authentication modules](/docs/admin/authentication/) to produce
|
||||
the [authentication modules](/docs/reference/access-authn-authz/authentication/) to produce
|
||||
usernames in the desired format. The RBAC authorization system does
|
||||
not require any particular format. However, the prefix `system:` is
|
||||
reserved for Kubernetes system use, and so the admin should ensure
|
||||
|
|
@ -721,11 +725,15 @@ Grants a `Role` or `ClusterRole` within a specific namespace. Examples:
|
|||
|
||||
* Grant the `admin` `ClusterRole` to a user named "bob" in the namespace "acme":
|
||||
|
||||
`kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme`
|
||||
```
|
||||
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
|
||||
```
|
||||
|
||||
* Grant the `view` `ClusterRole` to a service account named "myapp" in the namespace "acme":
|
||||
|
||||
`kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme`
|
||||
```
|
||||
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
|
||||
```
|
||||
|
||||
### `kubectl create clusterrolebinding`
|
||||
|
||||
|
|
@ -733,22 +741,28 @@ Grants a `ClusterRole` across the entire cluster, including all namespaces. Exam
|
|||
|
||||
* Grant the `cluster-admin` `ClusterRole` to a user named "root" across the entire cluster:
|
||||
|
||||
`kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root`
|
||||
```
|
||||
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
|
||||
```
|
||||
|
||||
* Grant the `system:node` `ClusterRole` to a user named "kubelet" across the entire cluster:
|
||||
|
||||
`kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet`
|
||||
```
|
||||
kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet
|
||||
```
|
||||
|
||||
* Grant the `view` `ClusterRole` to a service account named "myapp" in the namespace "acme" across the entire cluster:
|
||||
|
||||
`kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp`
|
||||
```
|
||||
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
|
||||
```
|
||||
|
||||
See the CLI help for detailed usage.
|
||||
|
||||
## Service Account Permissions
|
||||
|
||||
Default RBAC policies grant scoped permissions to control-plane components, nodes,
|
||||
and controllers, but grant *no permissions* to service accounts outside the "kube-system" namespace
|
||||
and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
|
||||
(beyond discovery permissions given to all authenticated users).
|
||||
|
||||
This allows you to grant particular roles to particular service accounts as needed.
|
||||
|
|
@ -775,7 +789,7 @@ In order from most secure to least secure, the approaches are:
|
|||
|
||||
If an application does not specify a `serviceAccountName`, it uses the "default" service account.
|
||||
|
||||
{{< note >}}**NOTE:** Permissions given to the "default" service
|
||||
{{< note >}}**Note:** Permissions given to the "default" service
|
||||
account are available to any pod in the namespace that does not
|
||||
specify a `serviceAccountName`.{{< /note >}}
|
||||
|
||||
|
|
@ -788,10 +802,10 @@ In order from most secure to least secure, the approaches are:
|
|||
--namespace=my-namespace
|
||||
```
|
||||
|
||||
Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the "kube-system" namespace.
|
||||
To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the "kube-system" namespace.
|
||||
Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the `kube-system` namespace.
|
||||
To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the `kube-system` namespace.
|
||||
|
||||
{{< note >}}**NOTE:** Enabling this means the "kube-system"
|
||||
{{< note >}}**Note:** Enabling this means the `kube-system`
|
||||
namespace contains secrets that grant super-user access to the
|
||||
API.{{< /note >}}
|
||||
|
||||
|
|
@ -831,7 +845,7 @@ In order from most secure to least secure, the approaches are:
|
|||
|
||||
If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
|
||||
|
||||
{{< warning >}}**WARNING:** This allows any user with read access
|
||||
{{< warning >}}**Warning:** This allows any user with read access
|
||||
to secrets or the ability to create a pod to access super-user
|
||||
credentials.{{< /warning >}}
|
||||
|
||||
|
|
@ -847,7 +861,7 @@ Prior to Kubernetes 1.6, many deployments used very permissive ABAC policies,
|
|||
including granting full API access to all service accounts.
|
||||
|
||||
Default RBAC policies grant scoped permissions to control-plane components, nodes,
|
||||
and controllers, but grant *no permissions* to service accounts outside the "kube-system" namespace
|
||||
and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace
|
||||
(beyond discovery permissions given to all authenticated users).
|
||||
|
||||
While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions.
|
||||
|
|
@ -856,7 +870,7 @@ Here are two approaches for managing this transition:
|
|||
### Parallel Authorizers
|
||||
|
||||
Run both the RBAC and ABAC authorizers, and specify a policy file that contains
|
||||
[the legacy ABAC policy](/docs/admin/authorization/abac#policy-file-format):
|
||||
[the legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format):
|
||||
|
||||
```
|
||||
--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json
|
||||
|
|
@ -876,11 +890,10 @@ in the server logs, you can remove the ABAC authorizer.
|
|||
You can replicate a permissive policy using RBAC role bindings.
|
||||
|
||||
{{< warning >}}
|
||||
**WARNING:** The following policy allows **ALL** service accounts to act as cluster administrators.
|
||||
**Warning:** The following policy allows **ALL** service accounts to act as cluster administrators.
|
||||
Any application running in a container receives service account credentials automatically,
|
||||
and could perform any action against the API, including viewing secrets and modifying permissions.
|
||||
This is not a recommended policy.
|
||||
{{< /warning >}}
|
||||
|
||||
```
|
||||
kubectl create clusterrolebinding permissive-binding \
|
||||
|
|
@ -889,3 +902,6 @@ kubectl create clusterrolebinding permissive-binding \
|
|||
--user=kubelet \
|
||||
--group=system:serviceaccounts
|
||||
```
|
||||
{{< /warning >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -5,15 +5,19 @@ reviewers:
|
|||
- lavalamp
|
||||
- liggitt
|
||||
title: Managing Service Accounts
|
||||
content_template: templates/concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
*This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
the [User Guide to Service Accounts](/docs/user-guide/service-accounts).*
|
||||
{{% capture overview %}}
|
||||
This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
the [User Guide to Service Accounts](/docs/user-guide/service-accounts).
|
||||
|
||||
*Support for authorization and user accounts is planned but incomplete. Sometimes
|
||||
incomplete features are referred to in order to better describe service accounts.*
|
||||
Support for authorization and user accounts is planned but incomplete. Sometimes
|
||||
incomplete features are referred to in order to better describe service accounts.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## User accounts vs service accounts
|
||||
|
||||
Kubernetes distinguishes between the concept of a user account and a service account
|
||||
|
|
@ -45,16 +49,15 @@ Three separate components cooperate to implement the automation around service a
|
|||
### Service Account Admission Controller
|
||||
|
||||
The modification of pods is implemented via a plugin
|
||||
called an [Admission Controller](/docs/admin/admission-controllers). It is part of the apiserver.
|
||||
called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/). It is part of the apiserver.
|
||||
It acts synchronously to modify pods as they are created or updated. When this plugin is active
|
||||
(and it is by default on most distributions), then it does the following when a pod is created or modified:
|
||||
|
||||
1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`.
|
||||
2. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it.
|
||||
4. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the
|
||||
`ServiceAccount` are added to the pod.
|
||||
5. It adds a `volume` to the pod which contains a token for API access.
|
||||
6. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`.
|
||||
1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it.
|
||||
1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod.
|
||||
1. It adds a `volume` to the pod which contains a token for API access.
|
||||
1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`.
|
||||
|
||||
### Token Controller
|
||||
|
||||
|
|
@ -108,3 +111,4 @@ kubectl delete secret mysecretname
|
|||
|
||||
Service Account Controller manages ServiceAccount inside namespaces, and ensures
|
||||
a ServiceAccount named "default" exists in every active namespace.
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue