Ενδεικτική λύση: Kubernetes Assessment 04 – Advanced + Security
Επίπεδο δυσκολίας: Advanced + Security Γλώσσα: Ελληνικά Τύπος: ενδεικτική λύση / οδηγός αναμενόμενων απαντήσεων
Αυτό το αρχείο είναι η αντίστοιχη λύση για το
04-advanced-security-kubernetes-assessment-EL.md. Όλα τα παραδείγματα προορίζονται για lab και ανασκόπηση. Μη χρησιμοποιείτε πραγματικά Secrets, tokens, δεδομένα πελατών ή production cluster contexts.
1. Οδηγίες χρήσης
Προτεινόμενο Namespace:
export NS=exam-security
Αυτή η ενδεικτική λύση συνδυάζει έγγραφα ανασκόπησης, παραδείγματα manifests και αναμενόμενα evidence. Δεν διαθέτουν όλα τα labs Kyverno, Gatekeeper, ValidatingAdmissionPolicy, Trivy, Cosign, Falco ή Tetragon. Αν λείπει ένα εργαλείο, η υποβολή πρέπει να περιγράφει σωστά ποιος έλεγχος θα απαιτούνταν σε production και ποιο stop criterion εφαρμόζεται.
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
Αναμενόμενα πεδία:
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.
3. Μέρος B: Threat Model και RBAC Audit
B1: threat-model.md
# 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
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:
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
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
Έλεγχος:
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.
4. Μέρος C: Hardening workload, δικτύου και supply chain
C1: Pod Security Restricted
Ορίστε labels στο Namespace:
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:
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
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
Έλεγχος:
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
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
# Έλεγχος 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
# 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 χωρίς αυτόν τον έλεγχο δεν εγκρίνονται.
5. Μέρος D: Secrets, Detection, Compliance και Incident Response
D1: secrets-review.md
# Έλεγχος 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
# 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
# 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
# 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 αργότερα.
6. Αναμενόμενη δομή υποβολής
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:
# Cleanup
```bash
kubectl delete namespace exam-security
```
Αν δημιουργήθηκαν ClusterPolicies ή demo resources σε επίπεδο cluster, πρέπει να αφαιρεθούν χωριστά και να τεκμηριωθούν.
7. Cleanup
Αφαιρέστε το Namespace:
kubectl delete namespace exam-security
Διαγράψτε cluster-wide policies μόνο αν δημιουργήθηκαν στο lab:
kubectl delete clusterpolicy require-standard-labels --ignore-not-found
kubectl delete clusterpolicy disallow-privileged --ignore-not-found
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.