The starting point.
I deployed FreeRADIUS in a Docker-based Linux environment as part of my infrastructure work. The container needed to start reliably and read its mounted configuration, without exposing authentication ports more broadly than intended.
What I did.
- I checked the image's service account and configuration paths. The freerad account used UID and GID 101 in the inspected image.
- I diagnosed a configuration-permission problem and corrected the mounted configuration's group ownership instead of making it writable to everyone.
- I confirmed that the container stayed running and inspected the UDP port bindings. During the recorded test, ports 1812 and 1813 were bound to loopback.
Decisions & trade-offs.
Repair ownership, not permissions indiscriminately
A service-account-aware correction is more precise than chmod 777. The appropriate owner and group must be checked against the actual image and mounted files.
Start with loopback-only listeners
Local bindings reduce exposure during setup. They also mean remote network devices cannot authenticate until intentional listener, firewall and client configuration changes are made.
Keep health and authentication separate
A running container demonstrates service startup. Authentication success, shared-secret handling, EAP certificates and network access policy require their own tests.
Inspect service health and the access boundary
Reconstructed, read-only commands. No shared secrets, live addressing or configuration exports are included.
docker inspect --format \
'Status={{.State.Status}} Restarts={{.RestartCount}}' freeradius
docker port freeradius
docker exec freeradius sh -c \
'id freerad; ls -ld /etc/raddb /etc/freeradius'
# Confirm the intended bind address, not just the port number.What I checked.
I verified the service account, examined the configuration-directory relationship, checked container state and restart count, and reviewed the published port bindings. That established a stable local service baseline, not a complete production network-access deployment.
Scope & limits.
This is a setup and diagnostics case study. It does not claim completed 802.1X enforcement, a verified EAP design or production deployment. The inspected UID and paths are image-specific and must be rechecked when the image changes.
A healthy process is a baseline. A tested trust boundary is the objective.