Radius with Google Cloud Identity
You set up radius with google cloud identity by linking a RADIUS server to Google Secure LDAP. The RADIUS server checks user passwords and group memberships against your Google directory. Teams use this flow to control Wi-Fi and VPN logins from one place. Still, network login rules often grant broad access once a user gets onto the network. A user who passes the network check can still reach sensitive databases and internal servers. How radius with google cloud identity works in practice Goog
Identity and Access Management (IAM) + Blast Radius Reduction: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up radius with google cloud identity by linking a RADIUS server to Google Secure LDAP. The RADIUS server checks user passwords and group memberships against your Google directory. Teams use this flow to control Wi-Fi and VPN logins from one place. Still, network login rules often grant broad access once a user gets onto the network. A user who passes the network check can still reach sensitive databases and internal servers.
How radius with google cloud identity works in practice
Google Cloud Identity does not run a native RADIUS server in the cloud. Instead, it offers a Secure LDAP service that acts as your central directory. You run a separate RADIUS server on a virtual machine or local host. This server takes login requests from your Wi-Fi gear or VPN hardware. Then the RADIUS server talks to Google over a secure connection to check the user.
First, an admin creates an LDAP client inside the Google admin console. This step gives you a client certificate and a key for encrypted traffic. Next, you load that certificate onto your RADIUS server so it can trust Google. You also set up the RADIUS server to read user groups from the directory. When a staff member tries to log in, the network device asks the RADIUS server. The server checks the password and group with Google and sends back an approval.
Where network login rules fall short for databases and servers
This setup solves a major problem for IT teams. You do not need to keep separate password lists on every router or VPN box. When someone leaves the company, you disable their Google account in one spot. That person loses Wi-Fi and VPN entry right away.
Yet network entry is only the first step in security. RADIUS decides who can join the network, not what they do afterward. Once an engineer connects to the VPN, they still need database logins and server keys. Teams often share static database passwords or wide admin roles with everyone on the VPN. Network logs show when a user logged in, but they never show which SQL queries ran. They also cannot stop a risky command or mask emails and card numbers in query results.
Identity and Access Management (IAM) + Blast Radius Reduction: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Moving from network entry to command-level control
Relying only on network login rules forces teams into all-or-nothing permissions. Anyone on the right VPN group can open a direct session to production data stores. If an attacker steals a laptop or guesses a login, the whole network opens up. Even trusted engineers can run a bad delete statement by mistake during an urgent fix.
To close this gap, teams need controls that work at the command and query level. Instead of trusting everyone on the network, you check every single action in flight. You can require a peer to approve a dangerous database command before it runs. You can also rewrite sensitive fields like phone numbers or national IDs in query output. This approach keeps data safe even after a user passes the initial network check.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does Google Cloud Identity include a built-in RADIUS service?
No, Google does not host a direct RADIUS endpoint. You must run your own RADIUS software and link it to Google Secure LDAP.
Can we check Google group memberships during a RADIUS login?
Yes, your RADIUS server can read group attributes through the Secure LDAP connection. You can use these groups to assign users to specific network segments or VPN roles.
Does RADIUS log the commands a user runs on internal servers?
No, RADIUS only tracks when a user logs into the network and disconnects. It has no view into SSH commands, database queries, or API calls inside the session.