RSAC 2024 Innovation Sandbox | Aembit: An IAM Platform for Cloud Workloads

RSAC 2024 Innovation Sandbox | Aembit: An IAM Platform for Cloud Workloads

maio 3, 2024 | NSFOCUS

The RSA Conference 2024 will kick off on May 6. Known as the “Oscars of Cybersecurity,” the RSAC Innovation Sandbox has become a benchmark for innovation in the cybersecurity industry.

Figure 1: Top 10 Finalists for the RSAC 2024 Innovation Sandbox Contest

Today let’s get to know the company Amebit.

Company Introduction

Aembit was established in 2021 and is headquartered in Washington, USA. The company is dedicated to cloud workload Identity and Access Management (IAM), with the aim of automating and securely controlling access between cloud workloads and cloud services to reduce the cost of manual management. Currently, the Aembit team consists of 10-50 people, with the two co-founders being David Goldschlag (CEO) and Kevin Sapp (CTO).

Figure 2: Co-founders of Aembit

David Goldschlag previously worked at the National Security Agency in the United States, where he invented onion routing technology. This encryption channel technology was initially used as a tool for U.S. intelligence and has since evolved into an online anonymous browser widely used by the general public to protect personal privacy.

David Goldschlag and Kevin Sapp both worked together at New Edge Labs, where they pioneered Zero Trust Network Access (ZTNA) and gained considerable recognition. Subsequently, New Edge Labs was acquired by Netskope, where Kevin Sapp served as Senior Director of Product Management, and David Goldschlag as VP. In 2021, they shifted their focus to the field of cloud workload IAM security and co-founded Aembit together.

It is worth noting that the establishment of Aembit originated from a conversation between David Goldschlag and Kevin Sapp with a customer. During the conversation, they discussed that traditional communication between workloads is often achieved through key connections, which can become extremely complex to manage as the number of workloads increases. Moreover, as businesses migrate to the cloud, scenarios where users’ cloud workloads communicate across on-premises, public, and hybrid clouds will become common, further driving the industry’s demand for IAM-focused cloud workloads.

In terms of financing, as of last November, Aembit has completed four rounds of financing, with the most recent round being a seed round on October 31, 2023. A total of $18 million has been raised, with Aembit’s main investors including CrowdStrike Falcon Fund, Ten Eleven Ventures, Ballistic Ventures, and Okta Ventures.


Traditional Cloud Workload Access Control Pose Risks

Figure 3: Traditional Cloud Workflow Access Control

Traditional communication between cloud services is usually implemented by embedding public and private key pairs or passwords within the cloud service. However, as the variety of cloud services increases, such as CI/CD systems, Kafka middleware, SaaS applications, and cloud-native services, the risk of control increases if users deploy a large number of service types. Typical issues include:

  • Developers may hardcode key and password information into code files, making key management difficult as the number of services increases, and the leakage of key information can lead to the risk of misuse.
  • There are various types of cloud services, such as Serverless services, SaaS services, APIs, and microservices, each with different access methods, which undoubtedly increases the attack surface of cloud services.
  • Existing solutions often involve using key managers like Vaults, Cloud IAM, SPIFFE, etc., but they have certain drawbacks:
    • Cloud IAM is only suitable for a single cloud environment and cannot solve the challenge of workload identity in multiple environments.
    • Key information cannot be associated with identity, which may lead to risks such as credential loss and identity deception.
    • Key management is more complex, with low automation, increasing the security risks of access between workloads.

For example, Service A and Service B are deployed on AWS and use AWS’s IAM for authentication and authorization. However, if they need to communicate with Service C deployed on Azure, users must resolve the discontinuity issues caused by different IAM mechanisms themselves.

Facing the control risks brought by traditional methods, the industry urgently needs a unified solution to manage access control between cloud services and maintain consistent policies.

IAM-Centric Cloud Workload Access Emerges

Figure 4: Aembit IAM Access Control

If we consider each cloud workload as an identity accessing another identity’s workload, we can abstract the underlying complex authentication and authorization mechanisms into a consistent IAM layer for management, thereby significantly reducing manual input costs. In fact, Aembit does just that. Aembit supports the configuration to connect a large number of cloud services (whether self-built or public cloud services). When cloud workloads communicate, the request is first proxied to Aembit, which realizes secure communication between services based on predefined policies, such as key generation methods and identity authentication. According to research, Aembit has the following advantages:

  • It manages authentication and authorization across multi-cloud environments uniformly for various cloud services.
  • It avoids implementing authentication and authorization code logic within cloud services, effectively decoupling business and security.
  • It provides deeper IAM visibility, mainly by visualizing IAM through Aembit’s log auditing features.

Product Introduction

Architecture Analysis

Figure 5: Aembit Architecture

Aembit’s architecture is inspired by the concept of SDN (Software-Defined Networking) and is simply divided into two core components: Edge (data plane) and Cloud (control plane). Edge is responsible for accessing the user’s cloud workloads, generating workload identities (Service Account), and proxying cloud service requests to the Cloud side for processing. Edge provides two access methods: Sidecar and SDK. There may be multiple Edge nodes in the data plane. Cloud is the control plane, mainly responsible for access policy configuration, access credential generation (short-lived certificates to avoid the security and management issues of long-lived certificates), client identity verification, event logging, 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. To better understand its architecture, you can refer to the official workflow diagram provided, as shown below:

Figure 6: Aembit Workflow

Scenario for Workload A accessing Service B:

  • Step 1: The client workload requests access to Service B.
  • Step 2: Aembit’s Edge component intercepts the client request via proxy.
  • Step 3:  Edge generates Token information for the Service Account (self-implemented, Token represents the identity of the Workload).
  • Step 4: Edge, on behalf of the client workload, requests access credentials for Service B.
  • Step 5: Cloud uses attestation to verify the authentication request from the client in step 4.
  • Step 6: Cloud detects the corresponding access requirements based on the preset authorization policies and conditions.
  • Step 7: Cloud requests access key information from the third-party Credential Provider (at this point, Cloud has obtained the access credentials for Workload A to access Service B).
  • Step 8: The client workload continues to request access to Service B.
  • Step 9: Edge embeds the access credentials obtained in step 7 into the client request and forwards it to Service B.
  • Step 10: Edge also sends the access event log of this time to Cloud.

Functional Analysis

Aembit’s product, Workload Identity & Access Management, can be briefly divided into three main parts: access policy configuration, access log auditing, and Edge component integration. On the product’s web interface, users can easily perform operations and management in these three areas, as shown in Figure 7:

Figure 7: Aembit Product Interface

>> Access Policy Configuration

Figure 8: Aembit Access Control Configuration

One of Aembit’s core functions is access policy configuration. As shown in Figure 8, configuring a policy involves five parts: Client Workloads, Trust Providers, Access Conditions, Credential Providers, and Server Workloads. With the introduction of the product’s process in the previous section, you may have a certain understanding of these parts. Here, we focus on the importance of Access Conditions.

Access conditions allow users to impose certain restrictions on the access behavior of cloud workloads. 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’s integration with Wiz, the access policy can be seen in Figure 9.

Figure 9: Configuration Page of Aembit’s Interation with Wiz

As shown in Figure 10, there are two key elements in the access conditions:

(1) Cluster Restriction: Only when the container cluster is connected to Wiz can the client workload continue to access.

(2) TIME Restriction: The most recent access time is set to 1 hour (since an access event log is generated every time the access policy is met. If we set the access time too long, it will cause an increase in the number of access event logs, so it can be dynamically adjusted according to user needs).

We believe that “Access Conditions” not only ensure the security and traceability of access but also take into account system performance and user experience.

Figure 10: Wiz Access Condition

>> Access Log Auditing

Aembit provides a detailed access log auditing function. From its user interface, it includes two parts: Workload Events and Audit Logs. Workload Events can display information such as the client, server, and event access type, such as specific cloud service requests or responses, as shown in Figure 11. Audit Logs record the access behavior between cloud workloads based on access policies, as shown in Figure 12.

Figure 11: Aembit Report Page

Figure 12: Aenbit Audit Log Page

>> Edge Component Integration

Aembit Edge has already integrated more than 100 types of cloud applications. It provides two deployment methods: Sidecar and SDK. Aembit claims that Edge can be installed via Helm without invading the application code, as shown in the following figures:

Figure 13:  Aembit Edge Deployment Script

Figure 14: YAML Configuration – Aembit Sidecar Injection  

Figure 15: Aembit Edge Access

Aembit claims that their Edge integration uses a “No-code auth technology (proxy design),” and based on the official video introduction, we believe that Aembit is likely to have drawn on the implementation of the Envoy proxy. Envoy supports mainstream L3/L4 layer protocols as well as proprietary protocols, has strong scalability, and is relatively developer-friendly. Considering that the communication protocols between cloud workloads may vary in different scenarios, this reference is reasonable.

From a technical perspective, I believe that “invasiveness” exists to varying degrees, and “non-invasive” is non-existent. Even when using a Sidecar to intercept request traffic, it is necessary to configure certain permissions in the Pod YAML. Therefore, regardless of the degree of invasiveness, it will affect the system’s configuration and deployment to some extent.

Competitor Analysis

The Top 10 Finalists for the RSAC 2024 Innovation Sandbox Contest includes another company engaged in IAM security, named P0 Security. They provide a cloud access governance platform, mainly to ensure the cloud access security of all identities within the organization (including humans and machines) without affecting the workflow of developers. In addition, P0 Security can also manage the inventory of all IAM identities, assess their risk status, and manage their access lifecycle.

Compared with Aembit, P0 Security has a different focus in the field of IAM security. P0 Security is more like a cloud service IAM access adapter, using the best practices of public cloud manufacturers to configure IAM to meet compliance requirements. 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, Aembit’s “access policy” can meet user needs well. In contrast, P0 Security seems only to use existing IAM policies for risk compliance, while Aembit appears to be more scalable.


This year’s RSAC Sandbox competition is particularly fierce in the field of cloud security, with four companies participating. Among them, Aembit and P0 Security focus on IAM solutions; RAD Security is involved in the field of cloud-native security; and Mitiga continues to focus on SaaS security.

This article mainly introduces Aembit’s architecture, functions, and technology. Overall, among the two companies offering IAM security, Aembit stands out more in terms of innovation than P0 Security. We look forward to Aembit achieving good results in the final competition.

More RSAC 2024 Innovation Sandbox Finalist Introduction: