Merge remote-tracking branch 'upstream/main' into dev-1.23
This commit is contained in:
@@ -134,6 +134,21 @@ The output is similar to this:
|
||||
no
|
||||
```
|
||||
|
||||
Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
|
||||
can list Pods in the Namespace `target`:
|
||||
|
||||
```bash
|
||||
kubectl auth can-i list pods \
|
||||
--namespace target \
|
||||
--as system:serviceaccount:dev:dev-sa
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
yes
|
||||
```
|
||||
|
||||
`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
|
||||
exposes the API server authorization to external services. Other resources in
|
||||
this group include:
|
||||
@@ -192,22 +207,33 @@ 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.
|
||||
|
||||
## Privilege escalation via pod creation
|
||||
## Privilege escalation via workload creation or edits {#privilege-escalation-via-pod-creation}
|
||||
|
||||
Users who have the ability to create pods in a namespace can potentially
|
||||
escalate their privileges within that namespace. They can create pods that
|
||||
access their privileges within that namespace. They can create pods that access
|
||||
secrets the user cannot themselves read, or that run under a service account
|
||||
with different/greater permissions.
|
||||
Users who can create/edit pods in a namespace, either directly or through a [controller](/docs/concepts/architecture/controller/)
|
||||
such as an operator, could escalate their privileges in that namespace.
|
||||
|
||||
{{< caution >}}
|
||||
System administrators, use care when granting access to pod creation. A user
|
||||
granted permission to create pods (or controllers that create pods) in the
|
||||
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.
|
||||
System administrators, use care when granting access to create or edit workloads.
|
||||
Details of how these can be misused are documented in [escalation paths](/docs/reference/access-authn-authz/authorization/#escalation-paths)
|
||||
{{< /caution >}}
|
||||
|
||||
### Escalation paths {#escalation-paths}
|
||||
- Mounting arbitrary secrets in that namespace
|
||||
- Can be used to access secrets meant for other workloads
|
||||
- Can be used to obtain a more privileged service account's service account token
|
||||
- Using arbitrary Service Accounts in that namespace
|
||||
- Can perform Kubernetes API actions as another workload (impersonation)
|
||||
- Can perform any privileged actions that Service Account has
|
||||
- Mounting configmaps meant for other workloads in that namespace
|
||||
- Can be used to obtain information meant for other workloads, such as DB host names.
|
||||
- Mounting volumes meant for other workloads in that namespace
|
||||
- Can be used to obtain information meant for other workloads, and change it.
|
||||
|
||||
{{< caution >}}
|
||||
System administrators should be cautious when deploying CRDs that
|
||||
change the above areas. These may open privilege escalations paths.
|
||||
This should be considered when deciding on your RBAC controls.
|
||||
{{< /caution >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ See the [webhook request](#request) section for details on the data sent to webh
|
||||
See the [webhook response](#response) section for the data expected from webhooks.
|
||||
|
||||
The example admission webhook server leaves the `ClientAuth` field
|
||||
[empty](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48),
|
||||
[empty](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/images/agnhost/webhook/config.go#L38-L39),
|
||||
which defaults to `NoClientCert`. This means that the webhook server does not
|
||||
authenticate the identity of the clients, supposedly apiservers. If you need
|
||||
mutual TLS or other ways to authenticate the clients, see
|
||||
@@ -79,7 +79,7 @@ The webhook server in the e2e test is deployed in the Kubernetes cluster, via
|
||||
the [deployment API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps).
|
||||
The test also creates a [service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
|
||||
as the front-end of the webhook server. See
|
||||
[code](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/e2e/apimachinery/webhook.go#L301).
|
||||
[code](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/e2e/apimachinery/webhook.go#L748).
|
||||
|
||||
You may also deploy your webhooks outside of the cluster. You will need to update
|
||||
your webhook configurations accordingly.
|
||||
|
||||
@@ -125,7 +125,6 @@ different Kubernetes components.
|
||||
| `HPAScaleToZero` | `false` | Alpha | 1.16 | |
|
||||
| `IndexedJob` | `false` | Alpha | 1.21 | 1.21 |
|
||||
| `IndexedJob` | `true` | Beta | 1.22 | |
|
||||
| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
|
||||
| `IngressClassNamespacedParams` | `false` | Alpha | 1.21 | 1.21 |
|
||||
| `IngressClassNamespacedParams` | `true` | Beta | 1.22 | |
|
||||
| `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | |
|
||||
@@ -138,13 +137,13 @@ different Kubernetes components.
|
||||
| `IPv6DualStack` | `true` | Beta | 1.21 | |
|
||||
| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
|
||||
| `KubeletCredentialProviders` | `false` | Alpha | 1.20 | |
|
||||
| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
|
||||
| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
|
||||
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
|
||||
| `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
|
||||
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
|
||||
| `LogarithmicScaleDown` | `false` | Alpha | 1.21 | 1.21 |
|
||||
| `LogarithmicScaleDown` | `true` | Beta | 1.22 | |
|
||||
| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
|
||||
| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
|
||||
| `MemoryManager` | `false` | Alpha | 1.21 | 1.21 |
|
||||
| `MemoryManager` | `true` | Beta | 1.22 | |
|
||||
| `MemoryQoS` | `false` | Alpha | 1.22 | |
|
||||
@@ -287,9 +286,6 @@ different Kubernetes components.
|
||||
| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
|
||||
| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
|
||||
| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
|
||||
| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
|
||||
| `DynamicKubeletConfig` | `true` | Beta | 1.11 | 1.21 |
|
||||
| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
|
||||
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
|
||||
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
|
||||
| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |
|
||||
|
||||
@@ -51,7 +51,7 @@ kubelet [flags]
|
||||
<td colspan="2">--address string Default: 0.0.0.0 </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the Kubelet to serve on (set to <code>0.0.0.0</code> or <code>::</code> for listening in gll interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address for the Kubelet to serve on (set to <code>0.0.0.0</code> or <code>::</code> for listening in all interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
|
||||
@@ -10,9 +10,9 @@ aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
An abstraction used by Kubernetes to support multiple virtual clusters on the same physical {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
|
||||
An abstraction used by Kubernetes to support isolation of groups of resources within a single {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces.
|
||||
Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
|
||||
|
||||
|
||||
@@ -142,6 +142,22 @@ For information about enabling IPVS mode with kubeadm see:
|
||||
For information about passing flags to control plane components see:
|
||||
- [control-plane-flags](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)
|
||||
|
||||
### Running kubeadm without an Internet connection {#without-internet-connection}
|
||||
|
||||
For running kubeadm without an Internet connection you have to pre-pull the required control-plane images.
|
||||
|
||||
You can list and pull the images using the `kubeadm config images` sub-command:
|
||||
|
||||
```shell
|
||||
kubeadm config images list
|
||||
kubeadm config images pull
|
||||
```
|
||||
|
||||
You can pass `--config` to the above commands with a [kubeadm configuration file](#config-file)
|
||||
to control the `kubernetesVersion` and `imageRepository` fields.
|
||||
|
||||
All default `k8s.gcr.io` images that kubeadm requires support multiple architectures.
|
||||
|
||||
### Using custom images {#custom-images}
|
||||
|
||||
By default, kubeadm pulls images from `k8s.gcr.io`. If the
|
||||
@@ -151,13 +167,24 @@ requested Kubernetes version is a CI label (such as `ci/latest`)
|
||||
You can override this behavior by using [kubeadm with a configuration file](#config-file).
|
||||
Allowed customization are:
|
||||
|
||||
* To provide `kubernetesVersion` which affects the version of the images.
|
||||
* To provide an alternative `imageRepository` to be used instead of
|
||||
`k8s.gcr.io`.
|
||||
* To set `useHyperKubeImage` to `true` to use the HyperKube image.
|
||||
* To provide a specific `imageRepository` and `imageTag` for etcd or DNS add-on.
|
||||
* To provide a specific `imageRepository` and `imageTag` for etcd or CoreDNS.
|
||||
|
||||
Please note that the configuration field `kubernetesVersion` or the command line flag
|
||||
`--kubernetes-version` affect the version of the images.
|
||||
Image paths between the default `k8s.gcr.io` and a custom repository specified using
|
||||
`imageRepository` may differ for backwards compatibility reasons. For example,
|
||||
one image might have a subpath at `k8s.gcr.io/subpath/image`, but be defaulted
|
||||
to `my.customrepository.io/image` when using a custom repository.
|
||||
|
||||
To ensure you push the images to your custom repository in paths that kubeadm
|
||||
can consume, you must:
|
||||
|
||||
* Pull images from the defaults paths at `k8s.gcr.io` using `kubeadm config images {list|pull}`.
|
||||
* Push images to the paths from `kubeadm config images list --config=config.yaml`,
|
||||
where `config.yaml` contains the custom `imageRepository`, and/or `imageTag`
|
||||
for etcd and CoreDNS.
|
||||
* Pass the same `config.yaml` to `kubeadm init`.
|
||||
|
||||
### Uploading control-plane certificates to the cluster
|
||||
|
||||
@@ -209,19 +236,6 @@ value to the kubelet.
|
||||
|
||||
Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
|
||||
|
||||
### Running kubeadm without an internet connection
|
||||
|
||||
For running kubeadm without an internet connection you have to pre-pull the required control-plane images.
|
||||
|
||||
You can list and pull the images using the `kubeadm config images` sub-command:
|
||||
|
||||
```shell
|
||||
kubeadm config images list
|
||||
kubeadm config images pull
|
||||
```
|
||||
|
||||
All images that kubeadm requires such as `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` and `k8s.gcr.io/pause` support multiple architectures.
|
||||
|
||||
### Automating kubeadm
|
||||
|
||||
Rather than copying the token you obtained from `kubeadm init` to each node, as
|
||||
|
||||
@@ -287,7 +287,7 @@ If your configuration is not using the latest version it is **recommended** that
|
||||
the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
For more information on the fields and usage of the configuration you can navigate to our
|
||||
[API reference](/docs/reference/config-api/kubeadm-config.v1beta2/).
|
||||
[API reference](/docs/reference/config-api/kubeadm-config.v1beta3/).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ behind one command, with support for both planning an upgrade and actually perfo
|
||||
|
||||
## kubeadm upgrade guidance
|
||||
|
||||
The steps for performing a upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
The steps for performing an upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
|
||||
For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website.
|
||||
|
||||
You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests.
|
||||
|
||||
@@ -8,8 +8,7 @@ no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
Kubernetes contains several built-in tools and external tools that are commonly used or relevant that may as well be seen as required for Kubernetes to function.
|
||||
|
||||
Kubernetes contains several tools to help you work with the Kubernetes system.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -25,10 +24,14 @@ development and testing purposes.
|
||||
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
|
||||
|
||||
## Helm
|
||||
{{% thirdparty-content single="true" %}}
|
||||
|
||||
[Helm](https://helm.sh/) is a tool for managing packages of pre-configured
|
||||
Kubernetes resources. These packages are known as _Helm charts_.
|
||||
|
||||
Helm is a third party managed tool for managing packages of pre-configured
|
||||
Kubernetes resources, aka Kubernetes charts.
|
||||
|
||||
Use Helm to:
|
||||
|
||||
* Find and use popular software packaged as Kubernetes charts
|
||||
|
||||
@@ -109,7 +109,7 @@ objects.
|
||||
|
||||
All of this is best illustrated by examples. Imagine a Kubernetes release,
|
||||
version X, which introduces a new API group. A new Kubernetes release is made
|
||||
every approximately 3 months (4 per year). The following table describes which
|
||||
every approximately 4 months (3 per year). The following table describes which
|
||||
API versions are supported in a series of subsequent releases.
|
||||
|
||||
<table>
|
||||
|
||||
Reference in New Issue
Block a user