feat(radius): in-cluster 802.1X RADIUS via authentik (test SSID) #1554
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: konairius/homelab#1554
Reference in New Issue
Block a user
In-cluster 802.1X RADIUS backed by authentik, for the test SSID "Renner Test". The UDM RADIUS, "Unifi Radius" provider, "Local Radius" outpost and the existing WLANs are unchanged.
Path: client → EAP-TTLS (Let's Encrypt cert
radius.renner.uno) → FreeRADIUS (radius-lb, 10.2.99.91 / fd99::91) → inner PAP proxied to the new authentik RADIUS outpost "802.1X Radius" (ak-outpost-8021x-radius) → VLAN from the group attributedot1x_vlan(lowest wins; no group → Access-Reject).Changes
blueprints-configmap.yaml,helmrelease.yaml): blueprintdot1x-radius.yamlwith flow,dot1x-has-vlanpolicy, VLAN property mapping (Tunnel-Type/Medium-Type/Private-Group-Id plusCisco-AV-Pair dot1x-vlan=<id>), provider, applicationdot1xand a 2-replica outpost.DOT1X_OUTPOST_SECRETis set on the worker only (optional: true), so SSO does not depend on it.radius-secretsfrom OpenBaoapps/radius; Certificateradius-tlsforradius.renner.uno(ClusterIssuerletsencrypt-cluster).freeradius-config.yaml,freeradius.yaml,freeradius-cnp.yaml):Cisco-AVPairtranslated. An Accept without a VLAN is rejected in inner-tunnel post-auth.status_check = requestwith the non-existent userdot1x-status-probe(always rejected; sent only while the home server is zombie/dead),response_window = 5.proxy_dedup_window = 10(>response_window): a NAS retransmit is never forwarded to the outpost. In FreeRADIUS 3.2.10, a TTLS inner request sent twice to the home server stays in the proxy hash whileeapttls_postproxy()rewritesrequest->proxy->dst_port(part of the hash key), so the freed request is never removed and the next proxy reply lookup segfaults radiusd.freeradius-server(3.2.x-alpine); alertsRadiusDeploymentDown/RadiusDeploymentDegradedfor FreeRADIUS and the outpost.tests/radius/run.sh: runs the production ConfigMap and Deployment args in Docker against a mock outpost, witheapol_testover IPv4 and IPv6. It checks:docs/radius/dot1x.md: client setup (Android, Linux, Windows 11 with server-certificate validation, Apple profiledocs/radius/clients/renner-test.mobileconfig), Loki latency queries, the VLAN contract.Rollout order
The worker restarts (Reloader) and applies the blueprint, which creates the outpost Deployment and Service. FreeRADIUS resolves
ak-outpost-8021x-radiusat startup and crash-loops until that Service exists;RadiusDeploymentDowncan fire once during the first rollout.UniFi objects (firewall policy for APs → 10.2.99.91, RADIUS profile, WLAN "Renner Test") are created via the API after merge.
🤖 Generated with Claude Code
🤖 Automated review — model
claude-opus-5-5, commit3ed987dd74ebc8394f00108bf7dd7821dc028837.Summary
This PR adds an in-cluster 802.1X path for the "Renner Test" SSID. FreeRADIUS ends the EAP-TTLS tunnel and sends the inner PAP request to a new authentik RADIUS outpost, which is managed by a blueprint. The PR also adds a certificate, an ExternalSecret, network policies, image automation, alerts, a Docker-based functional test and docs. The design is careful and well tested, and I found no defect I could verify. The two open risks are in authentik and the Helm chart, which I couldn't check from the repo.
mergeableis true. There is no linked issue and no earlier review from me, so this is a first review.⚪ Unverified
kubernetes/apps/authentik/helmrelease.yaml:183-189).worker.envlist addsDOT1X_OUTPOST_SECRET. If chart 2026.8.3 replacesglobal.envwithworker.envinstead of joining them, the worker losesAUTHENTIK_SECRET_KEY, the Postgres password and the other variables.helm templatebefore merging.helmrelease.yaml:85-92).!Envare put inglobal.env, because "if only the worker had it, blueprint apply would crash on startup with KeyError".DOT1X_OUTPOST_SECRETon the worker only. If the server also resolves blueprint!Envtags, as that comment suggests, the server may fail ondot1x-radius.yaml.optional: trueand no Secret present,shared_secretwould resolve to an empty orNonevalue.blueprints-configmap.yaml, thedot1x-vlan-mappingexpression).packet[64] = [b"..."]) insidetry/except: pass, and callsdefine_attribute.Cisco-AV-Pairfallback, translated in the FreeRADIUS inner tunnel, covers this case. The plan's post-merge spike (Task 2, Step 5) should record which of the two paths is actually used.🟡 Suggestions
kubernetes/apps/authentik/freeradius-cnp.yaml:27-45).dot1x-outpost-freeradius-ingressis additive.infrastructure/network-policies/authentik-ns.yamlalready allows ingress to every pod from the wholeauthentiknamespace, and fromtraefik,database,monitoring,paperlessand host/remote-node.client_networksalso covers the whole pod CIDR. The comment admits this.docs/radius/dot1x.mdthat the shared secret is the only guard on this hop, or add a deny rule for UDP 1812 on the outpost from anything except FreeRADIUS.freeradius-config.yaml,proxy.conf).status_check = none,response_window = 3,zombie_period = 20andrevive_interval = 10.response_windowor a shorterrevive_interval. Also document that the hostname is resolved once at startup, so a re-created outpost Service needs a FreeRADIUS restart.freeradius(freeradius.yaml). Node drains could take both replicas down if the two drains overlap.🟢 Nits
docs/superpowers/plans/2026-11-03-dot1x-radius-authentik.mdstill usesak-outpost-802-1x-radius, secrets inapps/authentikandauthentik-secrets. That differs from what was built:8021x-radius,apps/radiusandradius-secrets.clients.confand the CNP addfd02:10::/64. This is harmless, but the docs and the code disagree.Tests
tests/radius/run.shcovers the FreeRADIUS side well. It uses the production ConfigMap and Deployment args, and checks:Nothing tests the authentik side: the blueprint, the property mapping output and the policy. That rests on the post-merge spike described in the plan.
Recommendation
Looks reasonable — no blocking issues; comments above are optional. Before merging, check the Helm env merge and the server-side
!Envquestion.New commits pushed, approval review dismissed automatically according to repository settings
🤖 Automated review — model
claude-opus-5-5, commit64e19b40877299e7eb7e220303467bbdaf056c21.Summary
This is a re-review. Two commits landed after my review at
3ed987dd:f9eb38e2adds active outpost status checks, a recovery test case and corrections to the docs and spec.64e19b40setsproxy_dedup_window = 10, aboveresponse_window = 5, to avoid a crash in radiusd 3.2.10 after a stall.My earlier review had no 🔴. Status of the earlier 🟡 points:
docs/radius/dot1x.mdnow says the shared secret is the only guard on the FreeRADIUS → outpost hop.status_check = request, and the docs say the outpost Service name is resolved once at startup.freeradius: still open. It was optional.The two earlier unverified points (env merge, server-side
!Env) are unchanged in code. Only thehelmrelease.yamlcomment was reworded to claim there is no KeyError. The new commits look correct to me.mergeableis true.⚪ Unverified
kubernetes/apps/authentik/freeradius-config.yaml,proxy.conf,status_check = request).dot1x-status-probeAccess-Request: 3 answers, one check every 6 s.tests/radius/mock_outpost.pyanswers every request whether or not it carries a valid Message-Authenticator (request_mais only logged). So the test can't show whether radiusd 3.2.10 puts Message-Authenticator on status-check requests.kubernetes/apps/authentik/helmrelease.yaml:91-92).!Envto None or the default instead of raising KeyError. I couldn't check this against authentik 2026.8 from the repo.dot1x-radius.yaml, the server would writeshared_secret: None/empty. The worker would then write the real value back, so the two would keep overwriting each other.🟡 Suggestions
tests/radius/run.sh,check_recovery 20). After a dead marking, revival needs 3 probe answers 6 s apart, so roughly 12–18 s. The commit reports 10–15 s against a bound of 20 s. A slow CI host could make this flaky. Consider a bound of 25–30 s, or derive it fromcheck_interval × num_answers_to_alivepluscheck_timeout.🟢 Nits
proxy_dedup_window = 10(freeradius-config.yaml,radiusd.conf) could say that 10 is FreeRADIUS's upper bound for this setting. Then nobody later "fixes" the crash by raisingresponse_windowabove it. I'm going from memory on the bound; I didn't check it in the repo.Tests
check_recoverycovers the new behaviour directly: it stalls the outpost until it is marked dead, resumes it, and expects a successful login within a set time with radiusd still running. The commit reports 12/12 green runs after the fix and 2/2 crashes before it. The mock outpost doesn't check Message-Authenticator on requests, so the probe-acceptance risk above stays untested.Recommendation
Looks reasonable — no blocking issues; comments above are optional. There were no earlier 🔴 points, and the new commits add none.