Sample Solution: Kubernetes Exam 04 – Advanced + Security
Difficulty level: Advanced + Security
Language: English
Type: sample solution / expected-answer guide
This file is the matching solution for
04-advanced-security-kubernetes-assessment-EN.md.
All examples are intended for lab and review purposes. Do not use real Secrets, tokens, customer data, or production cluster contexts.
1. Usage Notes
Recommended Namespace:
export NS=exam-security
This sample solution combines review documentation, example manifests, and expected evidence. Not every lab contains Kyverno, Gatekeeper, ValidatingAdmissionPolicy, Trivy, Cosign, Falco, or Tetragon. If a tool is missing, the submission must correctly describe which control would be required in production and which stop criterion applies.
2. Part A: Sample Answers to Security Technical Questions
1. Central Kubernetes attack surfaces
Important attack surfaces are the API Server, authentication, RBAC, Admission, etcd, nodes, kubelet, container runtime, workloads, ServiceAccounts, Secrets, network, registry, CI/CD, GitOps, and add-ons. A review must consider API, node, workload, network, Secret, and supply-chain risks separately.
2. Authentication, authorization, and Admission Control
Authentication determines who is making a request. Authorization decides whether that identity may perform the action on the resource. Admission Control validates or mutates accepted requests before they are persisted in etcd. Example: a user may be allowed to create Pods, but Admission blocks privileged: true.
3. Risks of privileged, hostPath, hostNetwork, hostPID, and hostIPC
| Setting | Risk |
|---|---|
privileged: true |
container receives very broad host capabilities |
hostPath |
access to host filesystem and possible manipulation |
hostNetwork |
bypasses Pod network isolation, access to node network |
hostPID |
visibility into host processes |
hostIPC |
access to host IPC namespace |
These settings are acceptable only with strong justification, isolation, and an exception process.
4. ServiceAccounts and automatically mounted tokens
ServiceAccounts are workload identities. Automatically mounted tokens allow API access from the Pod. If a Pod is compromised, an attacker can misuse the token. Pods without API need should set automountServiceAccountToken: false.
5. Dangerous RBAC verbs and resources
Dangerous permissions include *, get/list/watch secrets, create pods, pods/exec, create rolebindings, bind, escalate, impersonate, nodes/proxy, and ClusterRoleBindings. Risks include Secret exfiltration, privilege escalation, lateral movement, and bypassing RBAC protection mechanisms.
6. Pod Security Standards
privileged permits almost everything and is not a security baseline. baseline blocks known dangerous settings but still permits broad standard workloads. restricted enforces stronger hardening such as non-root, seccomp, and reduced privileges. For new Namespaces, restricted is often the target state.
7. Expected SecurityContext fields
Expected fields:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- securityContext:
runAsUser: 1000
runAsGroup: 1000
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
In addition: no host Namespace usage, no uncontrolled hostPath mounts, resource limits, and writable paths only through defined volumes.
8. NetworkPolicy and lateral movement
NetworkPolicies reduce lateral movement because Pods can no longer communicate arbitrarily with each other or outward. They do not replace encryption. TLS or mTLS is required for transport confidentiality and integrity.
9. DNS egress with default deny
Default-deny egress also blocks DNS. Without a DNS exception, Pods cannot resolve Services or external targets by name. Therefore, TCP/UDP 53 to CoreDNS or kube-dns is explicitly allowed.
10. Supply-chain controls
Expected controls include approved registries, no latest in production, digest pinning, image scans, SBOM, signature verification, build provenance, Pull Secret ownership, and Admission verification.
11. Kubernetes Secrets and Base64
Kubernetes Secrets are API objects and are Base64-encoded by default; this is not encryption in the sense of secure confidentiality. Protection requires RBAC, etcd encryption, backup protection, minimal mounts, rotation, and possibly external Secret systems.
12. Robust incident evidence
Evidence contains timestamp, Namespace, Pod YAML, events, logs, previous logs, image digest, ServiceAccount, RBAC, can-i outputs, audit logs, runtime alerts, flow logs, and documented actions. It must be stored reproducibly and with minimal manipulation.
13. Prevention, detection, and response
Prevention prevents unsafe states, for example through Pod Security or Admission. Detection identifies suspicious behavior, for example through runtime alerts or audit logs. Response describes containment, evidence preservation, rotation, rebuild, and lessons learned.
14. Policy exceptions with owner, justification, and expiration date
Exceptions without owner and expiration date become permanent and invisible. A robust exception needs technical justification, risk, compensating controls, expiration date, review date, and approval.
15. Immediate actions for compromised Pod and Secret leak
- Determine triage and scope.
- Isolate Pod/Namespace; do not delete too early if evidence is required.
- Preserve logs, events, YAML, image digest, and RBAC.
- Rotate Secret and ServiceAccount token.
- Limit egress.
- Check image, CI, and GitOps.
- Rebuild and redeploy cleanly.
- Tighten policy and runbook.
3. Part B: Threat Model and RBAC Audit
B1: threat-model.md
# Threat Model: checkout-api
## Assets and Protection Value
| Asset | Protection value | Rationale |
| --- | --- | --- |
| `payment-api-token` | very high | access to payment API possible |
| `checkout-sa` | high | workload identity with possible API access |
| Deployment `checkout-api` | high | production workload |
| private image | high | supply-chain relevant |
| GitOps repository | very high | desired state and approval path |
| Ingress/Gateway route | medium to high | external attack surface |
## Trust Boundaries
- Internet to Gateway/Ingress.
- Gateway to `checkout-api`.
- Pod to Kubernetes API.
- Pod to Secret projection.
- CI to registry.
- GitOps Controller to cluster.
- Namespace `shop-prod` to other Namespaces.
## Attack Surfaces
- API Server and RBAC.
- ServiceAccount token.
- Container image and registry.
- Secret mount and Secret rotation.
- NetworkPolicy/egress.
- GitOps and CI permissions.
- Pod Security and host-adjacent fields.
## Abuse Scenarios
| Scenario | Risk | Control |
| --- | --- | --- |
| compromised Pod reads `payment-api-token` | payment API misuse | minimal Secret mounting, rotation, RBAC |
| `checkout-sa` may read/list Secrets | Secret exfiltration | least privilege, `can-i`, audit |
| old manifest with `privileged` and `hostPath` | host compromise | Pod Security, Admission, review |
| unsigned image is deployed | malware or manipulation | signature, digest, scan, SBOM |
| missing egress policy | exfiltration and C2 | default deny, DNS/app allow |
| CI has cluster-admin | pipeline compromise takes over cluster | GitOps, reduced CI permissions |
## Existing Controls
- Private registry.
- GitOps pipeline.
- ServiceAccount per workload.
- Runtime alert present.
## Missing Controls
- Complete NetworkPolicies.
- Documented Secret rotation path.
- Admission stop criteria.
- Signature/SBOM evidence.
- RBAC evidence.
- Incident runbook.
## Stop Criteria
- ServiceAccount can read/list Secrets without technical need.
- Workload uses `privileged`, `hostPath`, `hostNetwork`, `hostPID`, or `hostIPC` without approved exception.
- Image is not from an approved registry or not signed.
- Critical CVE without exception.
- Secret rotation is not possible or not documented.
- No NetworkPolicy for production workload.
## Evidence
- `kubectl auth can-i` outputs.
- Policy reports.
- Image digest, scan, SBOM, and signature status.
- NetworkPolicy manifests and tests.
- Incident evidence from logs, events, and runtime alerts.
B2: RBAC Audit
rbac-review.md and example 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
Required evidence for 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
Expected assessment:
| Check | Expected result | Assessment |
|---|---|---|
app-sa get configmaps |
yes | acceptable if technically required |
app-sa get secrets |
no | correctly minimized |
overprivileged-sa get secrets |
yes | critical |
overprivileged-sa create rolebindings |
yes | critical, possible escalation path |
Fix:
- Remove Secret permissions.
- Remove RoleBinding creation.
- Use a separate administrative break-glass process.
- Check effective permissions again with
can-i.
B3: ServiceAccount Token Automount
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
Check:
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
Sample assessment:
- Normal web apps without Kubernetes API need do not need a token.
- Controllers, operators, or apps that read or write Kubernetes objects need deliberately configured API permissions.
4. Part C: Workload, Network, and Supply-Chain Hardening
C1: Pod Security Restricted
Label 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
Insecure 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
Expected result: the API Server rejects the Pod through 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
Check:
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 follow-up questions:
- Does the Pod need Kubernetes API egress?
- Does it need registry, logging, monitoring, or external API targets?
- Can external targets be strictly limited?
- Is IPv6 or dual stack considered?
- Does the CNI actually enforce NetworkPolicies?
C4: supply-chain-review.md
# Supply-Chain Review
## Example 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` or platform standard; reproducible when immutable digests are used.
- ImagePullSecret: namespace-specific, owner `platform-registry`, rotation every 90 days.
## Check Status
| Control | Result | Decision |
| --- | --- | --- |
| approved registry | fulfilled | ok |
| no `latest` | fulfilled | ok |
| digest known | fulfilled | ok |
| CVE scan | no Critical, 1 High with ticket | conditionally ok |
| SBOM | present | ok |
| signature | valid | ok |
| build provenance | CI build ID and commit present | ok |
| Admission | only approved registry, digest, signature | required |
## Stop Criteria
- `latest` without digest in production.
- Image from a non-approved registry.
- Critical CVE without approved exception.
- Missing signature for production workloads.
- Pull Secret without owner or rotation.
C5: admission-policy.md
# Admission Policy
## Policy Goal 1: Required Labels
- Goal: enforce `owner`, `environment`, `cost-center`.
- Scope: Pods, Deployments, Namespaces according to platform standard.
- Mode: first audit/warn, then enforce.
- Example violation: Deployment without `cost-center`.
- Exception: owner, justification, expiration date, compensating control.
- Rollback: set policy back to audit or explicitly exempt a Namespace.
### Kyverno Example
```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 Goal 2: Prohibit `privileged: true`
- Goal: block host-adjacent privileges.
- Scope: Pods and workload Pod templates.
- Mode: warn/audit in existing Namespaces, enforce in new Namespaces.
- Example violation: container with `securityContext.privileged: true`.
- Exception: only temporary for approved system components.
- Rollback: move enforce back to audit if legitimate deployments are blocked.
### Kyverno Example
```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"
```
## Alternative Without Policy Engine
If Kyverno, Gatekeeper, or ValidatingAdmissionPolicy is unavailable, document the policy as a pseudo-manifest and operating requirement. The stop criterion remains: production workloads without this check are not approved.
5. Part D: Secrets, Detection, Compliance, and Incident Response
D1: secrets-review.md
# Secrets Review
## Inventory
| Secret | Namespace | Use | Owner | Rotation |
| --- | --- | --- | --- | --- |
| `payment-api-token` | `shop-prod` | checkout-api access to payment API | payments-team | every 90 days or immediately during incident |
## RBAC Access
- App ServiceAccounts do not receive `list/watch secrets` permissions.
- Secret is referenced only specifically as a volume or env value.
- Admin access requires audit.
## Mount Type
- Prefer read-only Secret volume.
- No output in logs.
- No Secrets in images or ConfigMaps.
## Risks
| Risk | Assessment |
| --- | --- |
| Logs | Secret must not be logged |
| Events | error messages must not contain values |
| Images | Secret must not be baked into the image |
| Backups | backup access equals Secret access |
| etcd | encryption at rest and access protection required |
## Comparison of Secret Systems
| Model | Benefit | Risk |
| --- | --- | --- |
| Kubernetes Secret | simple, API-native | RBAC/etcd/backup critical |
| External Secrets | sync from external store | controller permissions and store access critical |
| CSI Secret Store | runtime projection as volume | check rotation and node integration |
| Sealed Secrets | encrypted in Git | cluster private key critical |
| SOPS | encrypted files in Git | key management required outside the cluster |
## Rotation Path
1. Identify Secret usage.
2. Generate new value in the source system.
3. Update Kubernetes Secret or External Secret source.
4. Restart Pods or check reload.
5. Revoke old value.
6. Audit for misuse.
## Leak Action
- Isolate affected Pods.
- Rotate Secret immediately in the source system.
- Check ServiceAccount and RBAC.
- Preserve logs, events, and audit.
- Tighten NetworkPolicy and Admission.
D2: runtime-detection.md
# Runtime Detection
| Signal | Risk | Data source | First response | Evidence |
| --- | --- | --- | --- | --- |
| unexpected shell in container | interactive compromise | runtime sensor, audit `exec` | isolate Pod, check user | time, Pod, user, process |
| write access to `/etc`, `/proc`, `/sys` | manipulation or escape attempt | Falco/Tetragon/Tracee | freeze/isolate workload | path, process, container |
| unexpected egress | exfiltration or C2 | flow logs, DNS, CNI, runtime | block egress | target IP, DNS, Pod, Namespace |
| Kubernetes API access with ServiceAccount | token misuse | audit logs | check RBAC, rotate token | verb, resource, subject |
| suspicious `kubectl exec` | manual access without change | API audit | validate user/change | user, Pod, time, Namespace |
| OOMKill in security-relevant Pod | resource issue or attack signal | events, kubelet, metrics | separate app and security signals | events, limits, logs |
Detection does not replace prevention. It complements Pod Security, RBAC, NetworkPolicy, and Admission.
D3: compliance-evidence.md
# Compliance Evidence
## Finding 1: Namespace Without Pod Security Label
- Timestamp: 2026-06-12 10:00
- Resource: `namespace/team-legacy`
- Risk: unsafe Pods can be created without warning or rejection.
- Evidence: `kubectl get ns team-legacy --show-labels`
- Owner: team-legacy
- Fix: set `enforce/audit/warn` Labels.
- Deadline: 14 days
- Retest: check Labels again and verify that an unsafe Pod is rejected.
## Finding 2: ServiceAccount with Overly Broad Permissions
- Resource: `rolebinding/risky-binding`
- Risk: Secret exfiltration and escalation.
- Evidence: `kubectl auth can-i get secrets --as system:serviceaccount:team-a:app-sa -n team-a`
- Owner: team-a
- Fix: remove Secret permissions and RoleBinding creation.
- Exception: only with expiration date and security approval.
- Retest: `can-i` must return `no`.
## Finding 3: Pod Without Requests/Limits
- Resource: `deployment/legacy-api`
- Risk: unreliable scheduling, noisy-neighbor effect, poor HPA basis.
- Evidence: `kubectl get deployment legacy-api -o yaml`
- Owner: legacy-team
- Fix: add CPU/memory requests and limits.
- Retest: check manifest and QoS.
## Finding 4: Secret Without Rotation Note
- Resource: `secret/payment-api-token`
- Risk: long-term damage in case of leak.
- Evidence: missing Annotation `rotation.platform.example.com/next-date`.
- Owner: payments-team
- Fix: document owner, source system, and rotation date.
- Retest: simulate rotation in the runbook.
## Finding 5: Workload Without NetworkPolicy
- Resource: `namespace/shop-prod`, `deployment/checkout-api`
- Risk: lateral movement and uncontrolled egress.
- Evidence: `kubectl get networkpolicy -n shop-prod`
- Owner: shop-team
- Fix: default deny plus DNS, app, and required external egress rules.
- Retest: test allowed and blocked paths.
D4: incident-runbook.md
# Incident Runbook: Compromised Pod and Secret Leak
## 1. Triage
- Identify signal source: runtime alert, audit log, SIEM, user report.
- Determine affected resources: Namespace, Pod, Node, ServiceAccount, Secret, image.
- Assess criticality and potential data exposure.
## 2. Isolation
- Limit Namespace or Pod egress with NetworkPolicy.
- Do not delete the Pod too early if evidence is needed.
- If node compromise is suspected: cordon node, define evidence plan, then possibly drain and rebuild.
## 3. Evidence Preservation
```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
```
Also preserve:
- image digest,
- GitOps revision,
- audit logs,
- runtime alerts,
- flow logs and DNS queries.
## 4. Containment
- Reduce ServiceAccount permissions.
- Block or strongly restrict egress.
- Scale or redeploy affected workloads in isolation.
- Block unsafe image.
## 5. Secret and Token Rotation
1. Identify affected Secrets.
2. Rotate Secret in source system.
3. Update Kubernetes Secret.
4. Restart Pods or force reload.
5. Revoke old tokens.
6. Audit for usage of old values.
## 6. Image and CI Review
- Compare image digest with GitOps state.
- Check CI build, scan, and signature.
- Check registry access.
- If supply-chain compromise is suspected: block image and rebuild.
## 7. Rebuild and Redeploy
- Manifest fix through pull request.
- Rebuild, scan, and sign image.
- Perform GitOps sync.
- Run smoke tests and security tests.
## 8. Communication
- Name an incident commander.
- Inform security, platform team, app team, and, if required, data protection.
- Document status, risk, actions, and ETA.
## 9. Lessons Learned
- Which control was missing?
- Which detection worked?
- Which evidence was missing?
- Which policy will be tightened?
## 10. Policy Tightening
- Enforce Pod Security Restricted.
- Minimize RBAC.
- Standardize `automountServiceAccountToken: false`.
- Introduce NetworkPolicy default deny.
- Enforce image signatures and digest pinning.
- Improve Secret rotation and External Secret model.
## When a Pod Should Not Be Deleted Immediately
If logs, running processes, volumes, runtime signals, or container status are important for root-cause analysis, immediate deletion can destroy evidence. In that case, isolate and preserve first, then remove or redeploy.
6. Expected Submission Structure
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
Template for cleanup.md:
# Cleanup
```bash
kubectl delete namespace exam-security
```
If ClusterPolicies or cluster-wide demo resources were created, they must be removed separately and documented.
7. Cleanup
Remove Namespace:
kubectl delete namespace exam-security
Delete cluster-wide policies only if they were created in the lab:
kubectl delete clusterpolicy require-standard-labels --ignore-not-found
kubectl delete clusterpolicy disallow-privileged --ignore-not-found
8. Grading and Examiner Notes
An excellent Advanced + Security solution:
- separates risks by API, node, workload, network, Secrets, and supply chain,
- identifies ServiceAccount and RBAC escalation paths,
- reduces automatic ServiceAccount token mounts,
- satisfies Pod Security Restricted or documents deviations with stop criteria,
- provides a hardened SecurityContext,
- creates NetworkPolicies with default deny, DNS, and targeted app traffic,
- evaluates image, registry, tag, digest, scan, SBOM, signature, and Pull Secret,
- describes Admission Policies with audit/warn/enforce, exception, and rollback,
- handles Secrets with rotation, RBAC, etcd/backup risk, and leak actions,
- translates runtime signals into concrete responses,
- creates robust compliance evidence,
- writes an incident runbook with evidence, containment, rotation, recovery, and lessons learned,
- uses no real Secrets or production clusters.