Skip to main content

SSM Access via Apono

One of the most common reasons for adopting Apono is solving the problem of direct machine access on AWS. In most organizations, engineers need to access EC2 instances for troubleshooting, manual deployments, or incident investigation, and the traditional model of standing permissions creates significant security risks.

Before understanding how Apono automates this access, it's important to understand how AWS Systems Manager Session Manager (SSM) works, the native AWS service that replaces bastion hosts and SSH keys. If you're not yet familiar with SSM, first read the article on AWS Systems Manager — Session Manager.

The Problem with Standing Permissions​

With SSM configured in the infrastructure, access control to instances is managed through IAM permissions. Users need the ssm:StartSession policy to start sessions on specific instances.

The problem is how this permission is granted in practice:

  1. An engineer requests access to an EC2 instance.
  2. An administrator manually adds the ssm:StartSession policy to the user or IAM group.
  3. The engineer uses the access.
  4. No one remembers to remove the permission.

Access that should have been temporary becomes permanent. Over time, each engineer accumulates permissions on dozens of instances they no longer need to access, expanding the attack surface and violating the principle of least privilege.

How Apono Solves This​

Apono manages the IAM permissions that control who can start SSM sessions and on which instances. It doesn't replace SSM — the infrastructure (Agent, Instance Profile, VPC Endpoints) continues working normally. What changes is that the user's permission to start sessions becomes temporary and audited.

The flow with Apono:

The Apono connector manages this by adding and removing inline or managed IAM policies on the user/group/role. When the time expires, the policy is automatically removed — the engineer immediately loses the ability to start new SSM sessions.

What Changes in Practice​

With Apono managing SSM access, the permission lifecycle becomes:

  • Explicit request: The engineer must request access (via portal, Slack, or CLI), specifying which instance and why.
  • Policy-based approval: The request is automatically approved (if the policy allows it) or forwarded to a human approver.
  • Granular scope: The granted policy is for specific instances, not for "all EC2 instances".
  • Defined duration: Access has a time limit (e.g., 2 hours) and is automatically revoked when it expires.
  • Full audit trail: Who requested, when, for which instance, who approved, when it expired — everything is recorded.

The SSM infrastructure (Agent installed, Instance Profile configured, VPC Endpoints active) must be working before Apono comes in. Apono doesn't configure SSM — it only controls who has permission to use it and for how long.