rebase to add pt-br/docs/reference/node/_index.md

[zh] sync /concepts/architecture/nodes.md

[ES] Fix broken links for KubeletConfiguration struct

[pt] Update README.md

Document  volume.kubernetes.io/selected-node annotation (kubernetes#36399)

* Documented annotation for pv.kubernetes.io/bind-completed

Signed-off-by: afzal442 <[email protected]>

* Documented annotation for `volume.kubernetes.io/selected-node`

Signed-off-by: afzal442 <[email protected]>

Signed-off-by: afzal442 <[email protected]>

[zh] Sync /zh-cn/_index.html

[zh] sync /concepts/extend-kubernetes/operator.md

[ru] Update KubeCon dates for 2023

Fix in-cluster API discovery documentation (kubernetes#36691)

* Fix in-cluster API discovery documentation

The documentation incorrectly describes the way that client libraries
discover the Kubernetes API server. While the `kubernetes.default.svc`
DNS is provided as a convenience, **all** of the officially supported API
clients use environment variables to discover the address of the API server.

This change updates the documentation to reflect this.

Signed-off-by: Oliver Gould <[email protected]>

* Review feedback

* Fixup

Signed-off-by: Oliver Gould <[email protected]>

Add heading slash to ja content link

This commit adds heading slash "/" on ja content link.
The link is 404 without heading slash that's why I create this commit.

[ja] Remove instruction to use iptables-legacy

As reverted in 8830000, switching to iptables-legacy is no longer required.

[ja] Fix broken link on Creating a cluster with kubeadm pag

[JA] Fix broken links for KubeletConfiguration struct

[ja] Set heading IDs content/ja/docs/concepts/architecture/nodes.md

hi Localize /en/docs/reference/glossary/pod-disruption.md

hi Localize /en/docs/reference/glossary/pod-disruption.md(1)

hi Localize /en/docs/reference/glossary/pod-disruption.md(2)

hi Localize /en/docs/reference/glossary/pod-disruption.md(3)

hi Localize /en/docs/reference/glossary/pod-disruption.md(4)

hi Localize /en/docs/reference/glossary/pod-disruption.md(5)

Owners cleanup part 2

Cleaning up the owners file per comments on the PR

Update to remove anastyakulyk and butuzov from uk-owners

[zh] sync /windows/user-guide.md

described Pod pair

Update garbage-collection.md

Incorporated review suggestion

[ID] Fix broken links for KubeletConfiguration struct

[id] fix deployment apiversion error

Update index.md

doc: capture device-plugin stricter workflow ordering explicitly

Based on kubelet device manager refactoring done in 1.25 release,
there is stricter ordering requirements where the device plugin
MUST start a gRPC service before registering itself to kubelet.
In case this ordering is not followed, the plugin registration
will fail.

Signed-off-by: Swati Sehgal <[email protected]>

Update create-cluster-kubeadm.md

Conformance is not a french word

moved from 38014

changed title

udpated slack channels

fix title

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

fix in view of review comments

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Nate W. <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Nate W. <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Nate W. <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Nate W. <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Nate W. <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Nate W. <[email protected]>

Update content/en/blog/_posts/2023-01-15-Security-Bahavior-Analysis/index.md

Co-authored-by: Nate W. <[email protected]>

pushed to Jan 20

Note that AdmissionConfiguration is a static configuration to the apiserver.

We cannot use `kubectl apply` to apply it to the cluster.

Doing that gives the following error:

        no matches for kind "AdmissionConfiguration" in version "apiserver.config.k8s.io/v1"

Add `--ignore-daemonsets` to docs of `kubectl drain`

Update content/en/docs/tasks/administer-cluster/safely-drain-node.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/docs/tasks/administer-cluster/safely-drain-node.md

Co-authored-by: divya-mohan0209 <[email protected]>

Update content/en/docs/tasks/administer-cluster/safely-drain-node.md

thank you

Co-authored-by: divya-mohan0209 <[email protected]>

fix the shell of appending kubeconfig

sync high-availability.md with en page

update

update

[zh] sync /config-and-storage-resources/persistent-volume-v1.md

[zh-cn]sync list-all-running-container-images.md

Add January 2023 patch releases to the calendar

Signed-off-by: Marko Mudrinić <[email protected]>

[zh-cn] sync some files with en page.

[zh-cn] Sync quota-memory-cpu-namespace

[zh-cn] sync access-cluster-api.md

[zh-cn] Sync web-ui-dashboard.md

[zh] sync kubelet-config.v1beta1.md

[zh-cn] update declare-network-policy.md

[zh-cn] sync dns-debugging-resolution with en page

[zh] sync /releases/patch-releases.md

[zh-cn] Sync cpu-constraint-namespace.md

[zh] sync cluster-upgrade.md

[zh] sync cron-jobs.md

[hi]Localize content/en/docs/reference/glossary/cidr.md

Update cidr.md

Add /pt-br/docs/reference/glossary/event

Updated /pt-br/docs/reference/glossary/event

Changes from code review.

retrigger

[pt-br] Add docs/contribute/review/_index.md

Improvement: Added shell code block snippet to the commands.

Update RBAC Good Practices for PersistentVolumes

The docs previously referred to the reader to the now defunct PodSecurityPolicy
page to explain how PersistentVolumes can be a path of privilege escalation,
burrying the lede.

Now that PodSecurityPolicy is gone, update this bit to actually explain that it
it is unfettered access to creating hostPath-typed PersistentVolumes that are
a problem. Some words lifted from the 1.24 PodSecurityPolicy docs.

Signed-off-by: Mike Waychison <[email protected]>

Update content/en/docs/concepts/security/rbac-good-practices.md

Co-authored-by: Tim Bannister <[email protected]>

Update content/en/docs/concepts/security/rbac-good-practices.md

Co-authored-by: Tim Bannister <[email protected]>

Further updates to clarify language

[zh-cn] Sync 3 files in /tasks/administer-cluster/

[zh-cn]Fix nits in markdown links & update page weight

[pl] Update echoserver image in "Hello Minikube" tutorial for multiarch

Modify correct name to matchImages

Show minor (.0) releases in the calendar

Signed-off-by: Marko Mudrinić <[email protected]>

Remove cherry-pick deadline for minor .0 releases

Signed-off-by: Marko Mudrinić <[email protected]>

Add RU localization for proxies.md

[pt-br] Update includes/task-tutorial-prereqs.md

Updating the `task-tutorial-prereqs.md` file with the English version

Reverted and improved some changes after the review

Tweak long lines in connect-applications-service.md

Improved the content Flow.

Resolved nit.

[zh] Resync service-accounts-admin.md

[zh] sync /access-authn-authz/authentication.md

[zh] Sync kubelet-credential-provider.md

Fix indentations in cluster-level-pss.md

[pt-br] sync tutorials/hello-minikube.md

[en] Remove duplicate entry for SELinuxMountReadWriteOncePod

Signed-off-by: Vicente J. Jiménez Miras <[email protected]>

[en] Update entry for SELinuxMountReadWriteOncePod

Signed-off-by: Vicente J. Jiménez Miras <[email protected]>

Updated kubectl describe svc output

updated  kubectl describe svc my-nginx output

Tweak line wrapping for manage-deployment page

This PR wraps the long lines in the manage-deployment.md page.

Replace images for Virtual IPs and Service Proxies

Co-Authored-By: Tamilselvan Thangamony <[email protected]>

Commit rendered images for virtual IPs reference

- Convert text to curves
- Slight tweaks

Co-Authored-By: Tamilselvan Thangamony <[email protected]>

[zh] sync manage-deployment.md

[zh-cn] resync cluster-level-pss.md and ns-level-pss.md

resync pod-failure-policy.md

[zh] Sync access-authn-authz/authentication.md

[zh-cn] Resync dns-pod-service.md

[zh] Update basic-stateful-set.md

[zh] Sync /tutorials/security/seccomp.md

[zh] sync rbac-good-practices.md

registry change in docs (k8s.gcr.io -> registry.k8s.io) (kubernetes#38501)

* registry change in en docs

* Update content/en/blog/_posts/2019-04-04-local-persistent-volumes-ga.md

Co-authored-by: Tim Bannister <[email protected]>

* Update content/en/blog/_posts/2019-04-04-local-persistent-volumes-ga.md

Co-authored-by: Tim Bannister <[email protected]>

* Update content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md

Co-authored-by: Tim Bannister <[email protected]>

* Update content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md

Co-authored-by: Tim Bannister <[email protected]>

---------

Co-authored-by: Tim Bannister <[email protected]>

[zh-cn] resync kubelet-in-userns.md

[zh-cn] Sync dns-horizontal-autoscaling.md
with en page

 [pt-br] Translated page: Configure DNS for a Cluster.

kubernetes#13939

Fix: Proposed changes.

Update configure-dns-cluster.md

Register service.alpha.kubernetes.io/tolerate-unready-endpoints Ann… (kubernetes#39122)

* Registered service.alpha.kubernetes.io/tolerate-unready-endpoints Annotation

* Update content/en/docs/reference/labels-annotations-taints/_index.md

Co-authored-by: Qiming Teng <[email protected]>

* Update content/en/docs/reference/labels-annotations-taints/_index.md

Co-authored-by: Tim Bannister <[email protected]>

---------

Co-authored-by: Qiming Teng <[email protected]>
Co-authored-by: Tim Bannister <[email protected]>

Add pt-br/docs/reference/glossary/storageclass.md

Signed-off-by: Rodrigo V. Del Monte <[email protected]>

Improve concept docs for ttl-after-finished

Document Job cleanup TTL mechanism better.

Co-authored-by: Nate W. <[email protected]>

Fix links to mutatingadmissionwebhook

[zh] translate user-namespace

Fix indentations in setup-ha-etcd-with-kubeadm

[zh-cn] Sync dns-horizontal-autoscaling.md

Add rolebinding to Configure Multiple Schedulers (kubernetes#38208)

* Add rolebinding to Configure Multiple Schedulers

* Update content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md

Co-authored-by: Tim Bannister <[email protected]>

* Update content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md

Co-authored-by: Qiming Teng <[email protected]>

* Update content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md

Co-authored-by: Aldo Culquicondor <[email protected]>

---------

Co-authored-by: Tim Bannister <[email protected]>
Co-authored-by: Qiming Teng <[email protected]>
Co-authored-by: Aldo Culquicondor <[email protected]>

[zh] sync blog: 2022-12-27-cpumanager-goes-GA.md

[zh-cn] sync tasks/run-application/access-api-from-pod.md

Signed-off-by: xin.li <[email protected]>

[zh-cn] Resync nodelocaldns.md

[zh-cn] sync safely-drain-node.md

Signed-off-by: xin.li <[email protected]>

[zh] Sync /networking/virtual-ips.md

[zh] sync kms-provider.md

Fix Deployment YAML used for SSA

[zh-cn]sync some docs for little change

Signed-off-by: xin.li <[email protected]>

Update doc of admission plugin SecurityContextDeny

Note the shortcomings of the implementation of this admission plugin

Co-authored-by: Tim Bannister <[email protected]>
Co-authored-by: Qiming Teng <[email protected]>

[zh-cn] Sync encrypt-data.md

cleanup custom-resource-definition-versioning page

[zh-cn] resync reference/command-line-tools-reference/feature-gates.md

[zh] sync ttlafterfinished.md

[zh] Resync migrating-from-dockershim/_index.md

[zh-cn]sync ingress-controllers windows-networking

Signed-off-by: xin.li <[email protected]>

Make layout prettier in extended-resource-node.md

[zh-cn]improve docs pod-security-admission pod-security-standards

Signed-off-by: xin.li <[email protected]>

Tweak line wrappings in labels.md

resync NPD

[zh-cn] Sync extended-resource-node.md

[zh-cn] Adjust some lines to make changes compare line by line more efficiently
 in the future

[zh] sync device-plugins.md

[zh] sync /using-api/server-side-apply.md

Add spaces in code snippets for consistency

[zh-cn] Sync configure-cgroup-driver.md

[zh] sync enforce-standards-admission-controller.md

[zh] Sync pod-disruption-budget-v1.md

[pt-br] Add docs/contribute/style/_index.md

Reword explanation of ClusterIP for Services

Update content/en/docs/concepts/services-networking/service.md

thank you

Co-authored-by: divya-mohan0209 <[email protected]>

Update content/en/docs/concepts/services-networking/service.md

Co-authored-by: divya-mohan0209 <[email protected]>

OWNERS_ALIASES

@@ -104,19 +104,16 @@ aliases:
     - atoato88
     - bells17
     - kakts
-    - makocchi-git
     - ptux
     - t-inu
   sig-docs-ko-owners: # Admins for Korean content
-    - ClaudiaJKang
     - gochist
     - ianychoi
     - jihoon-seo
     - seokho-son
     - yoonian
     - ysyukr
   sig-docs-ko-reviews: # PR reviews for Korean content
-    - ClaudiaJKang
     - gochist
     - ianychoi
     - jihoon-seo
@@ -160,19 +157,15 @@ aliases:
     - devlware
     - edsoncelio
     - femrtnz
-    - jailton
     - jcjesus
-    - jhonmike
     - rikatz
     - stormqueen1990
     - yagonobre
   sig-docs-pt-reviews: # PR reviews for Portugese content
     - devlware
     - edsoncelio
     - femrtnz
-    - jailton
     - jcjesus
-    - jhonmike
     - rikatz
     - stormqueen1990
     - yagonobre
@@ -196,9 +189,7 @@ aliases:
     - mfilocha
     - nvtkaszpir
   sig-docs-uk-owners: # Admins for Ukrainian content
-    - anastyakulyk
     - Arhell
-    - butuzov
     - MaxymVlasov
   sig-docs-uk-reviews: # PR reviews for Ukrainian content
     - Arhell

README-pt.md

@@ -13,7 +13,7 @@ Você pode executar o website localmente utilizando o Hugo (versão Extended), o
 Para usar este repositório, você precisa instalar:
 
 - [npm](https://www.npmjs.com/)
-- [Go](https://golang.org/)
+- [Go](https://go.dev/)
 - [Hugo (versão Extended)](https://gohugo.io/)
 - Um container runtime, por exemplo [Docker](https://www.docker.com/).
 

content/en/blog/_posts/2019-04-04-local-persistent-volumes-ga.md

@@ -129,7 +129,7 @@ spec:
     spec:
       containers:
       - name: test-container
-        image: k8s.gcr.io/busybox
+        image: registry.k8s.io/busybox # updated after publication (previously used k8s.gcr.io/busybox)
         command:
         - "/bin/sh"
         args:

content/en/blog/_posts/2020-05-27-An-Introduction-to-the-K8s-Infrastructure-Working-Group.md

@@ -55,7 +55,7 @@ The team has made progress in the last few months that is well worth celebrating
 
 - The K8s-Infrastructure Working Group released an automated billing report that they start every meeting off by reviewing as a group. 
 - DNS for k8s.io and kubernetes.io are also fully [community-owned](https://groups.google.com/g/kubernetes-dev/c/LZTYJorGh7c/m/u-ydk-yNEgAJ), with community members able to [file issues](https://github.com/kubernetes/k8s.io/issues/new?assignees=&labels=wg%2Fk8s-infra&template=dns-request.md&title=DNS+REQUEST%3A+%3Cyour-dns-record%3E) to manage records.
-- The container registry [k8s.gcr.io](https://github.com/kubernetes/k8s.io/tree/main/k8s.gcr.io) is also fully community-owned and available for all Kubernetes subprojects to use. 
+- The container registry [registry.k8s.io](https://github.com/kubernetes/k8s.io/tree/main/registry.k8s.io) is also fully community-owned and available for all Kubernetes subprojects to use. 
 _Note:_ The container registry has changed to registry.k8s.io. Updated on August 25, 2022.
 - The Kubernetes [publishing-bot](https://github.com/kubernetes/publishing-bot) responsible for keeping k8s.io/kubernetes/staging repositories published to their own top-level repos (For example: [kubernetes/api](https://github.com/kubernetes/api)) runs on a community-owned cluster.
 - The gcsweb.k8s.io service used to provide anonymous access to GCS buckets for kubernetes artifacts runs on a community-owned cluster.

content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md

@@ -115,7 +115,8 @@ metadata:
 spec:
   containers:
   - name: agnhost
-    image: k8s.gcr.io/e2e-test-images/agnhost:2.35
+    # image changed since publication (previously used registry "k8s.gcr.io")
+    image: registry.k8s.io/e2e-test-images/agnhost:2.35
     command: ["/agnhost", "grpc-health-checking"]
     ports:
     - containerPort: 5000

content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md

@@ -50,7 +50,8 @@ spec:
         app: nginx
     spec:
       containers:
-      - image: k8s.gcr.io/nginx-slim:0.8
+      # image changed since publication (previously used registry "k8s.gcr.io")
+      - image: registry.k8s.io/nginx-slim:0.8
         imagePullPolicy: IfNotPresent
         name: nginx
   updateStrategy:
@@ -66,7 +67,7 @@ If you enable the new feature and you don't specify a value for `maxUnavailable`
 I'll run through a scenario based on that example manifest to demonstrate how this feature works. I will deploy a StatefulSet that
 has 5 replicas, with `maxUnavailable` set to 2 and `partition` set to 0.
 
-I can trigger a rolling update by changing the image to `k8s.gcr.io/nginx-slim:0.9`. Once I initiate the rolling update, I can 
+I can trigger a rolling update by changing the image to `registry.k8s.io/nginx-slim:0.9`. Once I initiate the rolling update, I can 
 watch the pods update 2 at a time as the current value of maxUnavailable is 2. The below output shows a span of time and is not 
 complete.  The maxUnavailable can be an absolute number (for example, 2) or a percentage of desired Pods (for example, 10%). The 
 absolute number is calculated from percentage by rounding up to the nearest integer.  

content/en/blog/_posts/2023-01-12-protect-mission-critical-pods-priorityclass/index.md

@@ -103,7 +103,7 @@ spec:
     resources:
       requests:
         memory: "256Mi"
-         cpu: "0.2"
+        cpu: "0.2"
       limits:
         memory: ".5Gi"
         cpu: "0.5"

content/en/blog/_posts/2023-01-20-Security-Bahavior-Analysis/index.md

@@ -0,0 +1,84 @@
+---
+layout: blog
+title: Consider All Microservices Vulnerable — And Monitor Their Behavior
+date: 2023-01-20
+slug: security-behavior-analysis
+---
+
+**Author:**
+David Hadas (IBM Research Labs)
+
+_This post warns Devops from a false sense of security. Following security best practices when developing and configuring microservices do not result in non-vulnerable microservices. The post shows that although all deployed microservices are vulnerable, there is much that can be done to ensure microservices are not exploited. It explains how analyzing the behavior of clients and services from a security standpoint, named here **"Security-Behavior Analysis"**, can protect the deployed vulnerable microservices. It points to [Guard](http://knative.dev/security-guard), an open source project offering security-behavior monitoring and control of Kubernetes microservices presumed vulnerable._
+
+As cyber attacks continue to intensify in sophistication, organizations deploying cloud services continue to grow their cyber investments aiming to produce safe and non-vulnerable services. However, the year-by-year growth in cyber investments does not result in a parallel reduction in cyber incidents. Instead, the number of cyber incidents continues to grow annually. Evidently, organizations are doomed to fail in this struggle - no matter how much effort is made to detect and remove cyber weaknesses from deployed services, it seems offenders always have the upper hand.
+
+Considering the current spread of offensive tools, sophistication of offensive players, and ever-growing cyber financial gains to offenders, any cyber strategy that relies on constructing a non-vulnerable, weakness-free service in 2023 is clearly too naïve. It seems the only viable strategy is to:
+
+➥ **Admit that your services are vulnerable!**
+
+In other words, consciously accept that you will never create completely invulnerable services. If your opponents find even a single weakness as an entry-point, you lose! Admitting that in spite of your best efforts, all your services are still vulnerable is an important first step. Next, this post discusses what you can do about it...
+
+## How to protect microservices from being exploited
+
+Being vulnerable does not necessarily mean that your service will be exploited. Though your services are vulnerable in some ways unknown to you, offenders still need to identify these vulnerabilities and then exploit them. If offenders fail to exploit your service vulnerabilities, you win! In other words, having a vulnerability that can’t be exploited, represents a risk that can’t be realized.
+
+{{< figure src="Example.png" alt="Image of an example of offender gaining foothold in a service" class="diagram-large" caption="Figure 1. An Offender gaining foothold in a vulnerable service" >}}
+
+The above diagram shows an example in which the offender does not yet have a foothold in the service; that is, it is assumed that your service does not run code controlled by the offender on day 1. In our example the service has vulnerabilities in the API exposed to clients. To gain an initial foothold the offender uses a malicious client to try and exploit one of the service API vulnerabilities. The malicious client sends an exploit that triggers some unplanned behavior of the service.
+
+More specifically, let’s assume the service is vulnerable to an SQL injection. The developer failed to sanitize the user input properly, thereby allowing clients to send values that would change the intended behavior. In our example, if a client sends a query string with key “username” and value of _“tom or 1=1”_, the client will receive the data of all users. Exploiting this vulnerability requires the client to send an irregular string as the value. Note that benign users will not be sending a string with spaces or with the equal sign character as a username, instead they will normally send legal usernames which for example may be defined as a short sequence of characters a-z. No legal username can trigger service unplanned behavior.
+
+In this simple example, one can already identify several opportunities to detect and block an attempt to exploit the vulnerability (un)intentionally left behind by the developer, making the vulnerability unexploitable. First, the malicious client behavior differs from the behavior of benign clients, as it sends irregular requests. If such a change in behavior is detected and blocked, the exploit will never reach the service. Second, the service behavior in response to the exploit differs from the service behavior in response to a regular request. Such behavior may include making subsequent irregular calls to other services such as a data store, taking irregular time to respond, and/or responding to the malicious client with an irregular response (for example, containing much more data than normally sent in case of benign clients making regular requests). Service behavioral changes, if detected, will also allow blocking the exploit in different stages of the exploitation attempt.
+
+More generally:
+
+- Monitoring the behavior of clients can help detect and block exploits against service API vulnerabilities. In fact, deploying efficient client behavior monitoring makes many vulnerabilities unexploitable and others very hard to achieve. To succeed, the offender needs to create an exploit undetectable from regular requests.
+
+- Monitoring the behavior of services can help detect services as they are being exploited regardless of the attack vector used. Efficient service behavior monitoring limits what an attacker may be able to achieve as the offender needs to ensure the service behavior is undetectable from regular service behavior.
+
+Combining both approaches may add a protection layer to the deployed vulnerable services, drastically decreasing the probability for anyone to successfully exploit any of the deployed vulnerable services. Next, let us identify four use cases where you need to use security-behavior monitoring.
+
+## Use cases
+
+One can identify the following four different stages in the life of any service from a security standpoint. In each stage, security-behavior monitoring is required to meet different challenges:
+
+Service State | Use case | What do you need in order to cope with this use case?
+------------- | ------------- | -----------------------------------------
+**Normal**   | **No known vulnerabilities:** The service owner is normally not aware of any known vulnerabilities in the service image or configuration. Yet, it is reasonable to assume that the service has weaknesses. | **Provide generic protection against any unknown, zero-day, service vulnerabilities** - Detect/block irregular patterns sent as part of incoming client requests that may be used as exploits.
+**Vulnerable** | **An applicable CVE is published:** The service owner is required to release a new non-vulnerable revision of the service. Research shows that in practice this process of removing a known vulnerability may take many weeks to accomplish (2 months on average).   |  **Add protection based on the CVE analysis** - Detect/block incoming requests that include specific patterns that may be used to exploit the discovered vulnerability. Continue to offer services, although the service has a known vulnerability.
+**Exploitable**  | **A known exploit is published:** The service owner needs a way to filter incoming requests that contain the known exploit.   |  **Add protection based on a known exploit signature** - Detect/block incoming client requests that carry signatures identifying the exploit. Continue to offer services, although the presence of an exploit.  
+**Misused**  | **An offender misuses pods backing the service:** The offender can follow an attack pattern enabling him/her to misuse pods. The service owner needs to restart any compromised pods while using non compromised pods to continue offering the service. Note that once a pod is restarted, the offender needs to repeat the attack pattern before he/she may again misuse it.  |  **Identify and restart instances of the component that is being misused** - At any given time, some backing pods may be compromised and misused, while others behave as designed. Detect/remove the misused pods while allowing other pods to continue servicing client requests.
+
+Fortunately, microservice architecture is well suited to security-behavior monitoring as discussed next.
+
+## Security-Behavior of microservices versus monoliths {#microservices-vs-monoliths}
+
+Kubernetes is often used to support workloads designed with microservice architecture. By design, microservices aim to follow the UNIX philosophy of "Do One Thing And Do It Well". Each microservice has a bounded context and a clear interface. In other words, you can expect the microservice clients to send relatively regular requests and the microservice to present a relatively regular behavior as a response to these requests. Consequently, a microservice architecture is an excellent candidate for security-behavior monitoring.
+
+{{< figure src="Microservices.png" alt="Image showing why microservices are well suited for security-behavior monitoring" class="diagram-large" caption="Figure 2. Microservices are well suited for security-behavior monitoring" >}}
+
+The diagram above clarifies how dividing a monolithic service to a set of microservices improves our ability to perform security-behavior monitoring and control. In a monolithic service approach, different client requests are intertwined, resulting in a diminished ability to identify irregular client behaviors. Without prior knowledge, an observer of the intertwined client requests will find it hard to distinguish between types of requests and their related characteristics. Further, internal client requests are not exposed to the observer. Lastly, the aggregated behavior of the monolithic service is a compound of the many different internal behaviors of its components, making it hard to identify irregular service behavior.
+
+In a microservice environment, each microservice is expected by design to offer a more well-defined service and serve better defined type of requests. This makes it easier for an observer to identify irregular client behavior and irregular service behavior. Further, a microservice design exposes the internal requests and internal services which offer more security-behavior data to identify irregularities by an observer. Overall, this makes the microservice design pattern better suited for security-behavior monitoring and control.
+
+## Security-Behavior monitoring on Kubernetes
+
+Kubernetes deployments seeking to add Security-Behavior may use [Guard](http://knative.dev/security-guard), developed under the CNCF project Knative. Guard is integrated into the full Knative automation suite that runs on top of Kubernetes. Alternatively, **you can deploy Guard as a standalone tool** to protect any HTTP-based workload on Kubernetes.
+
+See:
+
+- [Guard](https://github.com/knative-sandbox/security-guard)  on Github, for using Guard as a standalone tool.
+- The Knative automation suite - Read about Knative, in the blog post [Opinionated Kubernetes](https://davidhadas.wordpress.com/2022/08/29/knative-an-opinionated-kubernetes) which describes how Knative simplifies and unifies the way web services are deployed on Kubernetes.
+- You may contact Guard maintainers on the [SIG Security](https://kubernetes.slack.com/archives/C019LFTGNQ3) Slack channel or on the Knative community [security](https://knative.slack.com/archives/CBYV1E0TG) Slack channel. The Knative community channel will move soon to the [CNCF Slack](https://communityinviter.com/apps/cloud-native/cncf) under the name `#knative-security`.
+
+The goal of this post is to invite the Kubernetes community to action and introduce Security-Behavior monitoring and control to help secure Kubernetes based deployments. Hopefully, the community as a follow up will:
+
+1. Analyze the cyber challenges presented for different Kubernetes use cases
+1. Add appropriate security documentation for users on how to introduce Security-Behavior monitoring and control.
+1. Consider how to integrate with tools that can help users monitor and control their vulnerable services.
+
+## Getting involved
+
+You are welcome to get involved and join the effort to develop security behavior monitoring
+and control for Kubernetes; to share feedback and contribute to code or documentation;
+and to make or suggest improvements of any kind.

content/en/docs/concepts/architecture/garbage-collection.md

@@ -144,7 +144,7 @@ which you can define:
 
   * `MinAge`: the minimum age at which the kubelet can garbage collect a
     container. Disable by setting to `0`.
-  * `MaxPerPodContainer`: the maximum number of dead containers each Pod pair
+  * `MaxPerPodContainer`: the maximum number of dead containers each Pod 
     can have. Disable by setting to less than `0`.
   * `MaxContainers`: the maximum number of dead containers the cluster can have.
     Disable by setting to less than `0`.