Skip to content
ICASecuring WorkloadsSingle nodeHard

Terminate TLS at the ingress gateway with an HTTPS redirect

Scenario ica-sec-004 · about 10 minutes · 10 points · 6 grader checks

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

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

What you will practise

  • Create a TLS secret the ingress gateway can use
  • Configure a SIMPLE TLS server with credentialName
  • Redirect HTTP to HTTPS on the gateway
  • Verify the served certificate with openssl and curl --resolve

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

Task

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

Istio is installed (default profile). Namespace "shop" is in the mesh and runs the Service "web" (port 8000). A certificate for shop.example.com and its key are in /opt/ica/certs/shop.crt and /opt/ica/certs/shop.key; the issuing CA is /opt/ica/certs/ca.crt. 1. Create a TLS secret "shop-tls" from this certificate and key in the namespace where the default ingress gateway runs. 2. Create a Gateway "shop-gateway" in "shop" on the default ingress gateway with: - port 443, protocol HTTPS, host shop.example.com, TLS mode SIMPLE using the secret "shop-tls"; - port 80, protocol HTTP, host shop.example.com, redirecting every request to HTTPS. 3. Create a VirtualService "shop" in "shop", bound to "shop-gateway", that routes shop.example.com to the Service "web" on port 8000.

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
10 minutes
Points
10
Grader checks
6
Kubernetes version
1.35
Minimum CLI version
0.1.0
Scenario version
1
Published

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

Require a valid JWT for a workload

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

Single node · ~9 min · 9 points

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

goldenkube start ica-sec-003

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.