Skip to main content

Apono Architecture

Overview​

Apono follows a SaaS architecture with lightweight agents (connectors) deployed in the customer's infrastructure. The control plane runs in Apono's cloud, while the connectors bridge the gap between Apono and your infrastructure resources.

Main Components​

Apono Cloud (Control Plane)​

The control plane is the heart of Apono and runs entirely on Apono-managed infrastructure (SaaS). It is responsible for:

  • Access Engine: Decision engine that evaluates access requests against defined policies (Access Flows). Decides whether access should be automatically approved, forwarded for manual approval, or denied.
  • Access Flows (Policies): Rules that define who can request what, with which access level, for how long, and who approves. They are configured by the security team through the dashboard.
  • Audit Log: Immutable record of all access requests, approvals, grants, and revocations. It is the basis for compliance reports.
  • Dashboard: Web interface for policy configuration, active access viewing, audit reports, and connector management.

Apono Connector (Agent)​

The connector is a lightweight component deployed within the customer's infrastructure — typically as a container in Kubernetes, an EC2 instance, or a VM. It is the communication point between Apono's control plane and the infrastructure resources.

Important connector characteristics:

  • Outbound communication: The connector initiates communication with Apono Cloud (outbound), never the other way around. This means no inbound firewall ports need to be opened or internal resources exposed to the internet.
  • No credential storage in Apono: The connector uses local credentials (IAM roles, service accounts, managed identities) to interact with resources. Credentials never leave the customer's infrastructure.
  • Lightweight and stateless: The connector does not store state locally. All decision logic and auditing remain in the control plane.
  • High availability: Multiple connectors can be deployed for redundancy.

Identity Provider Integrations​

Apono integrates with identity providers for authentication and to understand the organizational structure (who belongs to which team, who is each person's manager):

  • Okta, Azure AD (Entra ID), Google Workspace: Synchronizes users, groups, and hierarchies.
  • SAML / OIDC: Support for standard authentication SSO protocols.
  • SCIM: Automatic user provisioning — when someone is added or removed from the Identity Provider, Apono automatically reflects the change.

This integration is fundamental for Access Flows to work correctly because Apono needs to know who belongs to which group and who is whose manager — information that comes directly from the Identity Provider.

In practice, each Access Flow defines not only who can request and which resource, but also who the approvers are. This is configurable by team and by resource. Some examples:

  • The backend-team requests access to the production database → tech lead approval.
  • The infra-team requests access to an EC2 instance via SSM → automatic approval (no manual approval, as it's low-risk access for this team).
  • Anyone requests admin access to the production Kubernetes cluster → direct manager approval + security team.
  • Emergency access (break-glass) → automatic approval with enhanced auditing.

Approvers can be defined in different ways:

  • Direct manager: Apono queries the Identity Provider hierarchy to automatically identify the requester's manager.
  • Specific people: You define a fixed list of approvers (e.g., "Maria and João approve production database access").
  • Resource owners: The resource owner receives the notification and decides.
  • Automatic approval: For low-risk access, approval is granted automatically without human intervention.

This flexibility allows each team to have its own approval flow, tailored to the risk level and organizational structure.

The Problem with Automatic Leader Approval​

In practice, there is a real risk when approval depends exclusively on team leaders: they tend to approve everything. The leader knows their team, trusts their engineers, and wants to unblock work as quickly as possible. The result is that approval becomes a formality — the leader clicks "approve" without questioning the reason or assessing the risk.

This is especially problematic for sensitive access like production, critical databases, or administrative permissions. A leader who approves everything defeats the purpose of the approval flow.

For organizations that have a security team focused on IAM, the ideal is for this team to participate in the approval flow as a mandatory layer. Apono allows configuring multi-level approvals, where all levels need to approve for access to be granted:

  • Level 1 — Team leader: Validates that the request makes sense from a technical and business perspective.
  • Level 2 — Security team (IAM): Assesses the risk, verifies whether the requested access level is appropriate, and whether the justification is valid.

This way, even if the leader approves without questioning, the security team acts as a control gate that ensures governance. Some examples of how to configure this:

  • Read-only access to dev/staging environments → leader approval only (low risk).
  • Read-only access to production → leader approval + security team notification.
  • Write/admin access to production → leader approval + mandatory security team approval.
  • Access to databases with sensitive data (PII/financial) → leader approval + security team approval + mandatory justification.

The goal is not to bureaucratize the process, but to ensure that high-risk access goes through those who truly understand the impact. Low-risk access can continue flowing quickly, while sensitive ones receive the attention they deserve.

Security Model​

Apono's architecture was designed with a focus on security:

  • Zero trust: The connector has no direct access to the control plane beyond what is necessary. Communication is encrypted (TLS) and authenticated.
  • Credentials never leave the customer: Apono Cloud never receives or stores credentials for accessing resources. All interaction with AWS, Azure, GCP, and databases is done by the connector using local credentials.
  • Segregation of responsibilities: The control plane decides who can access what. The connector executes the action on the infrastructure. No single component has full power.
  • Immutable audit trail: All events are recorded immutably in the control plane, ensuring complete traceability even if the connector is compromised.