Skip to content
ICASecuring WorkloadsSingle nodeHard

Require a valid JWT for a workload

Scenario ica-sec-003 · about 9 minutes · 9 points · 5 grader checks

Validate end-user JWTs with a RequestAuthentication and an inline key set, and deny requests that carry no token.

  • jwt
  • requestauthentication
  • authorizationpolicy
  • request-principals
  • securing-workloads

What you will practise

  • Configure a RequestAuthentication with an issuer and an inline JWKS
  • Require a request principal with an AuthorizationPolicy
  • Tell 401 (invalid token) apart from 403 (no token, not allowed)

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 ica-sec-003

Task

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

Istio is installed. Namespace "billing" is in the mesh and runs the Service "api" (port 8000, pods labelled app=api) and the Deployment "curl". Tokens for "api" are issued by "https://auth.goldenkube.lab". The issuer's JSON Web Key Set is in /opt/ica/jwks.json. /opt/ica/jwt/valid.jwt is a valid token, /opt/ica/jwt/forged.jwt is signed with a different key. 1. Create a RequestAuthentication "api-jwt" in "billing" for the pods with label app=api that validates tokens of the issuer "https://auth.goldenkube.lab" against this key set. Embed the key set in the resource. 2. Create an AuthorizationPolicy "api-require-jwt" in "billing" for the same pods that allows only requests with a valid token from this issuer. Requests without a token must get 403, requests with an invalid token 401.

Requirements and details

Certification
ICA · Istio Certified Associate
Domain
Securing Workloads
Difficulty
Hard
Cluster topology
Single node
Cluster features
None beyond the base cluster
Recommended time
9 minutes
Points
9
Grader checks
5
Kubernetes version
1.35
Minimum CLI version
0.1.0
Scenario version
1
Published

Grading runs locally: 5 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 Securing Workloads labs

ICASecuring WorkloadsEasy

Mesh-wide strict mTLS with a namespace exception

Require mutual TLS for the whole mesh while one legacy namespace keeps accepting plain text.

Single node · ~7 min · 7 points

  • mtls
  • peerauthentication
  • strict
  • permissive
  • securing-workloads

goldenkube start ica-sec-001

ICASecuring WorkloadsMedium

Allow one service account to call two paths

Write an ALLOW AuthorizationPolicy that admits a single workload identity for GET on two paths and nothing else.

Single node · ~8 min · 8 points

  • authorizationpolicy
  • allow
  • principals
  • spiffe
  • securing-workloads

goldenkube start ica-sec-002

ICASecuring WorkloadsHard

Terminate TLS at the ingress gateway with an HTTPS redirect

Serve a host over HTTPS at the ingress gateway from a Kubernetes TLS secret and redirect plain HTTP to HTTPS.

Single node · ~10 min · 10 points

  • gateway
  • tls
  • https-redirect
  • credentialname
  • securing-workloads

goldenkube start ica-sec-004

ICASecuring WorkloadsMedium

Deny by default, allow reads, deny one caller

Combine a namespace-wide deny-all with an ALLOW and a DENY AuthorizationPolicy and reason about their evaluation order.

Single node · ~9 min · 9 points

  • authorizationpolicy
  • deny-by-default
  • allow-nothing
  • deny
  • securing-workloads

goldenkube start ica-sec-005

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