Skip to content
CNPESecurity and Policy EnforcementSingle nodeMedium

Guardrails: least-privilege RBAC for a CI identity and a Kyverno pod baseline

Scenario cnpe-sec-002 · about 16 minutes · 11 points · 8 grader checks

Give the CI service account exactly the rights it needs to roll out Deployments in one namespace, and enforce a pod baseline there with Kyverno: non-root containers and pinned image tags.

  • rbac
  • kyverno
  • policy-as-code
  • admission-control
  • least-privilege
  • security

What you will practise

  • Write a namespaced Role and RoleBinding for a service account from another namespace
  • Enforce pod security rules with a Kyverno ClusterPolicy
  • Test admission policies with server-side dry-run

Start this lab

With the CLI installed and signed in, this command provisions a single node cluster on your Mac, applies the scenario setup and prints the task below.

goldenkube start cnpe-sec-002

Task

The task text exactly as the CLI shows it. Solve it on the cluster, then run goldenkube submit.

Kyverno is installed. The ServiceAccount "deployer" in namespace "ci" is used by the CI system to roll out applications into namespace "apps". 1. In namespace "apps" create the Role "deployer" and the RoleBinding "deployer" for ci:deployer. It may get, list, watch, create, update and patch Deployments and get and list Pods — nothing else (no delete, no Pod creation, no other namespace). 2. Create the Kyverno ClusterPolicy "pod-baseline" that blocks (Enforce) every Pod in namespace "apps" that - does not run as non-root (runAsNonRoot: true on the pod or on every container), or - uses an image without a tag or with the tag "latest". Pods in other namespaces are not affected.

Requirements and details

Certification
CNPE · Certified Cloud Native Platform Engineer
Domain
Security and Policy Enforcement
Difficulty
Medium
Cluster topology
Single node
Cluster features
None beyond the base cluster
Recommended time
16 minutes
Points
11
Grader checks
8
Kubernetes version
1.35
Minimum CLI version
0.1.0
Scenario version
1
Published

Grading runs locally: 8 state checks read your cluster when you submit; the scenario passes when every check passes. Hints, the reference solution and the check definitions are available only inside the CLI, not on this page.

Install the CLICreate a free account

More Security and Policy Enforcement labs

CNPESecurity and Policy EnforcementHard

Service mesh: enforce strict mTLS for a namespace with Istio

Move the bank and frontend workloads into the Istio mesh and require mutual TLS for every workload in bank, so meshed clients still reach the ledger while plaintext clients are refused.

Single node · ~16 min · 11 points

  • istio
  • service-mesh
  • mtls
  • peerauthentication
  • zero-trust
  • security

goldenkube start cnpe-sec-001

CNPESecurity and Policy EnforcementHard

Supply chain: Trivy SBOM and a Gatekeeper registry allow-list

Produce a CycloneDX SBOM for an image from the node's containerd store with Trivy and publish it as a ConfigMap, then restrict the registries Pods in a namespace may pull from with an OPA Gatekeeper ConstraintTemplate and Constraint.

Single node · ~18 min · 10 points

  • supply-chain
  • sbom
  • cyclonedx
  • trivy
  • gatekeeper
  • opa
  • rego
  • security

goldenkube start cnpe-sec-003

Independent community project, not affiliated with or endorsed by CNCF or The Linux Foundation. Lab results are practice feedback, not an exam score.