Merge branch 'aws:master' into master

content/reliability/docs/index.ko.md

@@ -0,0 +1,45 @@
+# 신뢰성을 위한 Amazon EKS 모범 사례 가이드
+
+이 섹션에서는 EKS에서 실행되는 워크로드의 복원력과 가용성을 높이는 방법에 대한 지침을 제공합니다.
+
+## 이 가이드를 사용하는 방법
+
+이 안내서는 EKS에서 가용성이 높고 내결함성이 있는 서비스를 개발하고 운영하려는 개발자와 설계자를 대상으로 합니다. 이 가이드는 보다 쉽게 사용할 수 있도록 다양한 주제 영역으로 구성되어 있습니다. 각 항목은 간략한 개요로 시작하여 EKS 클러스터의 신뢰성을 위한 권장 사항 및 모범 사례 목록이 이어집니다.
+
+## 소개
+
+EKS의 신뢰성 모범 사례는 다음 주제에 따라 그룹화되었습니다.
+
+* 애플리케이션
+* 컨트롤 플레인
+* 데이터 플레인
+
+---
+
+무엇이 시스템을 신뢰할 수 있게 만드나요? 일정 기간의 환경 변화에도 불구하고 시스템이 일관되게 작동하고 요구 사항을 충족할 수 있다면 신뢰할 수 있다고 할 수 있습니다. 이를 위해서는 시스템이 장애를 감지하고 자동으로 복구하며 수요에 따라 확장할 수 있어야 합니다.
+
+고객은 Kubernetes를 기반으로 사용하여 업무상 중요한 애플리케이션 및 서비스를 안정적으로 운영할 수 있습니다. 그러나 컨테이너 기반 애플리케이션 설계 원칙을 통합하는 것 외에도 워크로드를 안정적으로 실행하려면 신뢰할 수 있는 인프라가 필요합니다. 쿠버네티스에서 인프라는 컨트롤 플레인과 데이터 플레인으로 구성됩니다.
+
+EKS는 가용성과 내결함성을 제공하도록 설계된 프로덕션 등급의 Kubernetes 컨트롤 플레인을 제공합니다.
+
+EKS에서 AWS는 쿠버네티스 컨트롤 플레인의 신뢰성을 책임집니다. EKS는 AWS 리전의 세 가용 영역에서 쿠버네티스 컨트롤 플레인을 실행합니다. 쿠버네티스 API 서버 및 etcd 클러스터의 가용성과 확장성을 자동으로 관리합니다.
+
+데이터 플레인의 신뢰성에 대한 책임은 사용자, 고객, AWS 간에 공유됩니다. EKS는 Kubernetes 데이터 플레인에 대한 세 가지 옵션을 제공합니다. 가장 많이 관리되는 옵션인 Fargate는 데이터 플레인의 프로비저닝 및 확장을 처리합니다. 두 번째 옵션인 관리형 노드 그룹화는 데이터 플레인의 프로비저닝 및 업데이트를 처리합니다. 마지막으로, 자체 관리형 노드는 데이터 플레인에 대한 관리가 가장 적은 옵션입니다. AWS 관리형 데이터 플레인을 더 많이 사용할수록 책임은 줄어듭니다.
+
+[관리형 노드 그룹](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)은 EC2 노드의 프로비저닝 및 수명 주기 관리를 자동화합니다. EKS API (EKS 콘솔, AWS API, AWS CLI, CloudFormation, Terraform 또는 `eksctl` 사용)를 사용하여 관리형 노드를 생성, 확장 및 업그레이드할 수 있습니다. 관리형 노드는 계정에서 EKS에 최적화된 Amazon Linux 2 EC2 인스턴스를 실행하며, SSH 액세스를 활성화하여 사용자 지정 소프트웨어 패키지를 설치할 수 있습니다. 관리형 노드를 프로비저닝하면 여러 가용 영역에 걸쳐 있을 수 있는 EKS 관리형 Auto Scaling 그룹의 일부로 실행되므로 관리형 노드를 생성할 때 제공하는 서브넷을 통해 이를 제어할 수 있습니다. 또한 EKS는 관리형 노드에 자동으로 태그를 지정하여 클러스터 오토스케일러에서 사용할 수 있도록 합니다.
+
+> Amazon EKS는 관리형 노드 그룹의 CVE 및 보안 패치에 대한 공동 책임 모델을 따릅니다. 관리형 노드는 Amazon EKS에 최적화된 AMI들을 실행하므로 Amazon EKS는 버그 수정 시 이러한 AMI들의 패치 버전을 만들 책임이 있습니다. 하지만 이러한 패치가 적용된 AMI 버전을 관리형 노드 그룹에 배포하는 것은 사용자의 책임입니다.
+
+EKS는 업데이트 프로세스를 시작해야 하지만 [노드 업데이트도 관리](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html)합니다. [관리형 노드 업데이트](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html) 프로세스는 EKS 설명서에 설명되어 있습니다.
+
+자체 관리형 노드를 실행하는 경우 [Amazon EKS에 최적화된 Linux AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html)를 사용하여 작업자 노드를 생성할 수 있습니다. AMI와 노드의 패치 및 업그레이드는 사용자가 담당합니다. `eksctl`, CloudFormation 또는 코드형 인프라 도구를 사용하여 자체 관리형 노드를 프로비저닝하는 것이 가장 좋습니다. 이렇게 하면 [자체 관리형 노드 업그레이드](https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html)를 쉽게 할 수 있기 때문입니다. 마이그레이션 프로세스에서는 이전 노드 그룹을 `NoSchedule`로 **taints**하고 새 스택이 기존 포드 워크로드를 수용할 준비가 되면 노드를 **drains**하기 때문에 작업자 노드를 업데이트할 때 [새 노드로 마이그레이션](https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html)하는 것을 고려해 보십시오. 하지만 [자체 관리형 노드의 in-place 업그레이드](https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html)를 수행할 수도 있습니다.
+
+![공동 책임 모델 - Fargate](./images/SRM-Fargate.jpeg)
+
+![공동 책임 모델 - MNG](./images/SRM-MNG.jpeg)
+
+이 가이드에는 EKS 데이터 플레인, Kubernetes 핵심 구성 요소 및 애플리케이션의 신뢰성을 개선하는 데 사용할 수 있는 일련의 권장 사항이 포함되어 있습니다.
+
+## 피드백
+
+이 가이드는 광범위한 EKS/Kubernetes 커뮤니티로부터 직접적인 피드백과 제안을 수집하기 위해 GitHub에 게시 되었습니다. 가이드에 포함시켜야 한다고 생각되는 모범 사례가 있다면 GitHub 리포지토리에 문제를 제출하거나 PR을 제출해 주세요. 서비스에 새로운 기능이 추가되거나 새로운 모범 사례가 개발되면 가이드를 정기적으로 업데이트할 계획입니다.

content/security/docs/compliance.md

@@ -53,3 +53,4 @@ Policy can be thought of as a set of rules for governing behaviors, i.e. behavio
 + [docker-bench-security](https://github.com/docker/docker-bench-security)
 + [AWS Inspector](https://aws.amazon.com/inspector/)
 + [Kubernetes Security Review](https://github.com/kubernetes/community/blob/master/sig-security/security-audit-2019/findings/Kubernetes%20Final%20Report.pdf) A 3rd party security assessment of Kubernetes 1.13.4 (2019)
++ [NeuVector by SUSE](https://www.suse.com/neuvector/) open source, zero-trust container security platform, provides compliance reporting and custom compliance checks

content/security/docs/iam.md

@@ -63,7 +63,7 @@ Once the user's identity has been authenticated by the AWS IAM service, the kube
 
 ### The `aws-auth` ConfigMap
 
-One way Kubernetes integration with AWS authentication can be done is via the `aws-auth` ConfigMap, which resides in the `kube-system` Namespace. It's is responsible for mapping the AWS IAM Identities (Users, Groups, and Roles) authentication, to Kubernates role-based access control (RBAC) authorization. The `aws-auth` ConfigMap is automatically created in your Amazon EKS cluster during its provisioning phase. It was initially created to allow nodes to join your cluster, but as mentioned you can also use this ConfigMap to add RBACs access to IAM principals.
+One way Kubernetes integration with AWS authentication can be done is via the `aws-auth` ConfigMap, which resides in the `kube-system` Namespace. It is responsible for mapping the AWS IAM Identities (Users, Groups, and Roles) authentication, to Kubernetes role-based access control (RBAC) authorization. The `aws-auth` ConfigMap is automatically created in your Amazon EKS cluster during its provisioning phase. It was initially created to allow nodes to join your cluster, but as mentioned you can also use this ConfigMap to add RBACs access to IAM principals.
 
 To check your cluster's `aws-auth` ConfigMap, you can use the following command.
 
@@ -102,7 +102,7 @@ To manage permissions, you can edit the `aws-auth` ConfigMap adding or removing
 
 ### Cluster Access Manager
 
-Cluster Access Manager, now the preferred way to manage access of AWS IAM principals to Amazon EKS clusters, is a functionality of the AWS API as is an opt-in feature for EKS v1.23 and later clusters (new or existing). It simplifies identity mapping between AWS IAM and Kubernetes RBACs, eliminating the need to switch between AWS and Kubernetes APIs or editing the the `aws-auth` ConfigMap for access management, reducing operational overhead, and helping address misconfigurations. The tool also enables cluster administrators to revoke or refine `cluster-admin` permissions automatically granted to the AWS IAM principal used to create the cluster.
+Cluster Access Manager, now the preferred way to manage access of AWS IAM principals to Amazon EKS clusters, is a functionality of the AWS API and is an opt-in feature for EKS v1.23 and later clusters (new or existing). It simplifies identity mapping between AWS IAM and Kubernetes RBACs, eliminating the need to switch between AWS and Kubernetes APIs or editing the the `aws-auth` ConfigMap for access management, reducing operational overhead, and helping address misconfigurations. The tool also enables cluster administrators to revoke or refine `cluster-admin` permissions automatically granted to the AWS IAM principal used to create the cluster.
 
 This API relies on two concepts:
 
@@ -111,9 +111,9 @@ This API relies on two concepts:
 
 > At launch Amazon EKS supports only predefined and AWS managed policies. Access policies are not IAM entities and are defined and managed by Amazon EKS.
 
-Cluster Access Manager allows the combiniation of upstream RBAC with Access Policies supporting allow and pass (but not deny) on Kubernetes AuthZ decisions regarding API server requests. A deny descision will happen when both, the upstream RBAC and Amazon EKS authorizers can't determine the outcome of a request evaluation.
+Cluster Access Manager allows the combination of upstream RBAC with Access Policies supporting allow and pass (but not deny) on Kubernetes AuthZ decisions regarding API server requests. A deny descision will happen when both, the upstream RBAC and Amazon EKS authorizers can't determine the outcome of a request evaluation.
 
-With this feature, Amazon EKS support three modes of authentication:
+With this feature, Amazon EKS supports three modes of authentication:
 
 1. `CONFIG_MAP` to continue using `aws-auth` configMap exclusively.
 2. `API_AND_CONFIG_MAP` to source authenticated IAM principals from both EKS Access Entry APIs and the `aws-auth` configMap, prioritizing the Access Entries. Ideal to migrate existing `aws-auth` permissions to Access Entries.

content/security/docs/image.md

@@ -214,3 +214,4 @@ RUN apt-get update && apt-get install -y \
 * [Notary](https://github.com/theupdateframework/notary) A project for signing container images
 * [Notary v2](https://github.com/notaryproject/nv2)
 * [Grafeas](https://grafeas.io/) An open artifact metadata API to audit and govern your software supply chain
+* [NeuVector by SUSE](https://www.suse.com/neuvector/) open source, zero-trust container security platform, provides container, image and registry scanning for vulnerabilities, secrets and compliance.

content/security/docs/incidents.md

@@ -120,6 +120,7 @@ Periodically attacking your own cluster can help you discover vulnerabilities an
 + [Gremlin](https://www.gremlin.com/product/#kubernetes), a chaos engineering toolkit that you can use to simulate attacks against your applications and infrastructure. 
 + [Attacking and Defending Kubernetes Installations](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2019/findings/AtredisPartners_Attacking_Kubernetes-v1.0.pdf)
 + [kubesploit](https://www.cyberark.com/resources/threat-research-blog/kubesploit-a-new-offensive-tool-for-testing-containerized-environments)
++ [NeuVector by SUSE](https://www.suse.com/neuvector/) open source, zero-trust container security platform, provides vulnerability- and risk reporting as well as security event notification
 
 ## Videos
 + [Advanced Persistent Threats](https://www.youtube.com/watch?v=CH7S5rE3j8w)

content/security/docs/network.md

@@ -531,3 +531,4 @@ kubectl apply -f istio-custom-config.yaml
 + [Verifying Service Mesh TLS in Kubernetes, Using ksniff and Wireshark](https://itnext.io/verifying-service-mesh-tls-in-kubernetes-using-ksniff-and-wireshark-2e993b26bf95)
 + [ksniff](https://github.com/eldadru/ksniff)
 + [egress-operator](https://github.com/monzo/egress-operator) An operator and DNS plugin to control egress traffic from your cluster without protocol inspection
++ [NeuVector by SUSE](https://www.suse.com/neuvector/) open source, zero-trust container security platform, provides policy network rules, data loss prevention (DLP), web application firewall (WAF) and network threat signatures.

content/security/docs/pods.md

@@ -483,3 +483,4 @@ Policy-as-code and Pod Security Standards can be used to enforce this behavior.
 + [Policy based countermeasures: part 1](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-1/)
 + [Policy based countermeasures: part 2](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-2/)
 + [Pod Security Policy Migrator](https://appvia.github.io/psp-migration/) a tool that converts PSPs to OPA/Gatekeeper, KubeWarden, or Kyverno policies
++ [NeuVector by SUSE](https://www.suse.com/neuvector/) open source, zero-trust container security platform, provides process and filesystem policies as well as admission control rules.

content/security/docs/runtime.md

@@ -71,3 +71,4 @@ Pod Security Policies offer a lot of different ways to improve your security pos
 + [Stackrox](https://www.stackrox.com/use-cases/threat-detection/)
 + [Sysdig Secure](https://sysdig.com/products/kubernetes-security/)
 + [Prisma](https://docs.paloaltonetworks.com/cn-series)
++ [NeuVector by SUSE](https://www.suse.com/neuvector/) open source, zero-trust container security platform, provides process profile rules and file access rules.

content/upgrades/index.md

@@ -203,6 +203,75 @@ Running the check against static manifest files is generally more accurate. If r
 
 A deprecated Kubernetes API does not mean the API has been removed. You should check the [Kubernetes Deprecation Policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) to understand how API removal affects your workloads.
 
+### Cluster Insights
+[Cluster Insights](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html) is a feature that provides findings on issues that may impact the ability to upgrade an EKS cluster to newer versions of Kubernetes. These findings are curated and managed by Amazon EKS and offer recommendations on how to remediate them. By leveraging Cluster Insights, you can minimize the effort spent to upgrade to newer Kubernetes versions.
+
+To view insights of an EKS cluster, you can run the command:
+```
+aws eks list-insights --region <region-code> --cluster-name <my-cluster>
+
+{
+    "insights": [
+        {
+            "category": "UPGRADE_READINESS", 
+            "name": "Deprecated APIs removed in Kubernetes v1.29", 
+            "insightStatus": {
+                "status": "PASSING", 
+                "reason": "No deprecated API usage detected within the last 30 days."
+            }, 
+            "kubernetesVersion": "1.29", 
+            "lastTransitionTime": 1698774710.0, 
+            "lastRefreshTime": 1700157422.0, 
+            "id": "123e4567-e89b-42d3-a456-579642341238", 
+            "description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes v1.29. Upgrading your cluster before migrating to the updated APIs supported by v1.29 could cause application impact."
+        }
+    ]
+}
+```
+
+For a more descriptive output about the insight received, you can run the command:
+```
+aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>
+```
+
+You also have the option to view insights in the [Amazon EKS Console](https://console.aws.amazon.com/eks/home#/clusters). After selecting your cluster from the cluster list, insight findings are located under the ```Upgrade Insights``` tab.
+
+If you find a cluster insight with `"status": ERROR`, you must address the issue prior to performing the cluster upgrade. Run the `aws eks describe-insight` command which will share the following remediation advice: 
+
+Resources affected:
+```
+"resources": [
+      {
+        "insightStatus": {
+          "status": "ERROR"
+        },
+        "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null"
+      }
+]
+```
+
+APIs deprecated:
+```
+"deprecationDetails": [
+      {
+        "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas", 
+        "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas", 
+        "stopServingVersion": "1.29", 
+        "clientStats": [], 
+        "startServingReplacementVersion": "1.26"
+      }
+]
+```
+
+Recommended action to take:
+```
+"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."
+```
+
+Utilizing cluster insights through the EKS Console or CLI help speed the process of successfully upgrading EKS cluster versions. Learn more with the following resources:
+* [Official EKS Docs](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html)
+* [Cluster Insights launch blog](https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/).
+
 ### Kube-no-trouble
 
 [Kube-no-trouble](https://github.com/doitintl/kube-no-trouble) is an open source command line utility with the command `kubent`. When you run `kubent` without any arguments it will use your current KubeConfig context and scan the cluster and print a report with what APIs will be deprecated and removed.