Merge master into dev-1.22 to keep in sync

2021-08-04 19:43:06 +02:00
parent afeca102eb a54e81ece4
commit 61ac44bb11
31 changed files with 417 additions and 149 deletions
@@ -163,7 +163,7 @@ Instructions to do so are available at [Install Docker Engine - Enterprise on Wi
 #### Install wins, kubelet, and kubeadm  

 ```PowerShell
-curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
 ```

@@ -206,7 +206,7 @@ If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2")
 #### Install wins, kubelet, and kubeadm

 ```PowerShell
-curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
 ```

@@ -126,7 +126,18 @@ command. In that case, you should explicitly set `--certificate-renewal=true`.

 You can renew your certificates manually at any time with the `kubeadm certs renew` command.

-This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
+This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. 
+
+After running the command you should restart the control plane Pods. This is required since
+dynamic certificate reload is currently not supported for all components and certificates.
+[Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet
+and not by the API Server, thus kubectl cannot be used to delete and restart them.
+To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` 
+and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/
+reference/config-api/kubelet-config.v1beta1/).
+The kubelet will terminate the Pod if it's no longer in the manifest directory.
+You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate
+the Pod and the certificate renewal for the component can complete.

 {{< warning >}}
 If you are running an HA cluster, this command needs to be executed on all the control-plane nodes.
@@ -24,45 +24,59 @@ For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.
 ## Deploying Cilium on Minikube for Basic Testing

 To get familiar with Cilium easily you can follow the
-[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/)
+[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)
 to perform a basic DaemonSet installation of Cilium in minikube.

-To start minikube, minimal version required is >= v1.3.1, run the with the
+To start minikube, minimal version required is >= v1.5.2, run the with the
 following arguments:

 ```shell
 minikube version
 ```
 ```
-minikube version: v1.3.1
+minikube version: v1.5.2
 ```

 ```shell
-minikube start --network-plugin=cni --memory=4096
+minikube start --network-plugin=cni
 ```

-Mount the BPF filesystem:
+For minikube you can install Cilium using its CLI tool. Cilium will
+automatically detect the cluster configuration and will install the appropriate
+components for a successful installation:

 ```shell
-minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
-```
-
-For minikube you can deploy this simple ''all-in-one'' YAML file that includes
-DaemonSet configurations for Cilium as well as appropriate RBAC settings:
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
+curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
+sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
+rm cilium-linux-amd64.tar.gz
+cilium install
 ```
 ```
-configmap/cilium-config created
-serviceaccount/cilium created
-serviceaccount/cilium-operator created
-clusterrole.rbac.authorization.k8s.io/cilium created
-clusterrole.rbac.authorization.k8s.io/cilium-operator created
-clusterrolebinding.rbac.authorization.k8s.io/cilium created
-clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
-daemonset.apps/cilium create
-deployment.apps/cilium-operator created
+🔮 Auto-detected Kubernetes kind: minikube
+✨ Running "minikube" validation checks
+✅ Detected minikube version "1.20.0"
+ℹ️  Cilium version not set, using default version "v1.10.0"
+🔮 Auto-detected cluster name: minikube
+🔮 Auto-detected IPAM mode: cluster-pool
+🔮 Auto-detected datapath mode: tunnel
+🔑 Generating CA...
+2021/05/27 02:54:44 [INFO] generate received request
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
+🔑 Generating certificates for Hubble...
+2021/05/27 02:54:44 [INFO] generate received request
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
+🚀 Creating Service accounts...
+🚀 Creating Cluster roles...
+🚀 Creating ConfigMap...
+🚀 Creating Agent DaemonSet...
+🚀 Creating Operator Deployment...
+⌛ Waiting for Cilium to be installed...
 ```

 The remainder of the Getting Started Guide explains how to enforce both L3/L4
@@ -85,14 +99,14 @@ Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
 this list of Pods run:

 ```shell
-kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system -l k8s-app=cilium
 ```

 You'll see a list of Pods similar to this:

 ```console
-NAME            READY   STATUS    RESTARTS   AGE
-cilium-6rxbd    1/1     Running   0          1m
+NAME           READY   STATUS    RESTARTS   AGE
+cilium-kkdhz   1/1     Running   0          3m23s
 ...
 ```

@@ -26,7 +26,7 @@ and provides recommendations on overall security.

 ## Controlling access to the Kubernetes API

-As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions
+As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions
 they are allowed to perform is the first line of defense.

 ### Use Transport Layer Security (TLS) for all API traffic
@@ -40,7 +40,7 @@ potentially unsecured traffic.
 ### API Authentication

 Choose an authentication mechanism for the API servers to use that matches the common access patterns
-when you install a cluster. For instance, small single user clusters may wish to use a simple certificate
+when you install a cluster. For instance, small, single-user clusters may wish to use a simple certificate
 or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that
 allow users to be subdivided into groups.

@@ -54,7 +54,7 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
 Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships
 an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a
 set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
-resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
+resources (pods, services, nodes) and can be namespace-scoped or cluster-scoped. A set of out-of-the-box
 roles are provided that offer reasonable default separation of responsibility depending on what
 actions a client might want to perform. It is recommended that you use the
 [Node](/docs/reference/access-authn-authz/node/) and
@@ -69,8 +69,8 @@ With authorization, it is important to understand how updates on one object may
 other places. For instance, a user may not be able to create pods directly, but allowing them to
 create a deployment, which creates pods on their behalf, will let them create those pods
 indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node
-being terminated and recreated on other nodes. The out of the box roles represent a balance
-between flexibility and the common use cases, but more limited roles should be carefully reviewed
+being terminated and recreated on other nodes. The out-of-the box roles represent a balance
+between flexibility and common use cases, but more limited roles should be carefully reviewed
 to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.

 Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
@@ -104,7 +104,7 @@ reserved resources like memory, or to provide default limits when none are speci
 ### Controlling what privileges containers run with

 A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/)
-that allows it to request access to running as a specific Linux user on a node (like root),
+that allows it to request access to run as a specific Linux user on a node (like root),
 access to run privileged or access the host network, and other controls that would otherwise
 allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
 can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
@@ -155,10 +155,10 @@ within their namespaces. Many of the supported [Kubernetes networking providers]
 now respect network policy.

 Quota and limit ranges can also be used to control whether users may request node ports or
-load balanced services, which on many clusters can control whether those users applications
+load-balanced services, which on many clusters can control whether those users applications
 are visible outside of the cluster.

-Additional protections may be available that control network rules on a per plugin or per
+Additional protections may be available that control network rules on a per-plugin or per-
 environment basis, such as per-node firewalls, physically separating cluster nodes to
 prevent cross talk, or advanced networking policy.

@@ -169,7 +169,7 @@ By default these APIs are accessible by pods running on an instance and can cont
 credentials for that node, or provisioning data such as kubelet credentials. These credentials
 can be used to escalate within the cluster or to other cloud services under the same account.

-When running Kubernetes on a cloud platform limit permissions given to instance credentials, use
+When running Kubernetes on a cloud platform, limit permissions given to instance credentials, use
 [network policies](/docs/tasks/administer-cluster/declare-network-policy/) to restrict pod access
 to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -177,7 +177,7 @@ to the metadata API, and avoid using provisioning data to deliver secrets.

 By default, there are no restrictions on which nodes may run a pod.  Kubernetes offers a
 [rich set of policies for controlling placement of pods onto nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
-and the [taint based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
+and the [taint-based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/)
 that are available to end users. For many clusters use of these policies to separate workloads
 can be a convention that authors adopt or enforce via tooling.

@@ -223,8 +223,9 @@ do not use.
 The shorter the lifetime of a secret or credential the harder it is for an attacker to make
 use of that credential. Set short lifetimes on certificates and automate their rotation. Use
 an authentication provider that can control how long issued tokens are available and use short
-lifetimes where possible. If you use service account tokens in external integrations, plan to
-rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed.
+lifetimes where possible. If you use service-account tokens in external integrations, plan to
+rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap 
+token used for setting up nodes should be revoked or its authorization removed.

 ### Review third party integrations before enabling them

@@ -246,7 +247,8 @@ and may grant an attacker significant visibility into the state of your cluster.
 your backups using a well reviewed backup and encryption solution, and consider using full disk
 encryption where possible.

-Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
+Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature 
+introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
 parties that gain access to your etcd backups from viewing the content of those secrets. While
 this feature is currently beta, it offers an additional level of defense when backups
 are not encrypted or an attacker gains read access to etcd.