Wiki workshop · Ελληνικά

Ενδεικτική λύση: Kubernetes Assessment 04 – Advanced + Security

Λύσεις για threat model, RBAC, Pod Security, NetworkPolicy, supply chain, Secrets και incident response.

Παραδείγματα workshop σε ZIP
Πρόοδος μάθησης στη web app

Σημειώστε κεφάλαια ως αναγνωσμένα, δείτε την πρόοδο ανάγνωσης και ολοκληρώστε πρακτικές ενότητες αφού ενεργοποιήσετε την προαιρετική web app. Η πρόοδος του workshop υπολογίζεται από τα κεφάλαια όλων των σελίδων τεκμηρίωσης. Οι επιλογές μένουν σε αυτή τη συσκευή· δεν υπάρχει λογαριασμός ή συγχρονισμός με server. Δεν απαιτείται εγκατάσταση. Η ανάκληση στις Ρυθμίσεις απορρήτου διαγράφει την πρόοδο.

Πρόοδος ανάγνωσης0%
0%
0 / 8 κεφάλαια που διαβάστηκαν
Άλλη γλωσσική έκδοσηΓερμανικά ↗Αγγλικά ↗

Ενδεικτική λύση: Kubernetes Assessment 04 – Advanced + Security

Επίπεδο δυσκολίας: Advanced + Security Γλώσσα: Ελληνικά Τύπος: ενδεικτική λύση / οδηγός αναμενόμενων απαντήσεων

Αυτό το αρχείο είναι η αντίστοιχη λύση για το 04-advanced-security-kubernetes-assessment-EL.md. Όλα τα παραδείγματα προορίζονται για lab και ανασκόπηση. Μη χρησιμοποιείτε πραγματικά Secrets, tokens, δεδομένα πελατών ή production cluster contexts.

1. Οδηγίες χρήσης

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

bash
export NS=exam-security

Αυτή η ενδεικτική λύση συνδυάζει έγγραφα ανασκόπησης, παραδείγματα manifests και αναμενόμενα evidence. Δεν διαθέτουν όλα τα labs Kyverno, Gatekeeper, ValidatingAdmissionPolicy, Trivy, Cosign, Falco ή Tetragon. Αν λείπει ένα εργαλείο, η υποβολή πρέπει να περιγράφει σωστά ποιος έλεγχος θα απαιτούνταν σε production και ποιο stop criterion εφαρμόζεται.

01 / 08

2. Μέρος A: Ενδεικτικές απαντήσεις σε τεχνικές ερωτήσεις ασφάλειας

1. Κύριες επιφάνειες επίθεσης Kubernetes

Σημαντικές επιφάνειες επίθεσης είναι ο API Server, το authentication, το RBAC, το Admission, το etcd, τα Nodes, το kubelet, το container runtime, τα workloads, τα ServiceAccounts, τα Secrets, το δίκτυο, το registry, το CI/CD, το GitOps και τα add-ons. Ένας έλεγχος πρέπει να εξετάζει χωριστά τους κινδύνους API, Node, workload, δικτύου, Secrets και supply chain.

2. Authentication, Authorization και Admission Control

Το Authentication προσδιορίζει ποιος υποβάλλει ένα αίτημα. Το Authorization αποφασίζει αν αυτή η ταυτότητα μπορεί να εκτελέσει την ενέργεια στον πόρο. Το Admission Control επικυρώνει ή τροποποιεί τα αποδεκτά αιτήματα πριν αποθηκευτούν στο etcd. Παράδειγμα: ένας χρήστης μπορεί να έχει δικαίωμα να δημιουργεί Pods, αλλά το Admission να αποκλείει το privileged: true.

3. Κίνδυνοι των privileged, hostPath, hostNetwork, hostPID και hostIPC

Ρύθμιση Κίνδυνος
privileged: true το container αποκτά πολύ εκτεταμένες δυνατότητες πρόσβασης στον host
hostPath πρόσβαση στο filesystem του host και πιθανή τροποποίησή του
hostNetwork παράκαμψη της δικτυακής απομόνωσης Pod και πρόσβαση στο δίκτυο του Node
hostPID ορατότητα των διεργασιών του host
hostIPC πρόσβαση στο IPC namespace του host

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

4. ServiceAccounts και tokens που γίνονται αυτόματα mount

Τα ServiceAccounts αποτελούν ταυτότητες workloads. Τα tokens που γίνονται αυτόματα mount επιτρέπουν πρόσβαση στο API από το Pod. Αν παραβιαστεί ένα Pod, ο επιτιθέμενος μπορεί να καταχραστεί το token. Pods που δεν χρειάζονται API πρέπει να ορίζουν automountServiceAccountToken: false.

5. Επικίνδυνα RBAC verbs και resources

Επικίνδυνα δικαιώματα είναι τα *, get/list/watch secrets, create pods, pods/exec, create rolebindings, bind, escalate, impersonate, nodes/proxy και ClusterRoleBindings. Οι κίνδυνοι περιλαμβάνουν exfiltration Secrets, privilege escalation, lateral movement και παράκαμψη των μηχανισμών προστασίας RBAC.

6. Pod Security Standards

Το privileged επιτρέπει σχεδόν τα πάντα και δεν αποτελεί security baseline. Το baseline αποκλείει γνωστές επικίνδυνες ρυθμίσεις, αλλά επιτρέπει πολλά συνηθισμένα workloads. Το restricted επιβάλλει ισχυρότερο hardening, όπως non-root, seccomp και περιορισμένα δικαιώματα. Για νέα Namespaces, το restricted αποτελεί συχνά τον επιθυμητό στόχο.

7. Αναμενόμενα πεδία SecurityContext

Αναμενόμενα πεδία:

yaml
securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - securityContext:
      runAsUser: 1000
      runAsGroup: 1000
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Επιπλέον: χωρίς χρήση host namespaces, χωρίς ανεξέλεγκτα hostPath mounts, με resource limits και εγγράψιμες διαδρομές μόνο μέσω καθορισμένων volumes.

8. NetworkPolicy και lateral movement

Οι NetworkPolicies περιορίζουν το lateral movement, επειδή τα Pods δεν μπορούν πλέον να επικοινωνούν αυθαίρετα μεταξύ τους ή προς τα έξω. Δεν αντικαθιστούν την κρυπτογράφηση. Για την εμπιστευτικότητα και ακεραιότητα της μεταφοράς απαιτείται TLS ή mTLS.

9. DNS egress με default deny

Το default-deny egress αποκλείει και το DNS. Χωρίς εξαίρεση DNS, τα Pods δεν μπορούν να επιλύουν Services ή εξωτερικούς στόχους με όνομα. Γι’ αυτό επιτρέπεται ρητά TCP/UDP στη θύρα 53 προς CoreDNS ή kube-dns.

10. Έλεγχοι supply chain

Αναμενόμενοι έλεγχοι είναι εγκεκριμένα registries, απουσία latest σε production, digest pinning, image scans, SBOM, επαλήθευση υπογραφής, build provenance, σαφής owner των Pull Secrets και επαλήθευση μέσω Admission.

11. Kubernetes Secrets και Base64

Τα Kubernetes Secrets είναι API objects και κωδικοποιούνται εξ ορισμού με Base64. Αυτό δεν είναι κρυπτογράφηση που εξασφαλίζει εμπιστευτικότητα. Η προστασία απαιτεί RBAC, κρυπτογράφηση etcd, προστασία backups, ελάχιστα mounts, rotation και ενδεχομένως εξωτερικά συστήματα Secrets.

12. Αξιόπιστο incident evidence

Το evidence περιλαμβάνει χρονική σήμανση, Namespace, Pod YAML, events, logs, προηγούμενα logs, image digest, ServiceAccount, RBAC, αποτελέσματα can-i, audit logs, runtime alerts, flow logs και καταγεγραμμένες ενέργειες. Πρέπει να αποθηκεύεται με τρόπο αναπαραγώγιμο και με τις ελάχιστες δυνατές αλλοιώσεις.

13. Prevention, detection και response

Το prevention αποτρέπει μη ασφαλείς καταστάσεις, για παράδειγμα μέσω Pod Security ή Admission. Το detection εντοπίζει ύποπτη συμπεριφορά, για παράδειγμα μέσω runtime alerts ή audit logs. Το response περιγράφει containment, διατήρηση evidence, rotation, rebuild και lessons learned.

14. Εξαιρέσεις policy με owner, αιτιολόγηση και ημερομηνία λήξης

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

15. Άμεσες ενέργειες για παραβιασμένο Pod και διαρροή Secret

  • Καθορίστε triage και έκταση του περιστατικού.
  • Απομονώστε Pod/Namespace· μη διαγράψετε πρόωρα το Pod αν χρειάζεται evidence.
  • Διατηρήστε logs, events, YAML, image digest και RBAC.
  • Κάντε rotation του Secret και του ServiceAccount token.
  • Περιορίστε το egress.
  • Ελέγξτε image, CI και GitOps.
  • Κάντε καθαρό rebuild και redeploy.
  • Ενισχύστε policy και runbook.
02 / 08

3. Μέρος B: Threat Model και RBAC Audit

B1: threat-model.md

markdown
# Threat Model: checkout-api

## Assets και αξία προστασίας

| Asset | Αξία προστασίας | Αιτιολόγηση |
| --- | --- | --- |
| `payment-api-token` | πολύ υψηλή | πιθανή πρόσβαση στο payment API |
| `checkout-sa` | υψηλή | ταυτότητα workload με πιθανή πρόσβαση API |
| Deployment `checkout-api` | υψηλή | production workload |
| private image | υψηλή | σχετικό με το supply chain |
| GitOps repository | πολύ υψηλή | επιθυμητή κατάσταση και διαδικασία έγκρισης |
| Ingress/Gateway route | μέτρια έως υψηλή | εξωτερική επιφάνεια επίθεσης |

## Trust boundaries

- Από το internet προς Gateway/Ingress.
- Από το Gateway προς `checkout-api`.
- Από το Pod προς Kubernetes API.
- Από το Pod προς την προβολή Secret.
- Από το CI προς το registry.
- Από τον GitOps Controller προς το cluster.
- Από το Namespace `shop-prod` προς άλλα Namespaces.

## Επιφάνειες επίθεσης

- API Server και RBAC.
- ServiceAccount token.
- Container image και registry.
- Secret mount και rotation Secret.
- NetworkPolicy/egress.
- Δικαιώματα GitOps και CI.
- Pod Security και πεδία με πρόσβαση στον host.

## Σενάρια κατάχρησης

| Σενάριο | Κίνδυνος | Έλεγχος |
| --- | --- | --- |
| παραβιασμένο Pod διαβάζει `payment-api-token` | κατάχρηση payment API | ελάχιστα Secret mounts, rotation, RBAC |
| το `checkout-sa` μπορεί να διαβάζει ή να απαριθμεί Secrets | exfiltration Secrets | least privilege, `can-i`, audit |
| παλιό manifest με `privileged` και `hostPath` | παραβίαση host | Pod Security, Admission, review |
| εγκατάσταση ανυπόγραφου image | κακόβουλος κώδικας ή αλλοίωση | υπογραφή, digest, scan, SBOM |
| απουσία egress policy | exfiltration και C2 | default deny, άδειες DNS και εφαρμογής |
| το CI έχει cluster-admin | παραβίαση pipeline καταλαμβάνει το cluster | GitOps, περιορισμένα δικαιώματα CI |

## Υπάρχοντες έλεγχοι

- Private registry.
- GitOps pipeline.
- ServiceAccount ανά workload.
- Υπάρχει runtime alert.

## Έλεγχοι που λείπουν

- Πλήρεις NetworkPolicies.
- Τεκμηριωμένη διαδικασία rotation Secret.
- Stop criteria στο Admission.
- Evidence για υπογραφή και SBOM.
- Evidence για RBAC.
- Incident runbook.

## Stop criteria

- Το ServiceAccount μπορεί να διαβάζει ή να απαριθμεί Secrets χωρίς τεχνική ανάγκη.
- Το workload χρησιμοποιεί `privileged`, `hostPath`, `hostNetwork`, `hostPID` ή `hostIPC` χωρίς εγκεκριμένη εξαίρεση.
- Το image δεν προέρχεται από εγκεκριμένο registry ή δεν έχει υπογραφή.
- Υπάρχει κρίσιμο CVE χωρίς εξαίρεση.
- Το rotation Secret δεν είναι δυνατό ή δεν έχει τεκμηριωθεί.
- Δεν υπάρχει NetworkPolicy για production workload.

## Evidence

- Αποτελέσματα `kubectl auth can-i`.
- Policy reports.
- Image digest, scan, SBOM και κατάσταση υπογραφής.
- NetworkPolicy manifests και δοκιμές.
- Incident evidence από logs, events και runtime alerts.

B2: RBAC Audit

rbac-review.md και υποδειγματικό manifest

yaml
apiVersion: v1
kind: Namespace
metadata:
  name: exam-security
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: exam-security
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: overprivileged-sa
  namespace: exam-security
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: exam-security
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-sa-configmap-reader
  namespace: exam-security
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: exam-security
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: risky-role
  namespace: exam-security
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["rolebindings"]
    verbs: ["create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: risky-binding
  namespace: exam-security
subjects:
  - kind: ServiceAccount
    name: overprivileged-sa
    namespace: exam-security
roleRef:
  kind: Role
  name: risky-role
  apiGroup: rbac.authorization.k8s.io

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

bash
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

Αναμενόμενη αξιολόγηση:

Έλεγχος Αναμενόμενο αποτέλεσμα Αξιολόγηση
app-sa get configmaps yes αποδεκτό αν απαιτείται τεχνικά
app-sa get secrets no σωστά περιορισμένο
overprivileged-sa get secrets yes κρίσιμο
overprivileged-sa create rolebindings yes κρίσιμο, πιθανή διαδρομή privilege escalation

Διόρθωση:

  • Αφαιρέστε τα δικαιώματα Secrets.
  • Αφαιρέστε τη δυνατότητα δημιουργίας RoleBindings.
  • Χρησιμοποιήστε ξεχωριστή διαχειριστική διαδικασία break-glass.
  • Ελέγξτε ξανά τα πραγματικά δικαιώματα με can-i.

B3: Αυτόματο mount ServiceAccount token

serviceaccount-token-review.md / Deployment

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: no-api-app
  namespace: exam-security
spec:
  replicas: 1
  selector:
    matchLabels:
      app: no-api-app
  template:
    metadata:
      labels:
        app: no-api-app
    spec:
      automountServiceAccountToken: false
      containers:
        - name: app
          image: busybox:1.36
          command: ["sh", "-c", "sleep 3600"]
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 100m
              memory: 128Mi

Έλεγχος:

bash
kubectl apply -f no-api-app.yml
kubectl rollout status deployment/no-api-app -n exam-security
POD=$(kubectl get pod -l app=no-api-app -n exam-security -o jsonpath='{.items[0].metadata.name}')
kubectl exec "$POD" -n exam-security -- ls -la /var/run/secrets/kubernetes.io/serviceaccount || true

Ενδεικτική αξιολόγηση:

  • Συνηθισμένες web apps χωρίς ανάγκη πρόσβασης στο Kubernetes API δεν χρειάζονται token.
  • Controllers, operators ή εφαρμογές που διαβάζουν ή γράφουν Kubernetes objects χρειάζονται συνειδητά ρυθμισμένα API permissions.
03 / 08

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

C1: Pod Security Restricted

Ορίστε labels στο Namespace:

bash
kubectl create namespace exam-security --dry-run=client -o yaml | kubectl apply -f -
kubectl label namespace exam-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted --overwrite

Μη ασφαλές Pod:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
  namespace: exam-security
spec:
  containers:
    - name: app
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      securityContext:
        privileged: true

Αναμενόμενο αποτέλεσμα: ο API Server απορρίπτει το Pod μέσω Pod Security Admission.

C2: hardened-deployment.yml

yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: hardened-app
  namespace: exam-security
automountServiceAccountToken: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hardened-app
  namespace: exam-security
  labels:
    app: hardened-app
    owner: platform-security
    environment: exam
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hardened-app
  template:
    metadata:
      labels:
        app: hardened-app
        owner: platform-security
        environment: exam
    spec:
      serviceAccountName: hardened-app
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      volumes:
        - name: tmp
          emptyDir: {}
      containers:
        - name: app
          image: busybox:1.36
          command: ["sh", "-c", "while true; do echo ok > /tmp/status; sleep 60; done"]
          volumeMounts:
            - name: tmp
              mountPath: /tmp
          readinessProbe:
            exec:
              command: ["sh", "-c", "test -f /tmp/status || true"]
            periodSeconds: 10
          securityContext:
            runAsUser: 1000
            runAsGroup: 1000
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi

Έλεγχος:

bash
kubectl apply -f hardened-deployment.yml
kubectl rollout status deployment/hardened-app -n exam-security
kubectl get pod -l app=hardened-app -n exam-security -o yaml | grep -E 'runAsNonRoot|allowPrivilegeEscalation|readOnlyRootFilesystem|seccompProfile|capabilities' -A3

C3: networkpolicies.yml

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: exam-security
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: exam-security
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-egress-to-backend
  namespace: exam-security
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-ingress-from-frontend
  namespace: exam-security
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Ερωτήματα για production:

  • Χρειάζεται το Pod egress προς το Kubernetes API;
  • Χρειάζεται πρόσβαση σε registry, logging, monitoring ή εξωτερικά API targets;
  • Μπορούν οι εξωτερικοί στόχοι να περιοριστούν αυστηρά;
  • Έχει ληφθεί υπόψη IPv6 ή dual stack;
  • Εφαρμόζει πράγματι το CNI τις NetworkPolicies;

C4: supply-chain-review.md

markdown
# Έλεγχος supply chain

## Υποδειγματικό image

- Registry: `registry.example.com`
- Repository: `shop/checkout-api`
- Tag: `1.4.2`
- Digest: `sha256:<example-digest>`
- Production reference: `registry.example.com/shop/checkout-api@sha256:<example-digest>`
- Pull Policy: `IfNotPresent` ή πρότυπο της πλατφόρμας· αναπαραγώγιμο με immutable digests.
- ImagePullSecret: ειδικό για το Namespace, owner `platform-registry`, rotation κάθε 90 ημέρες.

## Κατάσταση ελέγχων

| Έλεγχος | Αποτέλεσμα | Απόφαση |
| --- | --- | --- |
| εγκεκριμένο registry | ικανοποιείται | εντάξει |
| χωρίς `latest` | ικανοποιείται | εντάξει |
| γνωστό digest | ικανοποιείται | εντάξει |
| CVE scan | κανένα Critical, 1 High με ticket | αποδεκτό υπό όρους |
| SBOM | υπάρχει | εντάξει |
| υπογραφή | έγκυρη | εντάξει |
| build provenance | υπάρχει CI build ID και commit | εντάξει |
| Admission | μόνο εγκεκριμένο registry, digest και υπογραφή | απαιτείται |

## Stop criteria

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

C5: admission-policy.md

markdown
# Admission Policy

## Στόχος policy 1: Υποχρεωτικά labels

- Στόχος: επιβολή των `owner`, `environment`, `cost-center`.
- Πεδίο: Pods, Deployments και Namespaces σύμφωνα με το πρότυπο της πλατφόρμας.
- Mode: πρώτα audit/warn και έπειτα enforce.
- Παράδειγμα παραβίασης: Deployment χωρίς `cost-center`.
- Εξαίρεση: owner, αιτιολόγηση, ημερομηνία λήξης, αντισταθμιστικός έλεγχος.
- Rollback: επιστροφή του policy σε audit ή ρητή εξαίρεση ενός Namespace.

### Παράδειγμα Kyverno

```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-standard-labels
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: require-owner-environment-cost-center
      match:
        any:
          - resources:
              kinds:
                - Pod
                - Deployment
      validate:
        message: "owner, environment, and cost-center Labels are required."
        pattern:
          metadata:
            labels:
              owner: "?*"
              environment: "?*"
              cost-center: "?*"
```

## Στόχος policy 2: Απαγόρευση του `privileged: true`

- Στόχος: αποκλεισμός δικαιωμάτων με πρόσβαση στον host.
- Πεδίο: Pods και Pod templates των workloads.
- Mode: warn/audit σε υπάρχοντα Namespaces, enforce σε νέα Namespaces.
- Παράδειγμα παραβίασης: container με `securityContext.privileged: true`.
- Εξαίρεση: προσωρινή μόνο για εγκεκριμένα system components.
- Rollback: επιστροφή του enforce σε audit αν αποκλειστούν νόμιμα Deployments.

### Παράδειγμα Kyverno

```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            =(containers):
              - =(securityContext):
                  =(privileged): "false"
```

## Εναλλακτική χωρίς policy engine

Αν δεν υπάρχει Kyverno, Gatekeeper ή ValidatingAdmissionPolicy, τεκμηριώστε το policy ως pseudo-manifest και λειτουργική απαίτηση. Το stop criterion παραμένει: production workloads χωρίς αυτόν τον έλεγχο δεν εγκρίνονται.
04 / 08

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

D1: secrets-review.md

markdown
# Έλεγχος Secrets

## Κατάλογος

| Secret | Namespace | Χρήση | Owner | Rotation |
| --- | --- | --- | --- | --- |
| `payment-api-token` | `shop-prod` | πρόσβαση του checkout-api στο payment API | payments-team | κάθε 90 ημέρες ή αμέσως σε περιστατικό |

## Πρόσβαση RBAC

- Τα App ServiceAccounts δεν λαμβάνουν δικαιώματα `list/watch secrets`.
- Το Secret αναφέρεται μόνο συγκεκριμένα ως volume ή env value.
- Η πρόσβαση διαχειριστή απαιτεί audit.

## Τύπος mount

- Προτιμήστε read-only Secret volume.
- Καμία εμφάνιση σε logs.
- Κανένα Secret σε images ή ConfigMaps.

## Κίνδυνοι

| Κίνδυνος | Αξιολόγηση |
| --- | --- |
| Logs | το Secret δεν πρέπει να καταγράφεται |
| Events | τα μηνύματα σφάλματος δεν πρέπει να περιέχουν τιμές |
| Images | το Secret δεν πρέπει να ενσωματώνεται στο image |
| Backups | πρόσβαση στο backup ισοδυναμεί με πρόσβαση στο Secret |
| etcd | απαιτείται encryption at rest και προστασία πρόσβασης |

## Σύγκριση συστημάτων Secrets

| Μοντέλο | Όφελος | Κίνδυνος |
| --- | --- | --- |
| Kubernetes Secret | απλό, εγγενές στο API | κρίσιμα RBAC, etcd και backups |
| External Secrets | συγχρονισμός από εξωτερικό store | κρίσιμα τα δικαιώματα controller και η πρόσβαση στο store |
| CSI Secret Store | προβολή ως volume κατά την εκτέλεση | ελέγξτε rotation και ενσωμάτωση στο Node |
| Sealed Secrets | κρυπτογραφημένα στο Git | κρίσιμο το private key του cluster |
| SOPS | κρυπτογραφημένα αρχεία στο Git | απαιτείται διαχείριση κλειδιών εκτός cluster |

## Διαδικασία rotation

1. Εντοπίστε πού χρησιμοποιείται το Secret.
2. Δημιουργήστε νέα τιμή στο σύστημα προέλευσης.
3. Ενημερώστε το Kubernetes Secret ή την πηγή External Secret.
4. Επανεκκινήστε Pods ή ελέγξτε το reload.
5. Ανακαλέστε την παλιά τιμή.
6. Ελέγξτε για κατάχρηση.

## Ενέργειες σε περίπτωση διαρροής

- Απομονώστε τα επηρεασμένα Pods.
- Κάντε αμέσως rotation του Secret στο σύστημα προέλευσης.
- Ελέγξτε ServiceAccount και RBAC.
- Διατηρήστε logs, events και audit.
- Ενισχύστε NetworkPolicy και Admission.

D2: runtime-detection.md

markdown
# Runtime Detection

| Signal | Κίνδυνος | Πηγή δεδομένων | Πρώτη ενέργεια | Evidence |
| --- | --- | --- | --- | --- |
| απροσδόκητο shell σε container | διαδραστική παραβίαση | runtime sensor, audit `exec` | απομόνωση Pod, έλεγχος χρήστη | χρόνος, Pod, χρήστης, διεργασία |
| εγγραφή σε `/etc`, `/proc`, `/sys` | προσπάθεια αλλοίωσης ή διαφυγής | Falco/Tetragon/Tracee | πάγωμα ή απομόνωση workload | διαδρομή, διεργασία, container |
| απροσδόκητο egress | exfiltration ή C2 | flow logs, DNS, CNI, runtime | αποκλεισμός egress | IP στόχου, DNS, Pod, Namespace |
| πρόσβαση στο Kubernetes API με ServiceAccount | κατάχρηση token | audit logs | έλεγχος RBAC, rotation token | verb, resource, subject |
| ύποπτο `kubectl exec` | χειροκίνητη πρόσβαση χωρίς αλλαγή | API audit | επαλήθευση χρήστη και αλλαγής | χρήστης, Pod, χρόνος, Namespace |
| OOMKill σε Pod σχετικό με την ασφάλεια | πρόβλημα πόρων ή σήμα επίθεσης | events, kubelet, metrics | διαχωρισμός σημάτων εφαρμογής και ασφάλειας | events, limits, logs |

Το detection δεν αντικαθιστά το prevention. Συμπληρώνει Pod Security, RBAC, NetworkPolicy και Admission.

D3: compliance-evidence.md

markdown
# Compliance Evidence

## Εύρημα 1: Namespace χωρίς Pod Security label

- Χρονική σήμανση: 2026-06-12 10:00
- Πόρος: `namespace/team-legacy`
- Κίνδυνος: μη ασφαλή Pods μπορούν να δημιουργηθούν χωρίς προειδοποίηση ή απόρριψη.
- Evidence: `kubectl get ns team-legacy --show-labels`
- Owner: team-legacy
- Διόρθωση: ορίστε labels `enforce/audit/warn`.
- Προθεσμία: 14 ημέρες
- Επανέλεγχος: ελέγξτε ξανά τα labels και επαληθεύστε ότι ένα μη ασφαλές Pod απορρίπτεται.

## Εύρημα 2: ServiceAccount με υπερβολικά ευρεία δικαιώματα

- Πόρος: `rolebinding/risky-binding`
- Κίνδυνος: exfiltration Secrets και privilege escalation.
- Evidence: `kubectl auth can-i get secrets --as system:serviceaccount:team-a:app-sa -n team-a`
- Owner: team-a
- Διόρθωση: αφαιρέστε τα δικαιώματα Secrets και δημιουργίας RoleBindings.
- Εξαίρεση: μόνο με ημερομηνία λήξης και έγκριση ασφάλειας.
- Επανέλεγχος: το `can-i` πρέπει να επιστρέφει `no`.

## Εύρημα 3: Pod χωρίς Requests/Limits

- Πόρος: `deployment/legacy-api`
- Κίνδυνος: αναξιόπιστο scheduling, επίδραση noisy neighbor και ανεπαρκής βάση για HPA.
- Evidence: `kubectl get deployment legacy-api -o yaml`
- Owner: legacy-team
- Διόρθωση: προσθέστε CPU/memory requests και limits.
- Επανέλεγχος: ελέγξτε manifest και QoS.

## Εύρημα 4: Secret χωρίς σημείωση rotation

- Πόρος: `secret/payment-api-token`
- Κίνδυνος: μακροχρόνια ζημιά σε περίπτωση διαρροής.
- Evidence: απουσία annotation `rotation.platform.example.com/next-date`.
- Owner: payments-team
- Διόρθωση: τεκμηριώστε owner, σύστημα προέλευσης και ημερομηνία rotation.
- Επανέλεγχος: προσομοιώστε το rotation στο runbook.

## Εύρημα 5: Workload χωρίς NetworkPolicy

- Πόρος: `namespace/shop-prod`, `deployment/checkout-api`
- Κίνδυνος: lateral movement και ανεξέλεγκτο egress.
- Evidence: `kubectl get networkpolicy -n shop-prod`
- Owner: shop-team
- Διόρθωση: default deny και κανόνες DNS, εφαρμογής και απαραίτητου εξωτερικού egress.
- Επανέλεγχος: δοκιμάστε επιτρεπόμενες και αποκλεισμένες διαδρομές.

D4: incident-runbook.md

markdown
# Incident Runbook: Παραβιασμένο Pod και διαρροή Secret

## 1. Triage

- Εντοπίστε την πηγή του σήματος: runtime alert, audit log, SIEM, αναφορά χρήστη.
- Προσδιορίστε τους επηρεασμένους πόρους: Namespace, Pod, Node, ServiceAccount, Secret, image.
- Αξιολογήστε κρισιμότητα και πιθανή έκθεση δεδομένων.

## 2. Απομόνωση

- Περιορίστε το egress του Namespace ή του Pod με NetworkPolicy.
- Μη διαγράψετε πρόωρα το Pod αν χρειάζεται evidence.
- Αν υπάρχει υποψία παραβίασης Node: κάντε cordon το Node, ορίστε σχέδιο συλλογής στοιχείων και έπειτα ενδεχομένως drain και rebuild.

## 3. Διατήρηση evidence

```bash
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
```

Διατηρήστε επίσης:

- image digest,
- GitOps revision,
- audit logs,
- runtime alerts,
- flow logs και DNS queries.

## 4. Containment

- Περιορίστε τα δικαιώματα ServiceAccount.
- Αποκλείστε ή περιορίστε αυστηρά το egress.
- Κάντε scale ή redeploy τα επηρεασμένα workloads σε απομόνωση.
- Αποκλείστε το μη ασφαλές image.

## 5. Rotation Secret και token

1. Εντοπίστε τα επηρεασμένα Secrets.
2. Κάντε rotation του Secret στο σύστημα προέλευσης.
3. Ενημερώστε το Kubernetes Secret.
4. Επανεκκινήστε Pods ή επιβάλετε reload.
5. Ανακαλέστε τα παλιά tokens.
6. Ελέγξτε για χρήση παλιών τιμών.

## 6. Έλεγχος image και CI

- Συγκρίνετε το image digest με την κατάσταση GitOps.
- Ελέγξτε CI build, scan και υπογραφή.
- Ελέγξτε την πρόσβαση στο registry.
- Αν υπάρχει υποψία παραβίασης supply chain, αποκλείστε το image και κάντε rebuild.

## 7. Rebuild και redeploy

- Διορθώστε το manifest μέσω pull request.
- Κάντε rebuild, scan και υπογραφή του image.
- Εκτελέστε GitOps sync.
- Εκτελέστε smoke tests και security tests.

## 8. Επικοινωνία

- Ορίστε incident commander.
- Ενημερώστε security, platform team, app team και, αν χρειάζεται, υπεύθυνο προστασίας δεδομένων.
- Τεκμηριώστε κατάσταση, κίνδυνο, ενέργειες και ETA.

## 9. Lessons learned

- Ποιος έλεγχος έλειπε;
- Ποιος μηχανισμός detection λειτούργησε;
- Ποιο evidence έλειπε;
- Ποιο policy θα ενισχυθεί;

## 10. Ενίσχυση policies

- Επιβάλετε Pod Security Restricted.
- Περιορίστε το RBAC.
- Τυποποιήστε το `automountServiceAccountToken: false`.
- Εισαγάγετε NetworkPolicy default deny.
- Επιβάλετε υπογραφές images και digest pinning.
- Βελτιώστε το rotation Secrets και το μοντέλο External Secrets.

## Πότε δεν πρέπει να διαγραφεί αμέσως ένα Pod

Αν logs, διεργασίες που εκτελούνται, volumes, runtime signals ή η κατάσταση του container είναι σημαντικά για root-cause analysis, η άμεση διαγραφή μπορεί να καταστρέψει evidence. Τότε απομονώστε και διατηρήστε πρώτα τα στοιχεία και αφαιρέστε ή κάντε redeploy το Pod αργότερα.
05 / 08

6. Αναμενόμενη δομή υποβολής

text
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

Πρότυπο για το cleanup.md:

markdown
# Cleanup

```bash
kubectl delete namespace exam-security
```

Αν δημιουργήθηκαν ClusterPolicies ή demo resources σε επίπεδο cluster, πρέπει να αφαιρεθούν χωριστά και να τεκμηριωθούν.
06 / 08

7. Cleanup

Αφαιρέστε το Namespace:

bash
kubectl delete namespace exam-security

Διαγράψτε cluster-wide policies μόνο αν δημιουργήθηκαν στο lab:

bash
kubectl delete clusterpolicy require-standard-labels --ignore-not-found
kubectl delete clusterpolicy disallow-privileged --ignore-not-found
07 / 08

8. Βαθμολόγηση και σημειώσεις εξεταστή

Μια εξαιρετική λύση Advanced + Security:

  • διαχωρίζει τους κινδύνους ανά API, Node, workload, δίκτυο, Secrets και supply chain,
  • εντοπίζει διαδρομές privilege escalation μέσω ServiceAccount και RBAC,
  • μειώνει τα αυτόματα mounts ServiceAccount token,
  • ικανοποιεί το Pod Security Restricted ή τεκμηριώνει αποκλίσεις με stop criteria,
  • παρέχει hardened SecurityContext,
  • δημιουργεί NetworkPolicies με default deny, DNS και στοχευμένη κίνηση εφαρμογής,
  • αξιολογεί image, registry, tag, digest, scan, SBOM, υπογραφή και Pull Secret,
  • περιγράφει Admission Policies με audit/warn/enforce, εξαίρεση και rollback,
  • διαχειρίζεται Secrets με rotation, RBAC, κινδύνους etcd/backup και ενέργειες σε διαρροή,
  • μετατρέπει runtime signals σε συγκεκριμένες ενέργειες,
  • δημιουργεί αξιόπιστο compliance evidence,
  • γράφει incident runbook με evidence, containment, rotation, recovery και lessons learned,
  • δεν χρησιμοποιεί πραγματικά Secrets ή production clusters.
08 / 08

K8S · Orthevs Academy

31 modules ως ενιαία διαδρομή μάθησης.

Η σειρά παραμένει αμετάβλητη: από τη βασική δομή του lab μέσω τεχνικών θεμελίων και λειτουργικών μοντέλων έως το τελικό troubleshooting. Τα τεχνικά ονόματα καταλόγων διατηρούνται σκόπιμα.

Orthevs – Η μηχανική ως βάση για όσα ακολουθούν.

Το Orthevs ως εφαρμογή

Εγκατάσταση του Orthevs

Η web app του Orthevs μπορεί να εγκατασταθεί σε υποστηριζόμενες κινητές συσκευές και browsers υπολογιστή.

iPhone και iPad

Ανοίξτε το Orthevs στο Safari. Πατήστε Κοινή χρήση και μετά Προσθήκη στην οθόνη αφετηρίας. Ενεργοποιήστε το Άνοιγμα ως web app, αν εμφανίζεται, και πατήστε Προσθήκη.

Android

Για τη web app, ανοίξτε το μενού του browser και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στην αρχική οθόνη. Επιβεβαιώστε την εγκατάσταση.

Browser υπολογιστή

Ανοίξτε το μενού του browser ή το εικονίδιο εγκατάστασης στη γραμμή διευθύνσεων και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στο Dock.

Η εγκατάσταση της web app εξαρτάται από τον browser. Αν δεν εμφανιστεί διάλογος εγκατάστασης, ακολουθήστε τα βήματα του browser που αναφέρονται παραπάνω.