RSAC 2024 Innovation Sandbox | Aembit: Cloud workload access control platform for IAM

May 6th

RSA Conference 2024

will officially open

As the “Oscar of Safety”

RSAC Innovation Sandbox (Innovation Sandbox）

Has become an innovation benchmark in the network security industry

under innovation

Together with Mr. Green Alliance

Focus on new hot spots in network security

Insight into new trends in security developmentAembit

Company Profile

Aembit was founded in 2021 and is headquartered in Washington, USA. The company is committed to the field of cloud workload IAM (Identity Identification and Access Management), aiming to realize automated, secure and controllable access between cloud workloads and cloud services to reduce human management cost. At present, the Aembit team size is about 10-50 people, and the two co-founders are David Goldschlag (CEO) and Kevin Sapp (CTO).

David Goldschlag served at the National Security Agency, where he invented onion routing, an encrypted channel technology that was originally used as a U.S. intelligence tool and has now evolved into an online anonymous browser used by the general public. Used to protect personal privacy. David Goldschlag and Kevin Sapp worked together at New Edge Labs, where they co-created ZTNA (Zero Trust Network Access) and became famous. Subsequently, New Edge Labs was acquired by Netskope, where Kevin Sapp served as senior director of product management and David Goldschlag served as VP. In 2021, they turned their attention to the field of cloud workload IAM security and co-founded Aembit.

It is worth noting that the creation of Aembit originated from a communication between David Goldschlag and Kevin Sapp and a customer. During the exchange, it was mentioned that traditional communication between workloads is usually implemented through key connection. This method will cause key management to become extremely complicated once the workload increases. And as businesses migrate to the cloud, it will become common for users' cloud workloads to communicate across local, public cloud, and hybrid clouds, which has further increased the industry's demand for IAM-oriented cloud workloads.

In terms of financing, as of November last year, Aembit had completed 4 rounds of financing, with the latest round of seed financing on October 31, 2023. A total of $18 million has been raised, with Aembit’s major investors including CrowdStrike Falcon Fund, Ten Eleven Ventures, Ballistic Ventures and Okta Ventures.

background

​Traditional access methods between cloud workloads have management and control risks

Communication between traditional cloud services is usually achieved by implanting a public-private key pair or password within the cloud service. However, with the diversification of cloud service types, such as CI/CD systems, Kafka middleware, SaaS applications, and cloud native services, if users deploy more types of services, management and control risks may increase. Typical questions include:

Developers may hard-code keys and password information in code files. As the number of services increases, key information management becomes difficult, and leaking key information may lead to abuse risks.

There are many types of cloud services, such as Serverless services, SaaS services, APIs and microservices. Different cloud services have different access methods, which will undoubtedly increase the attack surface of cloud services.

Most existing solutions use key managers Vaults, Cloud IAM, SPIFFE, etc. for management, but there are certain flaws:

1) Cloud IAM is only applicable to a single cloud environment and cannot solve the problem of workload identity challenges in multiple environments.

2) Key information cannot be associated with identity, and there may be risks such as credential loss and identity spoofing.

3) Key management is more complex and less automated, and the security risk of access between workloads becomes higher.

For example, service A and service B are deployed on AWS, and authentication and authorization are implemented through AWS's IAM. However, if they communicate with service C deployed on Azure, users need to solve the disconnection problem caused by different IAM mechanisms. Facing the management and control risks brought by traditional methods, the industry urgently needs a solution that can uniformly manage access control between cloud services and maintain policy consistency.

​IAM-oriented access between cloud workloads emerges as the times require

If we regard each cloud workload as an identity accessing the workload of another identity, we can abstract the underlying complex authentication and authorization mechanism upwards to form a consistent IAM layer for management, thereby greatly reducing labor investment costs. In fact, Aembit does this. Aembit supports configuration to connect to a large number of cloud services (whether self-built or public cloud services). When communicating between cloud workloads, requests will first be proxied to Aembit. According to pre-configured policies, such as key generation methods, identity authentication, etc., Aembit implements secure communication between services. According to the author's research, Aembit has the following advantages:

Through policy management across multi-cloud environments, authentication and authorization between various cloud services are managed uniformly.

Avoid implementing code logic such as authentication and authorization inside cloud services, and effectively decouple business and security.

Provide deeper IAM visibility, mainly through Aembit's log audit function to visually present IAM.

​Product introduction

Architecture analysis

Aembit's architecture draws on the concept of SDN and is simply divided into two core components: Edge (data plane) and Cloud (control plane). Edge is responsible for accessing the user's cloud workload, generating a workload identity (Service Account), and proxying request traffic between cloud services to the Cloud side for processing. Edge provides two access methods: Sidecar and SDK. The data plane may have multiple Edge nodes. Cloud is the control plane and is mainly responsible for access policy configuration, access credential generation (short life cycle certificates to avoid security and management issues caused by long life cycles), client authentication, event logs and other functions. In addition, Cloud also receives a type of request from Edge, including workload status, access event logs, etc., and manages Edge nodes. In order to understand its architecture more clearly, you can refer to the official workflow diagram, as shown below:

The above is the workflow of Aembit. The case scenario is Workload A accessing Service B in Figure 5:

Client workload requests access to Service B

Aembit's Egde component intercepts client requests through a proxy

Edge generates Token information of Service Account (self-implemented, Token represents the identity of Workload)

Egde requests credential information to access Service B on behalf of the client workload.

Cloud uses attestation to verify authentication requests from clients in 4

Cloud performs corresponding detection through pre-set authorization policies and conditional access requirements.

Cloud requests the access key information from the third-party credential provider (at this step, Cloud has obtained the access credential for Workload A to access Service B)

Client workload continues to request access to Service B

Edge embeds the access credentials obtained in 7 into the client request and forwards it to Service B

Edge also sends this access event log to Cloud

​Functional analysis

Aembit's product is called Workload Identity & Access Management. After the author's research, I found that its main functions can be briefly divided into three parts: access policy configuration, access log auditing, and Edge component access. On the product's Web interface, users can easily operate and manage these three aspects, as shown in Figure 6:

1) Access policy configuration

One of Aembit's core functions is access policy configuration. As can be seen from Figure 7, configuring a policy involves five parts: client workloads (Client Workloads), client authentication providers (Trust Providers), and access conditions. (Access Conditions), Credential Providers (Credential Providers), Server Workloads (Server Workloads). Through the process introduction part of the aforementioned products, readers should have a certain understanding of these parts. Here, the author would like to further explain the importance of access conditions (Access Conditions). In fact, access conditions allow users to restrict the access behavior of cloud workloads to certain conditions. For example, we can pass the information contained in an access record to a third-party application for processing and set certain conditions. In the case of Aembit integrating Wiz (2), you can see its access policy as shown in Figure 8.

In the access conditions shown in Figure 9, two key elements can be seen:

Cluster restrictions

Only when the opened container cluster is connected to Wiz can the client workload continue to access it.

TIME constraints

Set the latest access time to 1 hour (because whenever the access policy is met, the system will generate an access event log. If we set the access time too long, it will cause the number of access event logs to surge, so it can be based on the user needs to be dynamically adjusted).

The author believes that “access conditions” not only ensure the security and traceability of access, but also take into account system performance and user experience.

The author believes that the access policy configuration is quite innovative. Aembit focuses on the user's demand for freedom in access policies, which reflects the ease of use and flexibility of its products. The author believes that Aembit should probably go a step further and have more ideas, such as providing external SDK or API to users to enhance the scalability of the product. Somewhat similar to the transparent proxy Envoy in the cloud native field, its main feature is strong scalability. In this way, users can customize access conditions according to their own needs, making the product more applicable and scalable.

2)Access log audit

Aembit provides a more detailed access log audit function. Judging from the user interface it provides, it includes two parts: Workload Events and Audit Logs. In Workload Events, you can view the client, server, event access type, such as request or response for a specific cloud service, as shown in Figure 10, and Audit Logs records the access behavior between cloud workloads according to the access policy, as shown in Figure 11 shown.

3)Edge component access

Aembit Edge has currently integrated more than 100 various cloud applications (1), and provides two methods of deployment: Sidecar and SDK. Aembit claims that Edge can be installed through helm without invading the application code, as shown in the following figure:

Aembit claims that their Edge access adopts “No-code auth technology (proxy design)”. Based on the introduction of the official video, the author believes that Aembit is likely to learn from the implementation of the Envoy proxy. Envoy supports mainstream L3/L4 layer protocols and private protocols, has strong scalability, and is relatively developer-friendly. This reference is reasonable considering that communication protocols between cloud workloads may be different and similar in different scenarios.

From a technical perspective, the author believes that “invasiveness” exists to varying degrees, while “non-invasiveness” does not exist. Even if sidecar is used to intercept request traffic, certain permissions need to be configured in Pod YAML. Therefore, no matter how intrusive it is, it will affect the configuration and deployment of the system to some extent.

Competitive product analysis

There is also a company engaged in IAM security among the top ten of the RSAC Innovation Sandbox this year, called P0 Security. What they provide is a cloud access governance platform that focuses on ensuring secure cloud access for all identities within the organization, including people and machines, without impacting developer workflows. In addition, P0 Security can inventory manage all IAM identities, assess their risk status, and manage their access life cycle.

Compared with Aembit, P0 Security has a different entry point in IAM security. P0 Security is more like a cloud service IAM authorization accessor that configures IAM to meet compliance requirements by adopting the best practices of public cloud vendors. Aembit's IAM security is more extensive, covering not only public cloud application scenarios, but also a combination of hybrid cloud, local cloud and other scenarios. From an innovative perspective, the “access policy” provided by Aembit can well meet user needs. In comparison, P0 Security appears to simply leverage existing IAM policies for risk compliance, while Aembit appears to be more scalable.

Summary

This year's RSAC Sandbox competition is particularly fierce in the field of cloud security, with a total of four vendors participating. Among them, Aembit and P0 Security focus on IAM solutions; RAD Security involves the field of cloud native security; Mitaga continues to focus on SaaS security. This article focuses on the architecture, functionality and technical aspects of Aembit. Overall, among the two IAM security vendors, Aembit is more innovative than P0 Security. I look forward to Aembit achieving good results in the final competition.

references

(1) https://aembit.io/

(2) https://aembit.io/wiz/