Database Access via Apono

Another fundamental scenario for Apono is access to databases. Engineers need to access production databases for troubleshooting, data analysis, migrations, and incident investigation and, just like with SSM, the traditional model of standing permissions creates significant security risks.

Before understanding how Apono manages this access, it's important to know the two authentication models that exist in Amazon RDS. If you're not yet familiar with the difference between IAM authentication and native users, first read the article on RDS Database Authentication.

The Problem with Standing Database Access

In most organizations, database access suffers from the same problems as EC2 instance access:

• Shared credentials: Multiple engineers use the same generic user (e.g., dev_team) to access the production database.
• Passwords that never expire: Once the database user is created, the password is rarely rotated.
• Excessive permissions: The shared user has access to all tables, even when the engineer only needs to query one.
• Impossible auditing: When everyone uses the same user, there's no way to know who ran which query.

How Apono Solves This

Apono supports both RDS authentication models and adapts to what already exists in your infrastructure.

Scenario 1: IAM Auth on RDS

When the database uses IAM authentication, Apono manages access the same way it manages SSM — by controlling IAM policies:

1. The engineer requests access to the database.
2. After approval, the Apono connector adds the rds-db:connect policy to the IAM user, with the specific ARN of the database and database user.
3. The engineer generates the IAM token and connects.
4. When the time expires, the connector removes the policy and the user can no longer generate valid tokens.

In this scenario, the connector does not interact with the database. It operates exclusively at the AWS IAM layer, using the permissions from its own role (configured during deploy) to add and remove inline policies on the engineer's user/role. The engineer generates the IAM token on their own (aws rds generate-db-auth-token) and connects directly to the database.

Scenario 2: Native Database User

For databases that use native authentication (password), including those that do not support IAM Auth (SQL Server, Oracle, MariaDB), Apono works differently. It manages credentials directly inside the database:

1. The engineer requests access to the database.
2. After approval, the Apono connector connects to the database using administrative credentials (e.g., RDS master user) and creates a temporary user with the permissions defined in the Access Flow.
3. Apono delivers the temporary credentials to the engineer.
4. When the time expires, the connector connects to the database again and completely removes the access.

In this scenario, the connector interacts directly with the database. It executes SQL commands to manage the temporary user's lifecycle:

-- On access granting, the connector automatically executes:
CREATE USER temp_john_a1b2c3 WITH PASSWORD 'auto-generated-password';
GRANT SELECT ON schema_app.customers_table TO temp_john_a1b2c3;
GRANT SELECT ON schema_app.orders_table TO temp_john_a1b2c3;

-- On revocation (when the timer expires):
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA schema_app FROM temp_john_a1b2c3;
DROP USER temp_john_a1b2c3;

For the connector to create and remove users in the database, it needs administrative credentials for the database — typically a master user or a user with CREATE USER and GRANT permissions. These credentials are configured once in the Apono integration with the database and are stored on the connector — they are never sent to the Apono Cloud.

Scenario Comparison

Aspect	IAM Auth	Native User
What Apono manages	User's IAM policy	User/credential inside the database
Type of credential delivered	None (user generates IAM token)	Temporary username and password
Supported databases	PostgreSQL and MySQL (RDS/Aurora)	Any database supported by Apono
Revocation	Removes IAM policy	DROP USER on the database
Connector requirement	IAM permissions	Database admin credentials

What Changes in Practice

Regardless of the authentication model, the result is the same:

• Each engineer has their own credentials — no more shared passwords.
• Granular permissions — the Access Flow defines exactly which tables and operations (SELECT, INSERT, etc.) the engineer can access.
• Defined duration — access expires automatically, without depending on manual action.
• Individual auditing — Apono records who requested, for which database, with which permissions, and for how long. Combined with database logs, it's possible to trace each query back to the engineer who executed it.

Apono doesn't reinvent the wheel — it automates the lifecycle of credentials that already exist. For IAM Auth, it manages IAM policies. For native authentication, it creates and removes users directly in the database. In both cases, the result is the same: temporary, granular, approved, and audited access.

Connector and Connectivity

The connector is the component that executes the actions described in the scenarios above. To understand its complete architecture (how it's deployed, how it communicates with the Apono Cloud, and how the security model works), see the articles on architecture and deploy.

It's the same connector that manages both IAM access (as we saw in the SSM article) and direct database access. There are no separate connectors for AWS and databases. A single agent, deployed once in the infrastructure, executes different types of actions depending on the integration configured in the Apono Cloud:

• AWS Integration: the connector uses the IAM permissions from its own role to manipulate IAM policies (add/remove ssm:StartSession, rds-db:connect, etc.).
• Database Integration: the same connector uses administrative database credentials (configured in the integration) to execute CREATE USER, GRANT, DROP USER directly on the database.

The difference isn't in the connector itself, but in the integration. Each integration tells the connector how to interact with that type of resource, which credentials to use, and which actions to execute.

Connector Network Requirements

This distinction between integrations has direct implications for networking. The connector needs connectivity to two different destinations:

1. Apono Cloud (outbound HTTPS) — for polling pending actions and reporting status. This requires internet access (via NAT Gateway) or VPC Endpoints for the necessary services.
2. The managed databases — only for database integrations with native authentication. The connector needs to reach the database on its connection port (e.g., 5432 for PostgreSQL, 3306 for MySQL).

For the AWS integration (IAM Auth), the connector only needs to reach the AWS APIs (IAM, STS). It doesn't need a network route to the database because it doesn't interact with it directly.

For the database integration (native user), the connector must be in a network that can reach the database. If the connector is in one VPC and the database in another, VPC Peering, Transit Gateway, or deploying the connector in the same VPC as the database is required. Without this connectivity, the connector cannot execute the SQL commands for user creation and removal.

In practice, the connector's network placement is an important architectural decision. In organizations with multiple VPCs and AWS accounts, it's common to deploy the connector in a VPC with broad connectivity (via Transit Gateway, for example) or in the same VPC as the databases it needs to manage.

If the existing connector cannot reach a specific database, it's possible to deploy a second connector in another VPC or account. Apono supports multiple connectors simultaneously, and each integration is associated with a specific connector. For example, an organization might have one connector in the management account (for AWS/IAM integrations) and another in the production account (for database integrations requiring direct access). Each connector operates independently, polling the Apono Cloud and executing only the actions for the integrations linked to it.

The Connector Is Not a Proxy

It's important to understand that the connector is not a connection proxy. It doesn't mediate traffic between the engineer and the database. Its only function is to manage credentials: add IAM policies, create database users, grant permissions, and revoke access.

The engineer's connectivity to the database is a completely separate responsibility that Apono doesn't solve. If the database is in a private subnet without external access, the engineer needs a network route to it through other means — such as VPN, Direct Connect, bastion host, or SSM port forwarding. Apono ensures the engineer will have valid credentials when they reach the database, but how they get there is a networking problem that needs to be solved independently.

There are two distinct connectivity problems: the connector needs to reach the database to manage users, and the engineer needs to reach the database to use it. Apono solves the first but not the second.

The connector is stateless and does periodic polling to the Apono Cloud to check for pending actions (grants or revocations). All decision logic (who can access what, for how long, with what approval) resides in the Apono control plane. The connector simply executes what it receives.