1. Στόχος της αξιολόγησης

Αυτή η αξιολόγηση ελέγχει αν μπορείτε να εξετάζετε δομημένα τους κινδύνους Kubernetes, να εφαρμόζετε hardening σε workloads, να διατυπώνετε policies και να τεκμηριώνετε το incident response. Η έμφαση είναι σε threat modeling, API Server και Control Plane, RBAC, ServiceAccounts, Pod Security Standards, SecurityContext, NetworkPolicy, supply chain, Admission Control, ασφάλεια Secrets, Runtime Detection, Compliance Evidence και Incident Response.

Μετά την αξιολόγηση πρέπει να είναι σαφές ότι μπορείτε να:

• χωρίζετε τις επιφάνειες επίθεσης Kubernetes σε API, Nodes, workloads, δίκτυο, Secrets και supply chain,
• εντοπίζετε RBAC permissions και διαδρομές privilege escalation,
• περιορίζετε συνειδητά το αυτόματο mount των ServiceAccount tokens,
• αξιολογείτε πρακτικά Pod Security Standards και SecurityContext,
• διατυπώνετε NetworkPolicies με default deny, πρόσβαση DNS και στοχευμένη πρόσβαση εφαρμογών,
• αξιολογείτε προέλευση image, tag, digest, scan, SBOM και κατάσταση υπογραφής,
• ταξινομείτε Admission Policies σε audit/warn/enforce mode,
• περιγράφετε ρεαλιστικά τη διαχείριση και το rotation των Secrets,
• μετατρέπετε runtime signals και audit evidence σε ενέργειες,
• τεκμηριώνετε incident response για παραβιασμένο Pod και διαρροή Secret.

2. Προαπαιτούμενα και επιτρεπόμενοι πόροι

Χρειάζεστε:

• ένα lab cluster,
• kubectl,
• δικαιώματα δημιουργίας Namespaces, ServiceAccounts, RBAC, NetworkPolicies και δοκιμαστικών workloads,
• προαιρετικά Kyverno, OPA Gatekeeper ή ValidatingAdmissionPolicy,
• προαιρετικά Trivy, Grype, Cosign ή αντίστοιχα εργαλεία supply chain,
• προαιρετικά Falco, Tetragon, Tracee ή αντίστοιχες πηγές runtime signals.

Επιτρέπονται:

• η επίσημη τεκμηρίωση Kubernetes,
• το υλικό του workshop,
• οι δικές σας σημειώσεις,
• security checklists και εσωτερικά policy templates,
• kubectl auth can-i, kubectl describe, events, logs και policy reports.

Δεν επιτρέπονται:

• πραγματικά production Secrets ή δεδομένα πελατών,
• πραγματικά registry ή cloud credentials,
• καταστροφικές ενέργειες σε Node ή cluster χωρίς έγκριση για το lab,
• εσκεμμένη exfiltration ή ενέργειες επίθεσης εκτός lab,
• αλλαγές σε production clusters.

Προτεινόμενο Namespace:

export NS=exam-security

3. Σενάριο

Μια υποδειγματική εφαρμογή checkout-api εκτελείται στο Namespace shop-prod. Ο έλεγχος εντοπίζει:

• Το Deployment χρησιμοποιεί το ServiceAccount checkout-sa.
• Υπάρχει ένα Secret payment-api-token.
• Το image προέρχεται από private registry.
• Ένα GitOps pipeline συγχρονίζει τα manifests.
• Runtime alert αναφέρει απροσδόκητο shell μέσα στο Pod.
• Ένα παλιό manifest περιέχει privileged: true και mount τύπου hostPath.
• Οι NetworkPolicies είναι ελλιπείς.
• Η διαδικασία rotation του Secret δεν έχει τεκμηριωθεί.
• Το τμήμα ασφάλειας απαιτεί evidence και production stop criteria.

Εργάζεστε στο lab Namespace exam-security. Δεν πρέπει να τροποποιήσετε το πραγματικό shop-prod. Αντίθετα, αποδείξτε κινδύνους, ελέγχους και μέτρα αντιμετώπισης περιστατικών με αναπαραγώγιμα παραδείγματα και έγγραφα.

4. Αναμενόμενη υποβολή

Υποβάλετε φάκελο ή archive με αυτά τα αρχεία:

04-advanced-security-submission/
  answers.md
  threat-model.md
  rbac-review.md
  serviceaccount-token-review.md
  pod-security-review.md
  hardened-deployment.yml
  networkpolicies.yml
  supply-chain-review.md
  admission-policy.md
  secrets-review.md
  runtime-detection.md
  compliance-evidence.md
  incident-runbook.md
  evidence/
    can-i.txt
    events.txt
    policy-results.txt
    logs-summary.txt
  cleanup.md

Αν συγκεκριμένα εργαλεία δεν υπάρχουν στο lab, τεκμηριώστε το και δώστε μια τεχνικά ορθή εναλλακτική αξιολόγηση. Παράδειγμα: αν δεν υπάρχει Cosign, περιγράψτε ποιος έλεγχος υπογραφής θα απαιτούνταν σε production και ποιο stop criterion θα ίσχυε.

5. Μέρος A: Ερωτήσεις ασφάλειας

Απαντήστε με αναφορά στο σενάριο.

1. Ποιες είναι οι κύριες επιφάνειες επίθεσης του Kubernetes;
2. Πώς αλληλεπιδρούν Authentication, Authorization και Admission Control;
3. Ποιοι κίνδυνοι προκύπτουν από privileged: true, hostPath, hostNetwork, hostPID και hostIPC;
4. Γιατί είναι σημαντικά για την ασφάλεια τα ServiceAccounts και τα tokens που γίνονται αυτόματα mount;
5. Ποια RBAC verbs ή resources είναι ιδιαίτερα επικίνδυνα και γιατί;
6. Τι προσφέρουν τα Pod Security Standards privileged, baseline και restricted;
7. Ποια πεδία SecurityContext περιμένετε σε ένα hardened workload;
8. Γιατί το NetworkPolicy μειώνει το lateral movement χωρίς να αντικαθιστά την κρυπτογράφηση;
9. Γιατί το DNS egress αποτελεί ξεχωριστό σημείο στις πολιτικές default deny;
10. Ποιους ελέγχους supply chain περιμένετε για production images;
11. Γιατί τα Kubernetes Secrets δεν προστατεύονται επαρκώς μόνο με Base64;
12. Ποιες πληροφορίες ανήκουν σε αξιόπιστο incident evidence;
13. Ποια είναι η διαφορά μεταξύ prevention, detection και response;
14. Γιατί οι εξαιρέσεις policies χρειάζονται owner, αιτιολόγηση και ημερομηνία λήξης;
15. Ποια άμεσα μέτρα χρειάζονται για παραβιασμένο Pod και διαρροή Secret;

6. Μέρος B: Threat model και RBAC audit

Εργασία B1: Threat model

Δημιουργήστε threat-model.md για το checkout-api.

Απαιτούμενες ενότητες:

1. assets και αξία προστασίας,
2. trust boundaries,
3. επιφάνειες επίθεσης,
4. σενάρια κατάχρησης,
5. υπάρχοντες έλεγχοι,
6. έλεγχοι που λείπουν,
7. stop criteria,
8. evidence.

Ελάχιστα assets:

Εργασία B2: RBAC audit

Δημιουργήστε δύο ServiceAccounts στο lab:

• app-sa,
• overprivileged-sa.

Το app-sa πρέπει να έχει μόνο τα ελάχιστα δικαιώματα ανάγνωσης σε ConfigMaps. Το overprivileged-sa πρέπει σκόπιμα να έχει επικίνδυνα δικαιώματα, για παράδειγμα σε Secrets ή RoleBindings.

Ελέγξτε τα πραγματικά δικαιώματα με kubectl auth can-i.

Απαιτούμενο evidence στο evidence/can-i.txt:

kubectl auth can-i get configmaps --as system:serviceaccount:exam-security:app-sa -n exam-security
kubectl auth can-i get secrets --as system:serviceaccount:exam-security:app-sa -n exam-security
kubectl auth can-i get secrets --as system:serviceaccount:exam-security:overprivileged-sa -n exam-security
kubectl auth can-i create rolebindings --as system:serviceaccount:exam-security:overprivileged-sa -n exam-security

Τεκμηριώστε:

• ποια δικαιώματα είναι αποδεκτά,
• ποια δικαιώματα είναι κρίσιμα,
• ποια διαδρομή privilege escalation θα ήταν δυνατή,
• πώς γίνεται η διόρθωση.

Εργασία B3: Αυτόματο mount ServiceAccount token

Δημιουργήστε serviceaccount-token-review.md.

Εργασίες:

1. Δημιουργήστε Deployment no-api-app.
2. Ορίστε automountServiceAccountToken: false.
3. Ελέγξτε στο Pod αν έγινε αυτόματο mount token.
4. Εξηγήστε πότε ένα workload χρειάζεται πρόσβαση στο Kubernetes API και πότε όχι.

7. Μέρος C: Hardening workload, δικτύου και supply chain

Εργασία C1: Pod Security Restricted

1. Ορίστε Pod Security labels για restricted στα modes enforce, audit και warn στο lab Namespace.
2. Προσπαθήστε να δημιουργήσετε μη ασφαλές Pod με privileged: true.
3. Τεκμηριώστε την απόρριψη.
4. Δημιουργήστε hardened Pod ή Deployment που ικανοποιεί τις απαιτήσεις Restricted.

Αναμενόμενα κριτήρια hardening:

• runAsNonRoot: true,
• ορισμένος non-root user,
• allowPrivilegeEscalation: false,
• readOnlyRootFilesystem: true,
• capabilities.drop: [ALL],
• seccompProfile: RuntimeDefault,
• χωρίς χρήση host namespaces,
• χωρίς ανεξέλεγκτο hostPath,
• εγγράψιμη διαδρομή μόνο μέσω emptyDir ή αποκλειστικού volume.

Εργασία C2: Hardened Deployment

Δημιουργήστε hardened-deployment.yml για ασφαλή υποδειγματική εφαρμογή.

Το manifest πρέπει να περιλαμβάνει:

• Namespace exam-security,
• ServiceAccount χωρίς περιττό API token,
• SecurityContext σε επίπεδο Pod και container,
• resource Requests και Limits,
• Readiness Probe όπου έχει τεχνικό νόημα,
• σαφή labels owner, environment, app,
• κανένα πραγματικό Secret.

Εργασία C3: NetworkPolicy

Δημιουργήστε networkpolicies.yml με:

1. default deny για Ingress και Egress,
2. άδεια DNS egress,
3. άδεια από frontend προς backend στη θύρα TCP 8080,
4. αποκλεισμό κάθε άλλου egress,
5. σημείωση για το αν το CNI εφαρμόζει NetworkPolicies.

Τεκμηριώστε ερωτήματα για την παραγωγική λειτουργία:

• Χρειάζεται το Pod πρόσβαση στο Kubernetes API;
• Χρειάζεται το Pod πρόσβαση σε registry, logging, monitoring ή εξωτερικά APIs;
• Υπάρχουν σταθεροί εξωτερικοί στόχοι ή μόνο κανόνες απεριόριστου internet egress;
• Πώς λαμβάνονται υπόψη IPv6 ή dual-stack;

Εργασία C4: Έλεγχος supply chain

Δημιουργήστε supply-chain-review.md για ένα υποδειγματικό image.

Απαιτούμενα πεδία:

• registry,
• repository,
• tag,
• digest,
• Pull Policy,
• ImagePullSecret,
• αποτέλεσμα CVE scan ή αναμενόμενη διαδικασία scan,
• κατάσταση SBOM,
• κατάσταση υπογραφής,
• build provenance,
• admission requirement,
• stop criterion.

Πρέπει να αξιολογηθούν τουλάχιστον τα εξής stop criteria:

• latest χωρίς digest σε production,
• image από μη εγκεκριμένο registry,
• κρίσιμο CVE χωρίς εξαίρεση,
• έλλειψη υπογραφής για production workloads,
• Pull Secret χωρίς owner ή rotation.

Εργασία C5: Admission policy

Δημιουργήστε admission-policy.md.

Επιλέξτε τουλάχιστον δύο στόχους policy:

1. υποχρεωτικά labels owner, environment, cost-center,
2. απαγόρευση του privileged: true,
3. απαίτηση runAsNonRoot: true,
4. απαίτηση resource Requests και Limits,
5. μόνο εγκεκριμένα registries.

Για κάθε policy περιγράψτε:

• στόχο,
• πεδίο εφαρμογής,
• mode audit/warn/enforce,
• παράδειγμα παραβίασης,
• διαδικασία εξαίρεσης,
• διαδρομή rollback αν το policy είναι λανθασμένο.

Μπορείτε να χρησιμοποιήσετε Kyverno, OPA Gatekeeper ή ValidatingAdmissionPolicy. Αν κανένα από αυτά τα εργαλεία δεν είναι διαθέσιμο, περιγράψτε τεχνικά το policy με pseudomanifest και τον τρόπο λειτουργίας του.

8. Μέρος D: Secrets, Detection, Compliance και Incident Response

Εργασία D1: Ασφάλεια και rotation των Secrets

Δημιουργήστε secrets-review.md με:

1. κατάλογο Secrets,
2. πρόσβαση μέσω RBAC,
3. τύπο mount στο Pod,
4. κινδύνους σε logs, events, images και backups,
5. κινδύνους etcd/backup,
6. διαδικασία rotation,
7. σύγκριση Kubernetes Secret, External Secrets, CSI Secret Store, Sealed Secrets και SOPS,
8. μέτρο αντιμετώπισης περιστατικού σε περίπτωση διαρροής.

Σημαντικό: Μη χρησιμοποιήσετε πραγματικά Secrets. Οι υποδειγματικές τιμές πρέπει να αναγνωρίζονται ξεκάθαρα ως παραδείγματα.

Εργασία D2: Runtime detection και audit signals

Δημιουργήστε runtime-detection.md.

Ορίστε αναμενόμενα signals και ενέργειες για:

Εργασία D3: Compliance evidence

Δημιουργήστε compliance-evidence.md με τουλάχιστον πέντε ευρήματα:

1. Namespace χωρίς Pod Security label,
2. ServiceAccount με υπερβολικά ευρεία δικαιώματα,
3. Pod χωρίς Requests/Limits,
4. Secret χωρίς σημείωση rotation,
5. workload χωρίς NetworkPolicy.

Για κάθε εύρημα τεκμηριώστε:

• χρόνο,
• πόρο,
• κίνδυνο,
• evidence,
• owner,
• διόρθωση,
• εξαίρεση με ημερομηνία λήξης ή προθεσμία αποκατάστασης,
• επανέλεγχο.

Εργασία D4: Incident runbook

Δημιουργήστε incident-runbook.md για παραβιασμένο Pod και διαρροή Secret.

Απαιτούμενες ενότητες:

1. triage,
2. isolation,
3. διατήρηση evidence,
4. containment,
5. rotation Secret και token,
6. έλεγχος image και CI,
7. rebuild και redeploy,
8. επικοινωνία,
9. lessons learned,
10. hardening policies.

Απαιτούμενο evidence:

kubectl get pod <pod> -n <namespace> -o wide
kubectl get pod <pod> -n <namespace> -o yaml
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --all-containers
kubectl logs <pod> -n <namespace> --all-containers --previous
kubectl get sa,role,rolebinding -n <namespace>
kubectl auth can-i get secrets --as system:serviceaccount:<namespace>:<serviceaccount> -n <namespace>
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp

Τεκμηριώστε επίσης πότε ένα Pod μπορεί να διαγραφεί αμέσως και πότε πρέπει πρώτα να απομονωθεί για να διατηρηθούν στοιχεία.

9. Βαθμολόγηση

10. Κριτήρια αυτόματης αποτυχίας

Η αξιολόγηση αποτυγχάνει ανεξάρτητα από τη βαθμολογία αν:

• χρησιμοποιηθούν πραγματικά Secrets, δεδομένα πελατών ή production contexts,
• εκτελεστούν καταστροφικές ενέργειες εκτός lab,
• επιτραπεί σε workload που προσομοιώνει production να τρέχει ως privileged χωρίς τεκμηριωμένη εξαίρεση,
• γίνουν αποδεκτά δικαιώματα ανάγνωσης Secrets χωρίς τεχνική ανάγκη,
• καταστραφεί incident evidence πριν από τη βασική συλλογή του,
• ο εξεταζόμενος δεν μπορεί να εξηγήσει γιατί το Base64 δεν είναι κρυπτογράφηση,
• δεν οριστούν stop criteria για production.

11. Λίστα ελέγχου εξεταστή

• Το threat model διαχωρίζει API, Node, workload, δίκτυο, Secrets και supply chain.
• Υπάρχει evidence kubectl auth can-i για αμφότερα τα ServiceAccounts.
• Το αυτόματο mount token είναι απενεργοποιημένο σε workload χωρίς ανάγκη πρόσβασης API.
• Το Pod Security Restricted έχει οριστεί με labels και έχει τεκμηριωθεί η απόρριψη μη ασφαλούς Pod.
• Το hardened Deployment περιλαμβάνει non-root, seccomp, dropped capabilities και read-only root filesystem.
• Οι NetworkPolicies περιλαμβάνουν default deny, DNS και στοχευμένη άδεια εφαρμογής.
• Ο έλεγχος supply chain καλύπτει registry, digest, scan, SBOM, υπογραφή και stop criteria.
• Οι Admission policies έχουν mode audit/warn/enforce, εξαιρέσεις και διαδρομή rollback.
• Ο έλεγχος Secrets περιλαμβάνει RBAC, mount, rotation, backups και αντιμετώπιση διαρροής.
• Το Runtime detection και το compliance evidence οδηγούν σε εφαρμόσιμες ενέργειες.
• Το incident runbook καλύπτει triage, isolation, evidence, rotation, rebuild και βελτίωση policies.