Zero Trust network security with identity-aware proxies
Not so long ago, enterprises relied on a combination of VPNs and firewalls deployed at the network perimeter to secure their infrastructure and applications to provide users with remote access. Once users gained access to the network, they were implicitly authorized to access networks, servers, applications and various terminals.
In today’s cloud, BYOD, remote work, and distributed microservices environment, VPNs and traditional perimeter security mechanisms are unable to meet the compelling 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 and workstations, databases, Kubernetes clusters, internally hosted applications, and third-party applications—must be independently secured. Each time a user or process accesses an internal resource, their identity must be authenticated and checked against a predefined policy to determine the authorized action they are allowed to perform on the resource.
The idea of ”Don’t trust anyone until they’ve been verified” is the basic tenet of the Zero Trust model. This results in an architecture where a user/process is authenticated and authorized at all levels, even if the entity has the most privileged access to the network.
Implementing Zero Trust is no easy task for enterprise IT. Some challenges include the proliferation of user identities, the proliferation of in-house applications, reliance on third-party SaaS applications, and the rise of hybrid, multi-cloud, and edge architectures.
User profiles and identities are stored in internal LDAP directory services, external SSO platforms, and custom databases. Defining unified role-based access control for profiles spanning multiple sources is extremely difficult.
The same is true for internal web applications hosted in the corporate data center and public cloud. HTTP(S) endpoints must be secured to prevent external access. SaaS applications that have become an integral part of enterprise computing have their own identity management mechanisms, increasing the complexity of authentication and authorization. Applications deployed in hybrid, multicloud, and edge environments suffer from a highly fragmented and disjointed access control policy.
Finally, gaining insight into the access and use of these highly diverse and distributed assets poses another challenge. It is nearly impossible to perform audit trails, access logs, and review past sessions for each asset. But access auditing and review is not only a core aspect of Zero Trust, it’s also a mandatory requirement for compliance.
The Rise of the 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 policy definitions and access control by mapping registered identities to each resource. This puts enterprise IT in a better position to implement Zero Trust security.
Technically, IAP has two main components: the access plan and the agent. The access plane has the authentication and proxy components responsible for tunneling sessions to every agent registered with it. The agent runs closer to the asset representing a server, Kubernetes cluster, database server, or web application.
The access plan manages the list of users, roles, and policies that bind them. When a user connects to the access plan, they are authenticated and their 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 this process, the access control policy is imposed based on the role of the authenticated user. Since the proxy knows the identity and the context, it is called an identity-aware proxy.
The agent running closest to the resource is responsible for enforcing policy and translating actions according to the expected protocol. For example, the agent representing a MySQL database knows the original identity of the user and thus applies the policy specific to the resource. Similarly, when a Kubernetes user attempts to access a cluster, the agent is responsible for enforcing policy and translating actions initiated through the Kubernetes API. 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 GUI that allows users to connect to the access plan. The access plan can be available in a cloud-hosted environment or can be self-hosted in the company’s data center. It is accessible via a well-defined DNS name or a static IP address. Communication between client, access plan and agents is encrypted based on industry standard mechanisms.
IAP’s role-based access controls (RBAC) are independent of users and resources. Once the proxy authenticates the user, RBAC becomes effective. This decoupling of policies from the original identity makes it highly scalable. IAP can enforce multi-factor authentication for each connected session.
Since policies are centrally defined and managed by dedicated teams, this improves the governance and manageability of enterprise-wide access control. Regardless of where user profiles are stored (LDAP, cloud-based directory services, and IDaaS), IAP applies the same consistent set of policies to an authenticated user. These policies are valid until the user’s session expires or until an explicit logout action.
IAP is not limited 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 identity-based continuous integration and deployment with least privilege. The same goes for Ansible playbooks which require an SSH key to automate software installation and configuration.
Developers familiar with reverse proxies such as ngrok may think IAP is similar. But the main difference between the two is identity awareness and RBAC policies.
Companies considering Zero Trust security can consider IAP as 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 part of the IAP series, I will showcase the open source version of Teleport for accessing servers, databases, Kubernetes clusters, and web applications. Stay tuned.
Disclosure: The author of this article wrote for the Teleport blog.