DEV Community

The Cyber Sidekick
The Cyber Sidekick

Posted on

CKA Scenario 5 - Force nginx to TLS 1.3 with a ConfigMap edit + rolling restart (CKA Workloads)

#kubernetes #devops #tls #cka

Force nginx to TLS 1.3

An nginx server is accepting an old TLS version, and the exam wants it locked to TLS one point three. The config lives in a ConfigMap. The catch is that editing the ConfigMap alone changes nothing. Let's do it the way the CKA expects.

🎥 Watch the video: https://www.youtube.com/watch?v=rx-77YBw99w

This is a CKA Workloads & Scheduling walkthrough. Every command below is real output from a live cluster, and you can reproduce the whole thing yourself (scripts at the end).

The scenario

An nginx-static Deployment serves HTTPS, and its server config comes from a ConfigMap named nginx-config. Right now it allows both TLS one point two and one point three. Your task is to allow only TLS one point three, then make nginx actually use the change, so that a TLS one point two request fails.

  • nginx-static serves HTTPS from the nginx-config ConfigMap
  • It currently allows TLS 1.2 AND 1.3
  • Restrict ssl_protocols to TLS 1.3 only
  • A TLS 1.2 request to the Service must then fail

How nginx, ConfigMaps, and rolling restarts fit together

Two ideas drive this. First, ssl_protocols is an allow list; leave only TLSv1.3 and nginx rejects any older handshake. Second, a ConfigMap mounted into a pod updates the file on disk, but nginx only reads ssl_protocols when it starts. So you must roll the Deployment, with kubectl rollout restart, for the new value to take effect.

Inspect the current state

Start by seeing what is running and what the config says. The nginx-static Deployment, its Service on port four forty three, and the nginx-config ConfigMap are all here. Grep the rendered ConfigMap for the ssl_protocols line: it lists TLSv1.2 and TLSv1.3, so old clients still get in.

$ kubectl -n nginx-static get deploy,svc,configmap
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-static   1/1     1            1           17h
deployment.apps/tester         1/1     1            1           17h

NAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/nginx-static   ClusterIP   10.96.13.162   <none>        443/TCP   17h

NAME                         DATA   AGE
configmap/kube-root-ca.crt   1      17h
configmap/nginx-config       1      2s

$ kubectl -n nginx-static get configmap nginx-config -o yaml | grep ssl_protocols
        ssl_protocols TLSv1.2 TLSv1.3;
Enter fullscreen mode Exit fullscreen mode

Confirm TLS 1.2 works today

Prove the starting point from a real client. The tester pod curls the Service, pinned to a maximum of TLS one point two. It returns the page, which confirms the server accepts TLS one point two right now. That is exactly what we are about to stop.

$ kubectl -n nginx-static exec deploy/tester -- curl -sk --tlsv1.2 --tls-max 1.2 https://nginx-static.nginx-static.svc.cluster.local
TLS OK
Enter fullscreen mode Exit fullscreen mode

Roll the Deployment

Make nginx use it. A rolling restart replaces the pod, and the new pod reads the updated ssl_protocols on startup. Wait for the rollout to finish so you are testing the new pod, not the old one. This is the step people skip, and it is where the marks are.

$ kubectl -n nginx-static rollout restart deploy/nginx-static
deployment.apps/nginx-static restarted

$ kubectl -n nginx-static rollout status deploy/nginx-static
Waiting for deployment "nginx-static" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx-static" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-static" successfully rolled out
Enter fullscreen mode Exit fullscreen mode

Verify

Prove it both ways. The same TLS one point two request now fails the handshake; curl reports an alert and exits non-zero, which is what we want. A normal request, letting curl negotiate, connects over TLS one point three and still returns the page. Old TLS is gone, the service still works.

$ kubectl -n nginx-static exec deploy/tester -- curl -sSk --tlsv1.2 --tls-max 1.2 https://nginx-static.nginx-static.svc.cluster.local
curl: (35) OpenSSL/3.3.2: error:0A00042E:SSL routines::tlsv1 alert protocol version
command terminated with exit code 35

$ kubectl -n nginx-static exec deploy/tester -- curl -skv https://nginx-static.nginx-static.svc.cluster.local | grep -iE 'SSL connection|TLS OK'
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS
TLS OK
Enter fullscreen mode Exit fullscreen mode

Exam tips

A few traps to remember. Editing a ConfigMap does not restart anything; without a rollout restart your change is invisible. ssl_protocols is an allow list, so list only the versions you want. Test with the client version pinned, because curl will quietly use TLS one point three and hide the problem otherwise. And always verify against the Service name, not just the pod.

  • Editing a ConfigMap does nothing until you roll the Deployment
  • ssl_protocols is an allow-list: leave only TLSv1.3
  • Pin the client (curl --tls-max 1.2) or you won't see the failure
  • Verify against the Service, not just the pod

Recap

  • Set ssl_protocols to TLSv1.3 in the ConfigMap
  • kubectl rollout restart so nginx re-reads it
  • Verify TLS 1.2 fails, TLS 1.3 still serves
  • Subscribe + dev.to writeup

Reproduce this yourself

The entire scenario is scripted on a throwaway kind cluster: https://github.com/The-Cyber-Sidekick/TCS_CKA_2026_Exam_Scenarios

git clone https://github.com/The-Cyber-Sidekick/TCS_CKA_2026_Exam_Scenarios.git
cd TCS_CKA_2026_Exam_Scenarios/learning/scenarios/scenario5-nginx-tls-configmap
./setup.sh        # creates the cluster AND arms the scenario
# solve it by hand, or:
./solution.sh     # apply the answer key and verify
Enter fullscreen mode Exit fullscreen mode

If this helped, subscribe to The Cyber SideKick on YouTube for more CKA drills, and grab the newsletter at https://thecybersidekick.beehiiv.com.

Top comments (0)