Kubernetes Workshop: Advanced + Security – Ασκήσεις με λύσεις

Αναφορά: Kubernetes Workshop Advanced + Security Επίπεδο δυσκολίας: Advanced + Security Μορφή: security review, πρακτικό lab, οδηγίες βήμα προς βήμα και ενδεικτικές λύσεις

Στόχος αυτού του φύλλου ασκήσεων

Το φύλλο συμπληρώνει το workshop Advanced + Security με πρακτικές εργασίες, λίστες ελέγχου, ενδεικτικές λύσεις και αναλυτική καθοδήγηση. Η έμφαση είναι σε threat modeling, API Server και Control Plane hardening, RBAC, identity, Pod Security Standards, workload hardening, RuntimeClass, ασφάλεια δικτύου, ασφάλεια supply chain, policy-as-code, Admission Control, ασφάλεια Secrets, runtime detection, compliance, evidence και incident response.

Εργαστείτε μόνο σε lab cluster. Μη χρησιμοποιείτε production Secrets, πραγματικά δεδομένα πελατών ή production cluster contexts.

Προαπαιτούμενα

Χρειάζεστε:

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

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

export NS=workshop-security
kubectl create namespace "$NS"
kubectl config set-context --current --namespace="$NS"

Επισκόπηση ασκήσεων

Αρ.	Θέμα	Αποτέλεσμα
1	Threat Model	κίνδυνοι ανά API, Node, workload, δίκτυο, Secrets και supply chain
2	RBAC audit	αξιολόγηση πραγματικών δικαιωμάτων και διαδρομών privilege escalation
3	ServiceAccount Token	περιορισμός αυτόματου mount token
4	Pod Security Restricted	αποκλεισμός και hardening μη ασφαλών Pods
5	Workload hardening	σωστά ορισμένο SecurityContext
6	NetworkPolicy	ελεγχόμενα Default Deny, DNS και κίνηση εφαρμογής
7	Supply Chain	αξιολόγηση image, tag, digest, SBOM, scan και υπογραφής
8	Admission Policy	επιβολή υποχρεωτικών labels ή SecurityContext
9	Ασφάλεια Secrets	αξιολόγηση ροών Secret και rotation
10	Runtime Detection	ορισμός signals και ενεργειών
11	Compliance Evidence	τεκμηρίωση ευρήματος, κινδύνου, εξαίρεσης και διόρθωσης
12	Incident Response	runbook για παραβιασμένο Pod και διαρροή Secret

Μέρος A – Ασκήσεις

Άσκηση 1: Δημιουργία Kubernetes Threat Model

Στόχος

Μοντελοποιείτε χωριστά τους κινδύνους ασφάλειας ανά επιφάνεια επίθεσης Kubernetes.

Σενάριο

Μια υποδειγματική εφαρμογή αποτελείται από:

Namespace shop-prod,
Deployment checkout-api,
ServiceAccount checkout-sa,
Secret payment-api-token,
Ingress/Gateway route,
private registry,
GitOps Controller,
CI pipeline.

Εργασία

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

assets και αξία προστασίας,
trust boundaries,
επιφάνειες επίθεσης,
σενάρια κατάχρησης,
υπάρχοντες ελέγχους,
ελέγχους που λείπουν,
stop criteria,
evidence.

Άσκηση 2: Εκτέλεση RBAC audit

Στόχος

Εντοπίζετε υπερβολικά ευρεία δικαιώματα και διαδρομές privilege escalation.

Εργασία

Δημιουργήστε δύο ServiceAccounts: app-sa και overprivileged-sa.
Δώστε στο app-sa τα ελάχιστα δικαιώματα ανάγνωσης ConfigMaps.
Δώστε σκόπιμα στο overprivileged-sa δικαιώματα σε Secrets και RoleBindings.
Ελέγξτε τα πραγματικά δικαιώματα με kubectl auth can-i.
Τεκμηριώστε κινδύνους και διορθώσεις.

Άσκηση 3: Περιορισμός αυτόματου mount ServiceAccount token

Στόχος

Διασφαλίζετε ότι Pods χωρίς ανάγκη πρόσβασης στο Kubernetes API δεν λαμβάνουν αυτόματα ServiceAccount token.

Εργασία

Δημιουργήστε Deployment no-api-app.
Ορίστε automountServiceAccountToken: false.
Ελέγξτε στο Pod αν υπάρχει η διαδρομή /var/run/secrets/kubernetes.io/serviceaccount.
Εξηγήστε πότε ένα Pod χρειάζεται token και πότε όχι.

Άσκηση 4: Επιβολή Pod Security Restricted

Στόχος

Επιβάλλετε Pod Security Standards στο Namespace και διορθώνετε ένα μη ασφαλές Pod.

Εργασία

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

Άσκηση 5: Workload hardening με SecurityContext

Στόχος

Μετατρέπετε το workload hardening σε συγκεκριμένα πεδία SecurityContext σε επίπεδο Pod και container.

Εργασία

Κριτήρια hardening:

να μην εκτελείται ως root,
απαγόρευση privilege escalation,
read-only root filesystem,
αφαίρεση όλων των Linux capabilities,
seccomp RuntimeDefault,
προσωρινός εγγράψιμος κατάλογος μέσω emptyDir,
χωρίς χρήση host namespaces.

Δημιουργήστε Deployment που ικανοποιεί τα κριτήρια.

Άσκηση 6: NetworkPolicy Default Deny με DNS και άδεια εφαρμογής

Στόχος

Περιορίζετε το lateral movement και επιτρέπετε μόνο την απαραίτητη κίνηση.

Εργασία

Δημιουργήστε frontend και backend.
Δημιουργήστε Default Deny για Ingress και Egress.
Επιτρέψτε DNS Egress.
Επιτρέψτε κίνηση από frontend προς backend στη θύρα 8080.
Αποκλείστε κάθε άλλο Egress.
Τεκμηριώστε ποιες επιπλέον εξαιρέσεις θα χρειάζονταν σε production.

Άσκηση 7: Έλεγχος ασφάλειας supply chain

Στόχος

Αξιολογείτε ένα Kubernetes workload από την οπτική του supply chain.

Εργασία

Για ένα υποδειγματικό image τεκμηριώστε:

registry,
repository,
tag,
digest,
pull policy,
ImagePullSecret,
αποτέλεσμα scan,
κατάσταση SBOM,
κατάσταση υπογραφής,
απαίτηση Admission,
stop criterion.

Προαιρετικά με εργαλεία:

trivy image <image>
cosign verify <image>@<digest>

Άσκηση 8: Σύνταξη Admission Policy

Στόχος

Διατυπώνετε policy που αποκλείει μη ασφαλείς ή ελλιπείς πόρους.

Εργασία

Γράψτε policy για έναν από τους εξής στόχους:

υποχρεωτικά labels owner, environment, cost-center,
απαγόρευση privileged: true,
απαίτηση runAsNonRoot: true,
απαίτηση resource requests και limits,
μόνο εγκεκριμένα registries.

Ανάλογα με το lab, χρησιμοποιήστε Kyverno, OPA Gatekeeper ή εγγενές ValidatingAdmissionPolicy.

Άσκηση 9: Αξιολόγηση ασφάλειας και rotation των Secrets

Στόχος

Διακρίνετε Kubernetes Secret, External Secrets, CSI Secret Store, Sealed Secrets και SOPS με βάση συγκεκριμένο κίνδυνο.

Εργασία

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

κατάλογο Secrets,
ποιος έχει πρόσβαση,
πού γίνονται mount τα Secrets,
αν μπορούν να εμφανιστούν σε logs ή Events,
διαδικασία rotation,
κίνδυνο etcd/backup,
πρόταση για σύστημα Secrets,
ενέργειες σε περίπτωση διαρροής.

Άσκηση 10: Ταξινόμηση runtime detection

Στόχος

Ορίζετε signals που πρέπει να εντοπίζονται από το runtime detection ή το audit logging.

Εργασία

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

απροσδόκητο shell στο container,
πρόσβαση εγγραφής σε /etc, /proc ή /sys,
απροσδόκητο Egress,
πρόσβαση στο Kubernetes API με ServiceAccount,
ύποπτο kubectl exec,
OOMKill σε Pod σχετικό με την ασφάλεια.

Για κάθε signal τεκμηριώστε: κίνδυνο, πηγή δεδομένων, πρώτη ενέργεια και evidence.

Άσκηση 11: Δημιουργία compliance evidence

Στόχος

Δημιουργείτε τεκμηριωμένο compliance finding με κίνδυνο, owner, εξαίρεση ή διόρθωση.

Εργασία

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

Namespace χωρίς Pod Security label,
ServiceAccount με υπερβολικά ευρεία δικαιώματα,
Pod χωρίς requests/limits,
Secret χωρίς σημείωση rotation,
workload χωρίς NetworkPolicy.

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

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

Άσκηση 12: Σύνταξη incident runbook

Στόχος

Διατυπώνετε διαδικασία Kubernetes incident response για παραβιασμένο Pod και διαρροή Secret.

Εργασία

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

triage,
isolation,
διατήρηση evidence,
containment,
rotation Secret και token,
έλεγχο image και CI,
rebuild και redeploy,
επικοινωνία,
lessons learned,
policy hardening.

Μέρος B – Λύσεις και αναλυτική καθοδήγηση

Λύση 1: Threat Model

Υποδειγματική δομή:

# Threat Model: checkout-api

## Assets

| Asset | Αξία προστασίας |
| --- | --- |
| payment-api-token | πολύ υψηλή |
| checkout-api Deployment | υψηλή |
| checkout-sa ServiceAccount | υψηλή |
| Registry Image | υψηλή |
| GitOps Repository | πολύ υψηλή |
| Ingress/Gateway Route | μέτρια έως υψηλή |

## Trust boundaries

- Από το internet προς Ingress/Gateway.
- Από το Namespace εφαρμογής προς Kubernetes API.
- Από το Pod προς Secret Store.
- Από το CI προς το Registry.
- Από τον GitOps Controller προς το Cluster.
- Από το Namespace προς άλλα Namespaces.

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

| Σενάριο | Κίνδυνος | Έλεγχος |
| --- | --- | --- |
| Pod διαβάζει Secret και διαρρέει token | πρόσβαση σε δεδομένα πληρωμών | RBAC, ελάχιστο Secret mount, NetworkPolicy, rotation |
| ServiceAccount μπορεί να απαριθμεί Secrets | exfiltration Secrets | Least Privilege, `can-i`, audit logs |
| εγκαθίσταται ανυπόγραφο image | κακόβουλος κώδικας | επαλήθευση υπογραφής, digest pinning, Admission |
| απουσία NetworkPolicy επιτρέπει lateral movement | εξάπλωση | Default Deny, στοχευμένοι κανόνες Egress |
| CI έχει cluster-admin | παραβίαση pipeline οδηγεί σε παραβίαση cluster | GitOps, περιορισμένα δικαιώματα CI |

## Stop criteria

- Το ServiceAccount μπορεί να εκτελεί `get/list/watch secrets` χωρίς λειτουργική ανάγκη.
- Το workload εκτελείται ως `privileged` χωρίς εξαίρεση.
- Το image δεν έχει υπογραφή ή δεν έχει ελεγχθεί με scan.
- Το rotation του Secret δεν είναι εφικτό.
- Δεν υπάρχει evidence για εξαιρέσεις policy.

Λύση 2: RBAC audit

ServiceAccounts:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: workshop-security
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: overprivileged-sa
  namespace: workshop-security

Ελάχιστος Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
  namespace: workshop-security
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-sa-configmap-reader
  namespace: workshop-security
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: workshop-security
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

Σκόπιμα επικίνδυνος Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: risky-role
  namespace: workshop-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: workshop-security
subjects:
  - kind: ServiceAccount
    name: overprivileged-sa
    namespace: workshop-security
roleRef:
  kind: Role
  name: risky-role
  apiGroup: rbac.authorization.k8s.io

Έλεγχος:

kubectl apply -f rbac.yml
kubectl auth can-i get configmaps --as system:serviceaccount:workshop-security:app-sa -n workshop-security
kubectl auth can-i get secrets --as system:serviceaccount:workshop-security:app-sa -n workshop-security
kubectl auth can-i get secrets --as system:serviceaccount:workshop-security:overprivileged-sa -n workshop-security
kubectl auth can-i create rolebindings --as system:serviceaccount:workshop-security:overprivileged-sa -n workshop-security

Αξιολόγηση:

Το app-sa είναι αποδεκτό αν η εφαρμογή χρειάζεται ανάγνωση ConfigMaps.
Το overprivileged-sa είναι κρίσιμο, επειδή η ανάγνωση Secrets και η δημιουργία RoleBindings ανοίγουν διαδρομές privilege escalation.
Διόρθωση: αφαιρέστε πρόσβαση σε Secrets και δημιουργία RoleBindings και χρησιμοποιήστε ξεχωριστές διαδικασίες break-glass.

Λύση 3: Αυτόματο mount ServiceAccount token

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: no-api-app
  namespace: workshop-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"]

Έλεγχος:

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

Αναμενόμενο αποτέλεσμα:

Η διαδρομή δεν υπάρχει ή δεν περιέχει token που έγινε αυτόματα mount.

Τεχνική απόφαση:

Το Pod χρειάζεται token όταν απαιτείται τεχνικά πρόσβαση στο Kubernetes API, για παράδειγμα για controllers.
Το Pod δεν χρειάζεται token όταν είναι συνηθισμένη web app χωρίς χρήση του cluster API.

Λύση 4: Pod Security Restricted

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

kubectl label namespace workshop-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: workshop-security
spec:
  containers:
    - name: app
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      securityContext:
        privileged: true

Αναμενόμενο αποτέλεσμα:

kubectl apply -f privileged-pod.yml

Ο API Server απορρίπτει το Pod λόγω Pod Security Admission.

Hardened Pod:

apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
  namespace: workshop-security
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

Έλεγχος:

kubectl apply -f restricted-pod.yml
kubectl get pod restricted-pod
kubectl describe pod restricted-pod

Λύση 5: Workload hardening

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hardened-app
  namespace: workshop-security
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hardened-app
  template:
    metadata:
      labels:
        app: hardened-app
    spec:
      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
          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-app.yml
kubectl rollout status deployment/hardened-app
kubectl get pod -l app=hardened-app -o yaml | grep -E 'runAsNonRoot|allowPrivilegeEscalation|readOnlyRootFilesystem|seccompProfile|capabilities' -A3

Επεξήγηση:

Το readOnlyRootFilesystem απαιτεί ξεχωριστό εγγράψιμο κατάλογο αν η εφαρμογή χρειάζεται να γράφει.
Το drop: ALL περιορίζει τις Kernel capabilities.
Το allowPrivilegeEscalation: false αποτρέπει ορισμένες διαδρομές privilege escalation μέσω setuid/setcap.

Λύση 6: NetworkPolicy

Default Deny:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: workshop-security
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Άδεια DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: workshop-security
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Από frontend προς backend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: workshop-security
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-egress-to-backend
  namespace: workshop-security
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080

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

Χρειάζονται τα Pods Egress προς το Kubernetes API;
Χρειάζονται Egress προς registry, monitoring ή logging;
Υπάρχουν εξωτερικά APIs με σταθερούς στόχους;
Έχει ληφθεί υπόψη IPv6/dual-stack;
Εφαρμόζει πράγματι το CNI αυτές τις policies;

Λύση 7: Ασφάλεια supply chain

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

# Έλεγχος supply chain

## Image

- Image: registry.example.com/shop/checkout-api:1.4.2
- Digest: sha256:<digest>
- Pull Policy: IfNotPresent ή Always ανάλογα με το πρότυπο της πλατφόρμας
- Registry: private, εγκεκριμένο
- Pull Secret: ειδικό για το Namespace, με rotation

## Έλεγχοι

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

## Stop criteria

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

Προαιρετικά:

trivy image registry.example.com/shop/checkout-api:1.4.2
cosign verify registry.example.com/shop/checkout-api@sha256:<digest>

Λύση 8: Admission Policy

Παράδειγμα Kyverno: Υποχρεωτικά labels

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: "?*"

Παράδειγμα Kyverno: Απαγόρευση privileged

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 σε mode Audit/Warn.
Αποκαταστήστε τα ευρήματα.
Τεκμηριώστε εξαιρέσεις με owner και ημερομηνία λήξης.
Ενεργοποιήστε το Enforce.
Ορίστε διαδρομή rollback για αστοχία policy.

Λύση 9: Ασφάλεια Secrets

Ενδεικτικός έλεγχος:

# Έλεγχος Secrets

## Κατάλογος

| Secret | Namespace | Χρήση | Owner | Rotation |
| --- | --- | --- | --- | --- |
| payment-api-token | shop-prod | checkout-api | payments-team | κάθε 90 ημέρες |

## Πρόσβαση

- Μόνο το checkout-sa επιτρέπεται να κάνει mount το Secret.
- Τα App ServiceAccounts δεν έχουν δικαιώματα list σε Secrets.
- Κανένα Secret σε logs, Events ή images.

## Κίνδυνος

Τα Kubernetes Secrets είναι API objects κωδικοποιημένα με Base64. Η προστασία εξαρτάται από RBAC, κρυπτογράφηση etcd, προστασία backups και πρόσβαση Pods.

## Προτεινόμενη επιθυμητή κατάσταση

- External Secrets ή CSI Secret Store για εξωτερική πηγή Secrets.
- Kubernetes Secret μόνο ως βραχύβια προβολή κατά την εκτέλεση.
- Δοκιμασμένο rotation.
- Περιορισμένη πρόσβαση μέσω ServiceAccount.

## Αντιμετώπιση διαρροής

1. Εντοπίστε τη χρήση του Secret.
2. Απομονώστε τα επηρεασμένα Pods.
3. Κάντε rotation του Secret στο σύστημα προέλευσης.
4. Ενημερώστε το Kubernetes Secret.
5. Επανεκκινήστε τα Pods.
6. Ελέγξτε logs, Events και audit.
7. Ενισχύστε RBAC και NetworkPolicy.

Λύση 10: Runtime detection

Υποδειγματικός πίνακας signals:

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

Σημαντική διάκριση:

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

Λύση 11: Compliance Evidence

Υποδειγματικό εύρημα:

# Compliance Evidence

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

- Χρονική σήμανση: 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 ημέρες

## Εύρημα 2: ServiceAccount με δικαιώματα ανάγνωσης Secret

- Πόρος: rolebinding/risky-binding
- Κίνδυνος: exfiltration Secret.
- Evidence: `kubectl auth can-i get secrets --as system:serviceaccount:team-a:app-sa -n team-a`
- Διόρθωση: αφαιρέστε δικαιώματα Secret και ελέγξτε τα συγκεκριμένα Secret mounts.

## Εύρημα 3: Pod χωρίς requests/limits

- Κίνδυνος: αναξιόπιστο scheduling και επίδραση noisy neighbor.
- Διόρθωση: προσθέστε requests/limits μέσω manifest και Admission.

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

- Κίνδυνος: μακρόβιο Secret αυξάνει τη ζημιά σε περίπτωση διαρροής.
- Διόρθωση: τεκμηριώστε owner, ημερομηνία rotation και σύστημα προέλευσης.

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

- Κίνδυνος: lateral movement.
- Διόρθωση: Default Deny και στοχευμένοι κανόνες Allow.

Το καλό evidence δεν αποτελείται μόνο από screenshot· περιλαμβάνει αναπαραγώγιμες εντολές, owner, κίνδυνο, προθεσμία και επανέλεγχο.

Λύση 12: Incident runbook

Υποδειγματικό runbook:

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

## 1. Triage

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

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

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

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

- Pod YAML
- Events
- Logs και προηγούμενα logs
- Image digest
- ServiceAccount και RBAC
- επηρεασμένα Secrets
- audit logs
- runtime alerts

Παράδειγμα:

kubectl get pod <pod> -n <ns> -o yaml > evidence-pod.yaml
kubectl describe pod <pod> -n <ns> > evidence-describe.txt
kubectl logs <pod> -n <ns> --all-containers > evidence-logs.txt
kubectl get events -n <ns> --sort-by=.metadata.creationTimestamp > evidence-events.txt

## 4. Containment

- Περιορίστε τα δικαιώματα ServiceAccount.
- Κάντε rotation tokens και Secrets.
- Αποκλείστε το Egress.
- Αποκλείστε το μη ασφαλές image.

## 5. Recovery

- Αναπτύξτε εκ νέου το workload από καθαρό image.
- Ελέγξτε την κατάσταση GitOps.
- Ελέγξτε CI/CD και registry.
- Εκτελέστε smoke tests.

## 6. Lessons learned

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

Παραβιασμένο Pod – ελάχιστες εντολές:

kubectl get pod <pod> -n <ns> -o wide
kubectl get pod <pod> -n <ns> -o yaml
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --all-containers
kubectl logs <pod> -n <ns> --all-containers --previous
kubectl get sa,role,rolebinding -n <ns>
kubectl auth can-i get secrets --as system:serviceaccount:<ns>:<sa> -n <ns>

Διαρροή Secret – ενέργειες:

Εντοπίστε πού χρησιμοποιείται το Secret.
Αποκλείστε την πρόσβαση ή απομονώστε το workload.
Κάντε rotation του Secret στο σύστημα προέλευσης.
Ενημερώστε το Kubernetes Secret.
Επανεκκινήστε τα Pods.
Ανακαλέστε τα παλιά tokens.
Ελέγξτε logs και audit για χρήση.
Διορθώστε RBAC και τη διαδικασία Secrets.

Cleanup

kubectl delete namespace workshop-security

Λίστα ελέγχου αξιολόγησης

Κριτήριο	Ολοκληρώθηκε;
Threat Model με assets και trust boundaries	☐
Εντοπίστηκαν διαδρομές privilege escalation στο RBAC	☐
Περιορίστηκε το αυτόματο mount ServiceAccount token	☐
Εφαρμόστηκε Pod Security Restricted	☐
Το SecurityContext περιλαμβάνει πλήρες hardening	☐
Το NetworkPolicy έχει εξαίρεση DNS και άδεια εφαρμογής	☐
Ο έλεγχος supply chain περιλαμβάνει stop criteria	☐
Το Admission Policy έχει mode λειτουργίας	☐
Τεκμηριώθηκαν rotation Secret και διαδρομή αντιμετώπισης διαρροής	☐
Το Runtime Detection μετατράπηκε σε σχέδιο απόκρισης	☐
Το Compliance Evidence διατυπώθηκε τεκμηριωμένα	☐
Το incident runbook περιλαμβάνει evidence και recovery	☐

Kubernetes Workshop: Advanced + Security – Ασκήσεις με λύσεις

Στόχος αυτού του φύλλου ασκήσεων

Προαπαιτούμενα

Επισκόπηση ασκήσεων

Μέρος A – Ασκήσεις

Άσκηση 1: Δημιουργία Kubernetes Threat Model

Στόχος

Σενάριο

Εργασία

Άσκηση 2: Εκτέλεση RBAC audit

Στόχος

Εργασία

Άσκηση 3: Περιορισμός αυτόματου mount ServiceAccount token

Στόχος

Εργασία

Άσκηση 4: Επιβολή Pod Security Restricted

Στόχος

Εργασία

Άσκηση 5: Workload hardening με SecurityContext

Στόχος

Εργασία

Άσκηση 6: NetworkPolicy Default Deny με DNS και άδεια εφαρμογής

Στόχος

Εργασία

Άσκηση 7: Έλεγχος ασφάλειας supply chain

Στόχος

Εργασία

Άσκηση 8: Σύνταξη Admission Policy

Στόχος

Εργασία

Άσκηση 9: Αξιολόγηση ασφάλειας και rotation των Secrets

Στόχος

Εργασία

Άσκηση 10: Ταξινόμηση runtime detection

Στόχος

Εργασία

Άσκηση 11: Δημιουργία compliance evidence

Στόχος

Εργασία

Άσκηση 12: Σύνταξη incident runbook

Στόχος

Εργασία

Μέρος B – Λύσεις και αναλυτική καθοδήγηση

Λύση 1: Threat Model

Λύση 2: RBAC audit

Λύση 3: Αυτόματο mount ServiceAccount token

Λύση 4: Pod Security Restricted

Λύση 5: Workload hardening

Λύση 6: NetworkPolicy

Λύση 7: Ασφάλεια supply chain

Λύση 8: Admission Policy

Παράδειγμα Kyverno: Υποχρεωτικά labels

Παράδειγμα Kyverno: Απαγόρευση privileged

Λύση 9: Ασφάλεια Secrets

Λύση 10: Runtime detection

Λύση 11: Compliance Evidence

Λύση 12: Incident runbook

Cleanup

Λίστα ελέγχου αξιολόγησης

31 modules as one continuous learning path.