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

resolving conflicts

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-06-16 17:08:15 -04:00
parent 3ad8c45b0b 13ca92d745
commit 7ddedb00a0
1497 changed files with 24525 additions and 14364 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/access-authn-authz/abac.md
+5 -5
View File
@@ -5,15 +5,15 @@ reviewers:
- deads2k
- liggitt
title: Using ABAC Authorization
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- 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.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Policy File Format
To enable `ABAC` mode, specify `--authorization-policy-file=SOME_FILENAME` and `--authorization-mode=ABAC` on startup.
@@ -152,5 +152,5 @@ privilege to the API using ABAC, you would add this line to your policy file:
The apiserver will need to be restarted to pickup the new policy lines.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/admission-controllers.md
+12 -10
View File
@@ -7,15 +7,15 @@ reviewers:
- janetkuo
- thockin
title: Using Admission Controllers
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of Admission Controllers.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## What are they?
An admission controller is a piece of code that intercepts requests to the
@@ -32,6 +32,8 @@ which are configured in the API.
Admission controllers may be "validating", "mutating", or both. Mutating
controllers may modify the objects they admit; validating controllers may not.
Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
The admission control process proceeds in two phases. In the first phase,
mutating admission controllers are run. In the second phase, validating
admission controllers are run. Note again that some of the controllers are
@@ -610,7 +612,7 @@ node selector.
2. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector`
plugin configuration file as the node selector.
3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection.
4. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file.
4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the plugin configuration file.
Conflicts result in rejection.
{{< note >}}
@@ -672,15 +674,15 @@ for more information.
The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace.
It rejects the pod request if there is a conflict.
It then merges the tolerations annotated on the namespace into the tolerations of the pod.
The resulting tolerations are checked against a whitelist of tolerations annotated to the namespace.
The resulting tolerations are checked against a list of allowed tolerations annotated to the namespace.
If the check succeeds, the pod request is admitted otherwise it is rejected.
If the namespace of the pod does not have any associated default tolerations or a whitelist of
tolerations annotated, the cluster-level default tolerations or cluster-level whitelist of tolerations are used
If the namespace of the pod does not have any associated default tolerations or allowed
tolerations annotated, the cluster-level default tolerations or cluster-level list of allowed tolerations are used
instead if they are specified.
Tolerations to a namespace are assigned via the `scheduler.alpha.kubernetes.io/defaultTolerations` annotation key.
The whitelist can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
The list of allowed tolerations can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
Example for namespace annotations:
@@ -773,4 +775,4 @@ in the mutating phase.
For earlier versions, there was no concept of validating versus mutating and the
admission controllers ran in the exact order specified.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/authentication.md
+5 -5
View File
@@ -6,15 +6,15 @@ reviewers:
- deads2k
- liggitt
title: Authenticating
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of authenticating.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Users in Kubernetes
All Kubernetes clusters have two categories of users: service accounts managed
@@ -840,4 +840,4 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
}
}
```
{{% /capture %}}
content/en/docs/reference/access-authn-authz/authorization.md
+8 -7
View File
@@ -5,16 +5,16 @@ reviewers:
- deads2k
- liggitt
title: Authorization Overview
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Learn more about Kubernetes authorization, including details about creating
policies using the supported authorization modules.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
In Kubernetes, you must be authenticated (logged in) before your request can be
authorized (granted permission to access). For information about authentication,
see [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/).
@@ -197,9 +197,10 @@ namespace can: read all secrets in the namespace; read all config 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 %}}
## {{% heading "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 %}}
content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
+5 -5
View File
@@ -2,11 +2,11 @@
reviewers:
- jbeda
title: Authenticating with Bootstrap Tokens
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
@@ -16,9 +16,9 @@ to support [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), but can be u
for users that wish to start clusters without `kubeadm`. It is also built to
work, via RBAC policy, with the [Kubelet TLS
Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Bootstrap Tokens Overview
Bootstrap Tokens are defined with a specific type
@@ -188,4 +188,4 @@ client relying on the signature to bootstrap TLS trust.
Consult the [kubeadm implementation details](/docs/reference/setup-tools/kubeadm/implementation-details/)
section for more information.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/certificate-signing-requests.md
+8 -7
View File
@@ -4,11 +4,11 @@ reviewers:
- mikedanese
- munnerz
title: Certificate Signing Requests
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -21,9 +21,9 @@ A CertificateSigningRequest (CSR) resource is used to request that a certificate
by a denoted signer, after which the request may be approved or denied before
finally being signed.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Request signing process
The _CertificateSigningRequest_ resource type allows a client to ask for an X.509 certificate
@@ -317,9 +317,10 @@ subresource of the CSR to be signed.
As part of this request, the `status.certificate` field should be set to contain the
signed certificate.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read [Manage TLS Certificates in a Cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)
* View the source code for the kube-controller-manager built in [signer](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/signer/cfssl_signer.go)
@@ -327,4 +328,4 @@ signed certificate.
* For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
* For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
{{% /capture %}}
content/en/docs/reference/access-authn-authz/controlling-access.md
+13 -12
View File
@@ -3,15 +3,15 @@ reviewers:
- erictune
- lavalamp
title: Controlling Access to the Kubernetes API
content_template: templates/concept
content_type: concept
weight: 5
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of controlling access to the Kubernetes API.
{{% /capture %}}
{{% capture body %}}
<!-- 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
@@ -23,7 +23,7 @@ following diagram:
## Transport Security
In a typical Kubernetes cluster, the API serves on port 6443.
In a typical Kubernetes cluster, the API serves on port 443.
The API server presents a certificate. This certificate is
often self-signed, so `$USER/.kube/config` on the user's machine typically
contains the root certificate for the API server's certificate, which when specified
@@ -63,9 +63,9 @@ users in its object store.
## Authorization
After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram.
A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action.
For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`:
@@ -97,7 +97,7 @@ If Bob makes the following request, the request is authorized because he is allo
}
}
```
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied.
Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
@@ -110,10 +110,11 @@ To learn more about Kubernetes authorization, including details about creating p
Admission Control Modules are software modules that can modify or reject requests.
In addition to the attributes available to Authorization Modules, Admission
Control Modules can access the contents of the object that is being created or updated.
They act on objects being created, deleted, updated or connected (proxy), but not reads.
Control Modules can access the contents of the object that is being created or modified.
Multiple admission controllers can be configured. Each is called in order.
Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object.
Admission controllers do not act on requests that merely read objects.
When multiple admission controllers are configured, they are called in order.
This is shown as step **3** in the diagram.
@@ -161,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 %}}
content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+4 -5
View File
@@ -7,18 +7,17 @@ reviewers:
- liggitt
- jpbetz
title: Dynamic Admission Control
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
In addition to [compiled-in admission plugins](/docs/reference/access-authn-authz/admission-controllers/),
admission plugins can be developed as extensions and run as webhooks configured at runtime.
This page describes how to build, configure, use, and monitor admission webhooks.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## What are admission webhooks?
Admission webhooks are HTTP callbacks that receive admission requests and do
@@ -1589,4 +1588,4 @@ If your admission webhooks don't intend to modify the behavior of the Kubernetes
plane, exclude the `kube-system` namespace from being intercepted using a
[`namespaceSelector`](#matching-requests-namespaceselector).
{{% /capture %}}
content/en/docs/reference/access-authn-authz/node.md
+5 -5
View File
@@ -5,15 +5,15 @@ reviewers:
- liggitt
- ericchiang
title: Using Node Authorization
content_template: templates/concept
content_type: concept
weight: 90
---
{{% capture overview %}}
<!-- overview -->
Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Overview
The Node authorizer allows a kubelet to perform API operations. This includes:
@@ -96,4 +96,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 %}}
content/en/docs/reference/access-authn-authz/rbac.md
+4 -6
View File
@@ -4,17 +4,17 @@ reviewers:
- deads2k
- liggitt
title: Using RBAC Authorization
content_template: templates/concept
content_type: concept
aliases: [/rbac/]
weight: 70
---
{{% capture overview %}}
<!-- 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 your organization.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
RBAC authorization uses the `rbac.authorization.k8s.io`
{{< glossary_tooltip text="API group" term_id="api-group" >}} to drive authorization
decisions, allowing you to dynamically configure policies through the Kubernetes API.
@@ -1209,5 +1209,3 @@ kubectl create clusterrolebinding permissive-binding \
After you have transitioned to use RBAC, you should adjust the access controls
for your cluster to ensure that these meet your information security needs.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+5 -5
View File
@@ -5,19 +5,19 @@ reviewers:
- lavalamp
- liggitt
title: Managing Service Accounts
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- 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.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## User accounts versus service accounts
Kubernetes distinguishes between the concept of a user account and a service account
@@ -115,4 +115,4 @@ kubectl delete secret mysecretname
Service Account Controller manages ServiceAccount inside namespaces, and ensures
a ServiceAccount named "default" exists in every active namespace.
{{% /capture %}}
content/en/docs/reference/access-authn-authz/webhook.md
+6 -9
View File
@@ -5,15 +5,15 @@ reviewers:
- deads2k
- liggitt
title: Webhook Mode
content_template: templates/concept
content_type: concept
weight: 95
---
{{% capture overview %}}
<!-- overview -->
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.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
When specified, mode `Webhook` causes Kubernetes to query an outside REST
service when determining user privileges.
@@ -164,8 +164,8 @@ Access to non-resource paths are sent as:
}
```
Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
Non-resource paths include: `/api`, `/apis`, `/metrics`,
`/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and
`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
and `/version` to discover what resources and versions are present on the server.
Access to other non-resource paths can be disallowed without restricting access
@@ -174,6 +174,3 @@ to the REST api.
For further documentation refer to the authorization.v1beta1 API objects and
[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
{{% /capture %}}