Zero Trust Network Security with Identity-Aware Proxies
Not long ago, enterprises relied on a combination of VPN and firewalls deployed within the network perimeter to secure their infrastructure and applications to provide users remote access. Once users gained access to the network, they were implicitly trusted to access networks, servers, applications, and various endpoints.
In the current context of cloud, BYOD, remote work, and distributed microservices, VPNs and traditional perimeter security mechanisms are unable to keep up with the overwhelming need to secure an enterprise. The philosophy of implicitly trusting an entity within a network poses a huge security risk.
Every asset within the enterprise — networks, subnets, servers & desktops, databases, Kubernetes clusters, internally hosted applications, and third-party applications- must be secured independently. Every time a user or a process accesses an internal resource, its identity must be authenticated and verified against a predefined policy to determine the permissible action it is allowed to perform against the resource.
The idea of “Don’t trust anyone until they’ve been verified” is the core principle of the Zero Trust model. It translates to an architecture where a user/process is authenticated and authorized at every level, even if the entity enjoys the most privileged access to the network.
Implementing Zero Trust is not an easy task for enterprise IT. Some challenges include the sprawl of user identities, the proliferation of internal applications, reliance on third-party SaaS applications, and the rise of hybrid, multi-cloud, and edge architectures.
Users’ profiles and identities are stored in internal LDAP directory services, external SSO platforms, and custom databases. Defining a unified role-based access control for the profiles spanning diverse sources is extremely difficult.
The same is the case with internal web applications hosted within the enterprise data center and public cloud. The HTTP(S) endpoints must be secured to prevent external access. SaaS applications that are now an integral part of enterprise IT come with their own identity management mechanisms, increasing the complexity of authentication and authorization. Applications deployed in hybrid, multi-cloud, and edge environments suffer from a highly fragmented and disjoint access control policy.
Finally, gaining insights into the access and usage of these highly diverse and distributed assets poses another challenge. Performing audit trails, accessing logs, and reviewing past sessions per each asset is almost impossible. But, auditing and reviewing access is not only an essential aspect of Zero Trust, it is also a mandatory requirement for compliance.
The Rise of Identity-Aware Proxy (IAP)
Identity-Aware Proxy (IAP) replaces the traditional VPN-based access control mechanism with a modern, context-aware, and identity-aware authentication and authorization approach. Instead of defining access policies per resource such as a server, Kubernetes cluster, or application, IAP centralizes the policy definitions and access control by mapping the identities registered with each resource. This puts enterprise IT in a better position to implement Zero Trust security.
Technically, IAP has two core components — the access plane and the agent. The access plane has the authentication and proxy components responsible for tunneling the sessions to each agent registered with it. The agent runs closer to the asset representing a server, a Kubernetes cluster, a database server, or a web application.
The access plane maintains the list of users, roles, and the policies that bind them together. When a user logs into the access plane, he gets authenticated, and his identity is determined to derive associated roles and policies. Each authenticated user has a direct mapping to the user registered with the target resource.
Once authenticated, the proxy impersonates the user to access the resource. In that process, the access control policy is imposed based on the authenticated user’s role. Since the proxy is aware of the identity and context, it is called an identity-aware proxy.
The agent running closer to the resource is responsible for enforcing the policy and translating the actions as per the expected protocol. For example, the agent representing a MySQL database is aware of the original identity of the user and thus applies the policy specific to the resource. Similarly, when a Kubernetes user tries to access a cluster, the agent is responsible for enforcing the policy and translating the actions initiated through Kubernetes API. The agents are deployed behind the firewall or in virtual private network environments.
IAP also comes with a dedicated client in the form of a CLI or a GUI that lets users log onto the access plane. The access plane may be available within a hosted environment in the cloud or can be self-hosted within the enterprise data center. It is accessible via a well-defined DNS name or a static IP address. The communication between the client, the access plane, and the agents is encrypted based on the industry standard mechanisms.
IAP’s Role-based Access Controls (RBAC) are independent of the users and resources. Once the proxy authenticates the user, the RBAC becomes effective. This decoupling of policies from the original identity makes it highly scalable. IAP can enforce multifactor authentication for each connected session.
Since the policies are defined and managed centrally by dedicated teams, it brings better governance and manageability to enterprise-wide access control. Irrespective of where the user profiles are stored (LDAP, cloud-based directory services, and IDaaS), IAP applies the same set of consistent policies to an authenticated user. Those policies are valid until the user’s session expires or an explicit sign-out action.
IAP is not confined to remote or interactive users. It can be easily extended to automation tools based on Infrastructure as Code (Code) and programmable infrastructure. For example, Jenkins can use IAP for continuous integration and deployment based on identities with the least privileges. The same is true with Ansible playbooks that need an SSH key to automate software installation and configuration.
Developers familiar with reverse proxies such as ngrok may think IAP is similar. But the key difference between the two is the identity awareness and RBAC policies.
Enterprises considering Zero Trust security may consider IAP a modern replacement for traditional VPN-based remote access. Google Cloud IAP, Teleport, StrongDM, HashiCorp Boundary, and F5 BIG-IP APM are some of the IAP offerings in the market.
As a part of the IAP series, I will introduce the open source version of Teleport to access servers, databases, Kubernetes clusters, and web applications. Stay tuned.
Disclosure: The author of this post has written for the Teleport blog.