Key Takeaways
Access management is the process of identifying whether a user, or a group of users, should be able to access a given resource, such as a host, a service, or a database. For example, is it okay for a developer to be able to log in to a production application server using SSH, and if so then for how long? If an SRE is attempting to access a database during off-call hours, should they be allowed to do so? If a data engineer has moved to a different team, should they continue having access to the ETL pipelines S3 buckets?
Before the proliferation of various infrastructure and data services on the cloud, access management was a relatively simple problem for DevOps and Security teams to solve. VPNs and bastion hosts were (and still are) the preferred mechanisms to cordon off all critical resources at the network level. Users first authenticate with the VPN server, or log on to the bastion host, before they can access any resource on the private network.
This works well when the resources are static and their number relatively small. However, as more and more resources dynamically spring up in different parts of the private network, the VPN / bastion host solutions become untenable.
Specifically, there are three areas where VPNs and bastion hosts fall short as an effective mechanism for access management.
In this article, we will define a new reference architecture for cloud-native companies that are looking for a simplified access management solution for their cloud resources, from SSH hosts, databases, data warehouses, to message pipelines and cloud storage endpoints.
It solves the following specific challenges VPNs and bastion hosts arent able to overcome:
Additionally, it enables the following business benefits for organizations with sensitive data:
The architecture is built upon the following three core principles, whose implementation allows DevOps and Security teams to exercise full control over all of their environment while improving user productivity with a simple and consistent experience.
The following figure shows the reference architecture and its components.
The VPN / bastion host from the previous figure has been replaced with anAccess Gateway. TheAccess Gatewayis actually a collection of micro-services and is responsible for authenticating individual users, authorizing their requests based on certain attributes, and ultimately granting them access to the infrastructure and data services in the private network.
Next, lets look at the individual components to see how the core principles outlined before are accomplished.
The key insight underpinning this architecture is the delegation of user authentication to a single service (theAccess Controller) rather than placing that responsibility with each service to which the user may need access. This kind of federation is commonplace in the world of SaaS applications. Having a single service be responsible for authentication simplifies user provisioning and de-provisioning for application owners and accelerates application development.
TheAccess Controlleritself will typically integrate with an identity provider, such asAuth0orOkta, for the actual authentication sequence, thus providing a useful abstraction across a wide array of providers and protocols. Ultimately, the identity provider guaranteesnon-repudiationof the users identity in the form of a signed SAML assertion, a JWT token, or an ephemeral certificate. This obviates the need to rely on a trusted subnet as a proxy for the users identity. It also allows configuring access policies down to the granularity of a service unlike VPNs which permissively grant users access to all services on the network.
An additional advantage of delegating authentication to identity providers is that users can be authenticated using zero trust principles. Specifically, identity provider policies can be created to enforce the following:
While theAccess Controllerenforces authentication for users, thePolicy Engineenforces fine-grained authorization on their requests. It accepts authorization rules in a human-friendly YAML syntax (check out examples at the end) and evaluates them on user requests and responses.
The Open Policy Agent (OPA), an open-source CNCF project, is a great example of a policy engine. It can be run as a microservice on its own or used as a library in the process space of other microservices. Policies in OPA are written in a language called Rego. Alternatively, its easy to build a simple YAML interface on top of Rego to simplify policy specifications.
Having an independent policy engine separate from the security models of the infrastructure and data services themselves is advantageous for the following reasons:
Both the Infrastructure Gateway and Data Gateway depend on the Policy Engine for evaluating infrastructure and data activity, respectively, by users.
TheInfrastructure Gatewaymanages and monitors accesses to infrastructure services such SSH servers and Kubernetes clusters. It interfaces with the Policy Engine to determine granular authorization rules and enforces them on all infrastructure activity during a user session. For load balancing purposes, the gateway may comprise a set of worker nodes, be deployed as an auto-scaling group on AWS, or run as a replica set on a Kubernetes cluster.
Hashicorp Boundaryis an example of an Infrastructure Gateway. Itsan open source project that enables developers, DevOps, and SREs to securely access infrastructure services (SSH servers, Kubernetes clusters) with fine-grained authorization without requiring direct network access while precluding the use of VPNs or bastion hosts.
The Infrastructure Gateway understands the various wire protocols used by SSH servers and Kubernetes clients, and provides the following key capabilities:
This involves making a copy of every command executed by the user during a session. The captured commands will typically be annotated with additional information, such as the identity of the user, the various identity provider groups they belong to, the time of the day, the duration of the command, along with a characterization of the response (whether it was successful, whether there was an error, whether data was read or written to, etc.).
Monitoring takes the notion of session recording to the next level. In addition to capturing all commands and responses, the Infrastructure Gateway applies security policies on the users activity. In the case of a violation, it may choose to trigger an alert, block the offending command and its response, or terminate the users session altogether.
TheData Gatewaymanages and monitors accesses to data services such hosted databases such as MySQL, PostgreSQL and MongoDB, DBaaS endpoints such as AWS RDS, data warehouses such as Snowflake and Bigquery, cloud storage such as AWS S3, and message pipelines such as Kafka and Kinesis. It interfaces with the Policy Engine to determine granular authorization rules and enforces them on all data activity during a user session.
Similar to the Infrastructure Gateway, the Data Gateway may comprise a set of worker nodes, be deployed as an auto-scaling group on AWS, or run as a replica set on a Kubernetes cluster.
Due to the wider variety of data services compared to infrastructure services, a Data Gateway will typically have support for a large number of wire protocols and grammars.
An example of such a Data Gateway isCyral,a lightweight interception service and is deployed as a sidecar for monitoring and governing access to modern data endpoints such as AWS RDS, Snowflake, Bigquery, AWS S3, Apache Kafka, etc. Its capabilities include:
This is similar to recording infrastructure activity and involves making a copy of every command executed by the user during a session and annotating with rich audit information.
Again, this is similar to monitoring infrastructure activity. For example, the policy below blocks data analysts from reading sensitive PII of customers.
Unlike infrastructure services, data services grants users read and write access to sensitive data related to customers, partners, and competitors that often resides in databases, data warehouses, cloud storage, and message pipelines. For privacy reasons, a very common requirement for aData Gatewayis the ability to scrub (also known as tokenization or masking) PII such as emails, names, social security numbers, credit card numbers, and addresses.
Lets look at some common access management scenarios to understand how the Access Gateway architecture provides fine-grained control compared to using VPNs and bastion hosts.
Heres a simple policy to monitor privileged activity across all infrastructure and data services in a single place:
The next policy shows an example of enforcing zero standing privileges -- a paradigm where no one has access to an infrastructure or data service by default. Access may be obtained only upon satisfying one or more qualifying criteria:
The last policy shows an example of data governance involving data scrubbing:
We saw that for highly dynamic cloud environments, VPNs and bastion hosts are inadequate as effective access management mechanisms in agile cloud environments. A new access management architecture with a focus on a non-repudiable user identity, short-lived certificates or tokens, and a centralized fine-grained authorization engine effectively solves the challenges that VPNs and bastion hosts fail to solve. In addition to providing a comprehensive security for users accessing critical infrastructure and data services, the architecture helps organizations achieve their audit, compliance, privacy and governance objectives.
We also discussed a reference implementation of the architecture using well-known developer focussed open-source solutions such as Hashicorp Boundary and OPA in conjunction with Cyral, a fast and stateless sidecar for modern data services. Together they can provide a fine-grained andeasy to use access management solution on the cloud.
Manav Mital is the co-founder and CEO of Cyral, the first cloud-native security service that delivers visibility, access control and protection for the Data Cloud. Founded in2018, Cyral works with organizations of all kindsfrom cloud-native startups to Fortune 500enterprises as they embrace DevOps culture and cloud technologies for managing and analyzing their data. Manav has a MS in Computer Science from UCLA and a BS in Computer Science from the Indian Institute of Technology, Kanpur.
View post:
A Reference Architecture for Fine-Grained Access Management on the Cloud - InfoQ.com
Read More..