Skip to content
CNPESecurity and Policy EnforcementSingle nodeHard

Service mesh: enforce strict mTLS for a namespace with Istio

Scenario cnpe-sec-001 · about 16 minutes · 11 points · 7 grader checks

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.

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

What you will practise

  • Enable automatic sidecar injection for namespaces and roll the workloads
  • Enforce STRICT mutual TLS with a namespace-wide PeerAuthentication
  • Prove the policy with a meshed and a non-meshed client

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-001

Task

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

Istio is installed (istiod in istio-system). The Deployment "ledger" (Service "ledger", port 80) runs in namespace "bank". The Deployment "web" in namespace "frontend" and the Deployment "client" in namespace "legacy" call http://ledger.bank/. 1. Enable automatic sidecar injection for the namespaces "bank" and "frontend" and make the running ledger and web pods carry the Istio proxy. Namespace "legacy" stays outside the mesh. 2. Create the PeerAuthentication "default" in namespace "bank" that requires mutual TLS (STRICT) for every workload in the namespace. 3. Afterwards web must still get HTTP 200 from http://ledger.bank/ and client in legacy must no longer get a response.

Requirements and details

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

Grading runs locally: 7 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 EnforcementMedium

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

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.

Single node · ~16 min · 11 points

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

goldenkube start cnpe-sec-002

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.