diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 6172b28d3..d05776c71 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -398,7 +398,8 @@ - [Az - Enumeration Tools](pentesting-cloud/azure-security/az-enumeration-tools.md) - [Az - Unauthenticated Enum & Initial Entry](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md) - [Az - OAuth Apps Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md) - - [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md) + - [Az - Storage Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-storage-unauth.md) + - [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unauth.md) - [Az - Device Code Authentication Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md) - [Az - Password Spraying](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying.md) - [Az - Services](pentesting-cloud/azure-security/az-services/README.md) diff --git a/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md b/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md index f510b1a59..35dda4ac1 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md +++ b/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md @@ -17,11 +17,11 @@ Learn & practice GCP Hacking: -n -- sh ``` ### port-forward -이 권한은 **지정된 포드의 하나의 포트에 하나의 로컬 포트를 포워딩할 수 있게 해줍니다**. 이는 포드 내에서 실행 중인 애플리케이션을 쉽게 디버깅할 수 있도록 하기 위한 것이지만, 공격자는 이를 악용하여 포드 내의 흥미로운 (예: DB) 또는 취약한 애플리케이션 (웹?)에 접근할 수 있습니다: +이 권한은 **하나의 로컬 포트를 지정된 포드의 하나의 포트로 포워딩할 수 있게 해줍니다**. 이는 포드 내에서 실행 중인 애플리케이션을 쉽게 디버깅할 수 있도록 하기 위한 것이지만, 공격자는 이를 악용하여 포드 내의 흥미로운 (예: DB) 또는 취약한 애플리케이션 (웹?)에 접근할 수 있습니다: ``` kubectl port-forward pod/mypod 5000:5000 ``` ### 호스트 쓰기 가능한 /var/log/ 탈출 [**이 연구에서 언급된 바와 같이**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), **호스트의 `/var/log/` 디렉토리가 마운트된** 포드에 접근하거나 생성할 수 있다면, **컨테이너에서 탈출할 수 있습니다**.\ -이는 기본적으로 **Kube-API가 컨테이너의 로그를 가져오려고 할 때** (`kubectl logs ` 사용) **포드의 `0.log`** 파일을 **Kubelet** 서비스의 `/logs/` 엔드포인트를 사용하여 요청하기 때문입니다.\ +이는 기본적으로 **Kube-API가 컨테이너의 로그를 가져오려고 할 때** ( `kubectl logs ` 사용) **포드의 `0.log`** 파일을 **Kubelet** 서비스의 `/logs/` 엔드포인트를 사용하여 요청하기 때문입니다.\ Kubelet 서비스는 기본적으로 **컨테이너의 `/var/log` 파일 시스템을 노출하는** `/logs/` 엔드포인트를 노출합니다. -따라서 **컨테이너의 /var/log/ 폴더에 쓰기 접근 권한이 있는** 공격자는 이 행동을 두 가지 방법으로 악용할 수 있습니다: +따라서 **컨테이너의 /var/log/ 폴더에 쓰기 접근 권한이 있는** 공격자는 이 행동을 2가지 방법으로 악용할 수 있습니다: - 컨테이너의 `0.log` 파일을 수정하여 (보통 `/var/logs/pods/namespace_pod_uid/container/0.log`에 위치) **예를 들어 `/etc/shadow`를 가리키는 심볼릭 링크**로 만들 수 있습니다. 그러면 다음과 같이 호스트의 shadow 파일을 유출할 수 있습니다: ```bash @@ -219,7 +219,7 @@ kubectl logs escaper --tail=2 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n" # Keep incrementing tail to exfiltrate the whole file ``` -- 공격자가 **`nodes/log`를 읽을 수 있는 권한을 가진 주체**를 제어하는 경우, 그는 단순히 `/host-mounted/var/log/sym`에 `/`에 대한 **symlink**를 생성할 수 있으며, **`https://:10250/logs/sym/`에 접근할 때 호스트의 루트** 파일 시스템을 나열할 수 있습니다 (symlink를 변경하면 파일에 대한 접근을 제공할 수 있습니다). +- 공격자가 **`nodes/log`를 읽을 수 있는 권한**을 가진 주체를 제어하는 경우, 그는 `/host-mounted/var/log/sym`에 `/`에 대한 **symlink**를 생성할 수 있으며, **`https://:10250/logs/sym/`에 접근할 때 호스트의 루트** 파일 시스템을 나열할 수 있습니다 (symlink를 변경하면 파일에 대한 접근이 가능할 수 있습니다). ```bash curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/' bin @@ -231,11 +231,11 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https:// lib [...] ``` -**실험실과 자동화된 익스플로잇은** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)에서 찾을 수 있습니다. +**실험실 및 자동화된 익스플로잇은** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)에서 찾을 수 있습니다. #### readOnly 보호 우회 -운이 좋다면, 고급 권한을 가진 `CAP_SYS_ADMIN` 기능이 사용 가능할 때, 폴더를 rw로 다시 마운트할 수 있습니다: +운이 좋다면, 고급 권한을 가진 `CAP_SYS_ADMIN` 기능이 사용 가능할 경우, 폴더를 rw로 다시 마운트할 수 있습니다: ```bash mount -o rw,remount /hostlogs/ ``` @@ -312,13 +312,14 @@ https://:/api/v1/namespaces/kube-system/secrets/ ``` ### Listing Secrets -**비밀을 나열할 수 있는 권한은 공격자가 실제로 비밀을 읽을 수 있게 할 수 있습니다** REST API 엔드포인트에 접근하여: +**비밀 목록을 나열할 수 있는 권한은 공격자가 실제로 비밀을 읽을 수 있게 할 수 있습니다** REST API 엔드포인트에 접근하여: ```bash curl -v -H "Authorization: Bearer " https://:/api/v1/namespaces/kube-system/secrets/ ``` ### Creating and Reading Secrets -Kubernetes의 **kubernetes.io/service-account-token** 유형의 비밀은 serviceaccount 토큰을 저장하는 특별한 종류의 비밀입니다. 비밀을 생성하고 읽을 수 있는 권한이 있고 serviceaccount의 이름을 알고 있다면, 다음과 같이 비밀을 생성한 후 피해자의 serviceaccount 토큰을 훔칠 수 있습니다: +Kubernetes의 **kubernetes.io/service-account-token** 유형의 비밀은 serviceaccount 토큰을 저장하는 특별한 종류의 비밀입니다. +비밀을 생성하고 읽을 수 있는 권한이 있고 serviceaccount의 이름을 알고 있다면, 다음과 같이 비밀을 생성한 후 피해자의 serviceaccount 토큰을 훔칠 수 있습니다: ```yaml apiVersion: v1 kind: Secret @@ -381,7 +382,7 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso ### 비밀 읽기 – 토큰 ID 무작위 대입 -읽기 권한이 있는 토큰을 소유한 공격자는 이를 사용하기 위해 비밀의 정확한 이름이 필요하지만, 더 넓은 _**비밀 나열**_ 권한과는 달리 여전히 취약점이 존재합니다. 시스템의 기본 서비스 계정은 나열할 수 있으며, 각 계정은 비밀과 연결되어 있습니다. 이러한 비밀은 이름 구조가 있으며: 정적 접두사 뒤에 무작위의 다섯 자리 알파벳 숫자 토큰(특정 문자를 제외하고)이 옵니다. [소스 코드](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)에 따르면. +읽기 권한이 있는 토큰을 소유한 공격자는 이를 사용하기 위해 비밀의 정확한 이름이 필요하지만, 더 넓은 _**비밀 나열**_ 권한과는 달리 여전히 취약점이 존재합니다. 시스템의 기본 서비스 계정은 나열할 수 있으며, 각 계정은 비밀과 연결되어 있습니다. 이러한 비밀은 이름 구조가 있으며: 정적 접두사 뒤에 특정 문자를 제외한 무작위 5자리 알파벳 숫자 토큰이 옵니다. 이는 [소스 코드](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)에 따라 결정됩니다. 토큰은 전체 알파벳 숫자 범위가 아닌 제한된 27자 집합(`bcdfghjklmnpqrstvwxz2456789`)에서 생성됩니다. 이 제한으로 인해 가능한 조합의 총 수는 14,348,907(27^5)로 줄어듭니다. 따라서 공격자는 몇 시간 내에 토큰을 추론하기 위해 무작위 대입 공격을 실행할 수 있으며, 이는 민감한 서비스 계정에 접근하여 권한 상승으로 이어질 수 있습니다. @@ -389,7 +390,7 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso `certificatesigningrequests` 리소스에서 **`create`** 동사를 가지고 있다면 (또는 최소한 `certificatesigningrequests/nodeClient`에서). **새 노드의** 새로운 CeSR을 **생성**할 수 있습니다. -[문서에 따르면 이 요청을 자동으로 승인하는 것이 가능합니다](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), 따라서 이 경우 **추가 권한이 필요하지 않습니다**. 그렇지 않다면 요청을 승인할 수 있어야 하며, 이는 `certificatesigningrequests/approval`에서 업데이트하고 `signers`에서 리소스 이름 `/` 또는 `/*`로 `approve`해야 함을 의미합니다. +[문서에 따르면 이 요청을 자동으로 승인하는 것이 가능합니다](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), 따라서 이 경우 **추가 권한이 필요하지 않습니다**. 그렇지 않다면 요청을 승인할 수 있어야 하며, 이는 `certificatesigningrequests/approval`에서 업데이트하고 `signers`에서 `/` 또는 `/*`로 `approve`해야 함을 의미합니다. 모든 필요한 권한이 포함된 **역할의 예**는: ```yaml @@ -422,7 +423,7 @@ resourceNames: verbs: - approve ``` -새로운 노드 CSR이 승인되었으므로, 노드의 특별한 권한을 **악용**하여 **비밀을 훔치고** **권한을 상승**시킬 수 있습니다. +새로운 노드 CSR이 승인되었으므로, 노드의 특별 권한을 **악용**하여 **비밀을 훔치고** **권한을 상승**시킬 수 있습니다. [**이 게시물**](https://www.4armed.com/blog/hacking-kubelet-on-gke/)과 [**이 게시물**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)에서 GKE K8s TLS 부트스트랩 구성은 **자동 서명**으로 설정되어 있으며, 이를 악용하여 새로운 K8s 노드의 자격 증명을 생성한 다음 이를 사용하여 비밀을 훔쳐 권한을 상승시킵니다.\ **언급된 권한이 있다면 같은 작업을 수행할 수 있습니다.** 첫 번째 예제는 새로운 노드가 컨테이너 내부의 비밀에 접근하는 것을 방지하는 오류를 우회합니다. 왜냐하면 **노드는 자신에게 마운트된 컨테이너의 비밀만 접근할 수 있기 때문입니다.** @@ -481,11 +482,11 @@ groups: ### GKE에서의 권한 상승 -**GCP 주체에 K8s 권한을 부여하는 방법은 2가지**가 있습니다. 어떤 경우든 주체는 클러스터에 접근하기 위한 자격 증명을 수집할 수 있도록 **`container.clusters.get`** 권한이 필요하며, 그렇지 않으면 **자신의 kubectl 구성 파일을 생성해야** 합니다 (다음 링크를 따르세요). +GCP 주체에게 K8s 권한을 부여하는 **2가지 방법**이 있습니다. 어떤 경우든 주체는 클러스터에 접근하기 위한 자격 증명을 수집할 수 있도록 **`container.clusters.get`** 권한이 필요하며, 그렇지 않으면 **자신의 kubectl 구성 파일을 생성해야** 합니다 (다음 링크를 따르세요). > [!WARNING] > K8s API 엔드포인트와 통신할 때 **GCP 인증 토큰이 전송됩니다**. 그러면 GCP는 K8s API 엔드포인트를 통해 먼저 **주체**(이메일로)가 클러스터 내에 **접근 권한이 있는지** 확인한 다음, **GCP IAM을 통해 접근 권한이 있는지** 확인합니다.\ -> 이 중 **하나라도** **참이면**, 응답을 받게 됩니다. **아니면** **GCP IAM을 통해 권한을 부여하라는** 오류가 발생합니다. +> 만약 **어떤** 것이 **참**이라면, 응답을 받을 것입니다. 그렇지 않으면 **GCP IAM을 통해 권한을 부여하라는** 오류가 발생합니다. 그런 다음 첫 번째 방법은 **GCP IAM**을 사용하는 것이며, K8s 권한은 **상응하는 GCP IAM 권한**이 있으며, 주체가 이를 가지고 있다면 사용할 수 있습니다. @@ -493,7 +494,7 @@ groups: ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md {{#endref}} -두 번째 방법은 **클러스터 내에서 K8s 권한을 부여하는 것**으로, 사용자를 **이메일**로 식별합니다 (GCP 서비스 계정 포함). +두 번째 방법은 **클러스터 내에서 K8s 권한을 부여하는** 것으로, 사용자를 **이메일**로 식별합니다 (GCP 서비스 계정 포함). ### 서비스 계정 토큰 생성 @@ -505,13 +506,13 @@ groups: ### ValidatingWebhookConfigurations 또는 MutatingWebhookConfigurations -`validatingwebhookconfigurations` 또는 `mutatingwebhookconfigurations`에 대해 `create`, `update` 또는 `patch`의 동사를 가진 주체는 **이러한 webhookconfigurations 중 하나를 생성**하여 **권한을 상승**시킬 수 있습니다. +`validatingwebhookconfigurations` 또는 `mutatingwebhookconfigurations`에 대해 `create`, `update` 또는 `patch`의 동사를 가진 주체는 **권한 상승**을 위해 **이러한 webhookconfigurations 중 하나를 생성할 수** 있습니다. [`mutatingwebhookconfigurations` 예제는 이 게시물의 이 섹션을 확인하세요](#malicious-admission-controller). ### 권한 상승 -다음 섹션에서 읽을 수 있듯이: [**내장된 권한 상승 방지**](#built-in-privileged-escalation-prevention), 주체는 자신이 새로운 권한을 가지지 않고는 역할이나 클러스터 역할을 업데이트하거나 생성할 수 없습니다. 단, **`roles`** 또는 **`clusterroles`**에 대해 **동사 `escalate`**를 가진 경우는 예외입니다.\ +다음 섹션에서 읽을 수 있듯이: [**내장된 권한 상승 방지**](#built-in-privileged-escalation-prevention), 주체는 자신이 새로운 권한을 가지지 않고는 역할이나 클러스터 역할을 업데이트하거나 생성할 수 없습니다. 단, **`roles`** 또는 **`clusterroles`**에 대해 **`escalate`** 동사를 가진 경우는 예외입니다.\ 그렇다면 그는 더 나은 권한을 가진 새로운 역할, 클러스터 역할을 업데이트/생성할 수 있습니다. ### 노드 프록시 @@ -522,11 +523,11 @@ groups: ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md {{#endref}} -[**Kubelet API에 인증된 상태로 RCE를 얻는 방법은 여기에서 확인하세요**](../pentesting-kubernetes-services/index.html#kubelet-rce). +[**Kubelet API에 인증된 상태로 RCE를 얻는 방법은 여기**](../pentesting-kubernetes-services/index.html#kubelet-rce)에서 확인할 수 있습니다. ### pods 삭제 + 스케줄링 불가능한 노드 -**pods를 삭제**할 수 있는 주체(`pods` 리소스에 대한 `delete` 동사) 또는 **pods를 퇴거**할 수 있는 주체(`pods/eviction` 리소스에 대한 `create` 동사) 또는 **pod 상태를 변경**할 수 있는 주체(`pods/status`에 대한 접근)와 **다른 노드를 스케줄링 불가능하게 만들 수 있는 주체**(`nodes/status`에 대한 접근) 또는 **노드를 삭제**할 수 있는 주체(`nodes` 리소스에 대한 `delete` 동사)와 pod에 대한 제어권을 가진 주체는 **다른 노드에서 pods를 훔쳐** **손상된** **노드**에서 **실행**되도록 할 수 있으며, 공격자는 이러한 pods에서 **토큰을 훔칠** 수 있습니다. +**pods를 삭제**할 수 있는 주체(`pods` 리소스에 대한 `delete` 동사), 또는 **pods를 퇴거**할 수 있는 주체(`pods/eviction` 리소스에 대한 `create` 동사), 또는 **pod 상태를 변경**할 수 있는 주체(`pods/status`에 대한 접근)와 **다른 노드를 스케줄링 불가능하게 만들 수 있는** 주체(`nodes/status`에 대한 접근) 또는 **노드를 삭제**할 수 있는 주체(`nodes` 리소스에 대한 `delete` 동사)와 pod에 대한 제어권을 가진 주체는 **다른 노드에서 pods를 훔쳐** **손상된** **노드**에서 **실행**되도록 할 수 있으며, 공격자는 이러한 pods에서 **토큰을 훔칠** 수 있습니다. ```bash patch_node_capacity(){ curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]' @@ -549,9 +550,9 @@ kubectl delete pods -n kube-system Kubernetes는 권한 상승을 방지하기 위한 [내장 메커니즘](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)을 가지고 있습니다. -이 시스템은 **사용자가 역할이나 역할 바인딩을 수정하여 권한을 상승시킬 수 없도록 보장합니다**. 이 규칙의 시행은 API 수준에서 이루어지며, RBAC 인가자가 비활성화되어 있을 때도 보호 장치를 제공합니다. +이 시스템은 **사용자가 역할이나 역할 바인딩을 수정하여 권한을 상승시킬 수 없도록 보장합니다**. 이 규칙의 시행은 API 수준에서 이루어지며, RBAC 인증자가 비활성화되어 있을 때도 안전 장치를 제공합니다. -규칙은 **사용자가 역할을 생성하거나 업데이트할 수 있는 것은 그 역할이 포함하는 모든 권한을 보유하고 있을 때만 가능하다고 명시합니다**. 또한, 사용자의 기존 권한 범위는 생성하거나 수정하려는 역할의 범위와 일치해야 합니다: ClusterRoles의 경우 클러스터 전체에 대해, Roles의 경우 동일한 네임스페이스(또는 클러스터 전체)에 대해 제한됩니다. +규칙은 **사용자가 역할을 생성하거나 업데이트할 수 있는 것은 그 역할이 포함하는 모든 권한을 보유하고 있을 때만 가능하다고 명시합니다**. 또한 사용자의 기존 권한 범위는 생성하거나 수정하려는 역할의 범위와 일치해야 합니다: ClusterRoles의 경우 클러스터 전체에 대해, Roles의 경우 동일한 네임스페이스(또는 클러스터 전체)에 대해 제한됩니다. > [!WARNING] > 이전 규칙에 대한 예외가 있습니다. 주체가 **`roles`** 또는 **`clusterroles`**에 대해 **`escalate`** 동사를 가지고 있다면, 자신이 권한을 가지고 있지 않더라도 역할과 클러스터 역할의 권한을 증가시킬 수 있습니다. @@ -567,9 +568,9 @@ Rolebindings를 생성할 수 있는 권한은 사용자가 **서비스 계정 ### 사이드카 프록시 앱 -기본적으로 파드 간의 통신에는 암호화가 없습니다. 상호 인증, 양방향, 파드 간. +기본적으로 파드 간의 통신에는 암호화가 없습니다. 상호 인증, 양방향, 파드 대 파드. -#### 사이드카 프록시 앱 생성 +#### 사이드카 프록시 앱 만들기 .yam 파일을 생성하세요. ```bash diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md b/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md index d1af23651..d3182d57d 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md @@ -12,7 +12,7 @@ Kubernetes 환경 내에서 포드를 손상시킨 경우, 현재 K8 환경에 ### Service Account Tokens -계속하기 전에 Kubernetes에서 서비스가 무엇인지 모른다면 **이 링크를 따라가고 Kubernetes 아키텍처에 대한 정보를 최소한 읽어보는 것을 권장합니다.** +계속하기 전에 Kubernetes에서 서비스가 무엇인지 모른다면 **이 링크를 따라가서 Kubernetes 아키텍처에 대한 정보를 최소한 읽어보는 것을 권장합니다.** Kubernetes [문서](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)에서 인용: @@ -68,7 +68,7 @@ K8s 환경을 열거하기 위해 필요한 몇 가지 사항은 다음과 같 이 세부 정보를 통해 **Kubernetes를 열거할 수 있습니다**. **API**가 어떤 이유로 **인터넷을 통해 접근 가능**하다면, 해당 정보를 다운로드하고 호스트에서 플랫폼을 열거할 수 있습니다. -그러나 일반적으로 **API 서버는 내부 네트워크에 있습니다**, 따라서 손상된 기계를 통해 **터널을 생성**하여 내 기계에서 접근해야 하며, 또는 **`kubectl`** 바이너리를 **업로드**하거나 **`curl/wget/anything`**을 사용하여 API 서버에 대한 원시 HTTP 요청을 수행할 수 있습니다. +그러나 일반적으로 **API 서버는 내부 네트워크에** 있으므로, 손상된 기계를 통해 **터널을 생성**하여 자신의 기기에서 접근해야 하며, 또는 **`kubectl`** 바이너리를 **업로드**하거나 **`curl/wget/anything`**을 사용하여 API 서버에 대한 원시 HTTP 요청을 수행할 수 있습니다. ### Differences between `list` and `get` verbs @@ -91,7 +91,7 @@ GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name} [DEPRECATED] GET /apis/apps/v1/watch/namespaces/{namespace}/deployments [DEPRECATED] GET /apis/apps/v1/watch/deployments [DEPRECATED] ``` -그들은 스트리밍 연결을 열어 Deployment의 전체 매니페스트를 반환합니다. 매니페스트가 변경되거나 새로 생성될 때마다 반환됩니다. +그들은 변경될 때마다(또는 새로 생성될 때마다) 배포의 전체 매니페스트를 반환하는 스트리밍 연결을 엽니다. > [!CAUTION] > 다음 `kubectl` 명령은 객체를 나열하는 방법을 나타냅니다. 데이터를 액세스하려면 `get` 대신 `describe`를 사용해야 합니다. @@ -109,7 +109,7 @@ alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\"" # if kurl is still got cert Error, using -k option to solve this. ``` > [!WARNING] -> 기본적으로 pod는 **`kubernetes.default.svc`** 도메인 이름에서 **kube-api 서버**에 **접근**할 수 있으며, **`/etc/resolv.config`**에서 kube 네트워크를 볼 수 있습니다. 여기에서 kubernetes DNS 서버의 주소를 찾을 수 있습니다 (같은 범위의 ".1"은 kube-api 엔드포인트입니다). +> 기본적으로 pod는 **kube-api 서버**에 **`kubernetes.default.svc`** 도메인 이름으로 **접근**할 수 있으며, **`/etc/resolv.config`**에서 kube 네트워크를 확인할 수 있습니다. 여기에서 kubernetes DNS 서버의 주소를 찾을 수 있습니다(같은 범위의 ".1"이 kube-api 엔드포인트입니다). ### Using kubectl @@ -150,7 +150,7 @@ kubectl config set-context --current --namespace= {{#endtab }} {{#endtabs }} -사용자 자격 증명을 훔쳤다면 **로컬에서 구성할 수** 있습니다: +사용자 자격 증명을 훔쳤다면 **로컬에서 구성할 수** 있습니다. 다음과 같은 방법을 사용하세요: ```bash kubectl config set-credentials USER_NAME \ --auth-provider=oidc \ @@ -231,7 +231,7 @@ kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clu ### 네임스페이스 가져오기 -Kubernetes는 동일한 물리적 클러스터에 의해 지원되는 **다수의 가상 클러스터**를 지원합니다. 이러한 가상 클러스터를 **네임스페이스**라고 합니다. +Kubernetes는 동일한 물리적 클러스터를 기반으로 하는 **다수의 가상 클러스터**를 지원합니다. 이러한 가상 클러스터를 **네임스페이스**라고 합니다. {{#tabs }} {{#tab name="kubectl" }} @@ -309,7 +309,7 @@ kurl -v https://$APISERVER/api/v1/namespaces//deployments/ ### Get Pods -Pods는 실제 **컨테이너**로, **실행**될 것입니다. +Pods는 실제로 **실행**될 **컨테이너**입니다. {{#tabs }} {{#tab name="kubectl" }} @@ -347,7 +347,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/default/services/ ### 노드 가져오기 -클러스터 내에 구성된 모든 **노드**를 가져옵니다. +클러스터 내에 **구성된 모든 노드**를 가져옵니다. {{#tabs }} {{#tab name="kubectl" }} @@ -449,7 +449,7 @@ k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm' {{#endtab }} {{#endtabs }} -### **Pod 소비 확인하기** +### **Pod 소비량 가져오기** {{#tabs }} {{#tab name="kubectl" }} @@ -461,11 +461,11 @@ k top pod --all-namespaces ## kubectl을 사용하지 않고 클러스터와 상호작용하기 -Kubernetes 제어 평면이 REST-ful API를 노출하므로, HTTP 요청을 수동으로 작성하고 **curl** 또는 **wget**과 같은 다른 도구를 사용하여 보낼 수 있습니다. +Kubernetes 제어 평면이 REST-ful API를 노출하므로, HTTP 요청을 수동으로 작성하고 **curl** 또는 **wget**과 같은 다른 도구를 사용하여 전송할 수 있습니다. ### 포드에서 탈출하기 -새 포드를 생성할 수 있다면, 이를 통해 노드로 탈출할 수 있습니다. 이를 위해서는 yaml 파일을 사용하여 새 포드를 생성하고, 생성된 포드로 전환한 다음 노드의 시스템으로 chroot해야 합니다. 기존 포드를 yaml 파일의 참조로 사용할 수 있으며, 이들은 기존 이미지와 경로를 표시합니다. +새 포드를 생성할 수 있다면, 이를 통해 노드로 탈출할 수 있습니다. 이를 위해서는 yaml 파일을 사용하여 새 포드를 생성하고, 생성된 포드로 전환한 다음 노드의 시스템으로 chroot해야 합니다. 이미 존재하는 포드를 yaml 파일의 참조로 사용할 수 있으며, 이들은 기존 이미지와 경로를 표시합니다. ```bash kubectl get pod [-n ] -o yaml ``` @@ -549,7 +549,7 @@ volumes: hostPath: path: / ``` -curl로 포드 생성: +curl을 사용하여 포드를 생성합니다: ```bash CONTROL_PLANE_HOST="" TOKEN=""