IAM Roles vs Vault Dynamic Secrets for Binlog Access #

A binlog archiver holds two kinds of sensitive access — object-storage write credentials and a MySQL account that can read replication metadata — and baking either as a static, long-lived key into config is the credential leak waiting to happen. Two patterns deliver short-lived credentials instead: cloud IAM instance roles, where the platform injects rotating credentials scoped to a role, and HashiCorp Vault dynamic secrets, where Vault generates a credential on demand with a lease and revokes it on expiry. They solve the same problem differently, and the right choice depends on whether your access is single-cloud or spans databases and clouds, how fast you need revocation, and what your audit regime requires. This page compares them on the axes that matter for binlog access: rotation, revocation, blast radius, audit trail, and portability.

Context & Prerequisites #

This decision refines the credential-scoping model in Security & Access Frameworks for Binary Log Archiving and PITR Automation; read that for the least-privilege grants both patterns deliver. You need MySQL 8.0.22+, Python 3.10+, and either a cloud IAM provider (instance roles / workload identity) or a Vault deployment with the database and cloud secret engines. Both feed the archiving daemon in Automated Binlog Archiving to Object Storage and the recovery orchestrator in Point-in-Time Recovery Workflow Automation.

Step-by-Step Implementation #

1. IAM instance role: consume injected credentials #

The platform supplies rotating credentials to the instance; the SDK picks them up with no key in config.

# Python 3.10+  — boto3 resolves the instance role automatically; no static key
import boto3
s3 = boto3.client("s3")     # credentials from the instance metadata service, auto-rotated

PITR relevance: no static object-storage key ever exists on disk, so a compromised archiver host cannot leak a durable credential that would let an attacker rewrite or delete the archive.

2. Vault dynamic secret: request a leased MySQL credential #

Vault generates a unique, short-lived MySQL user on request and revokes it when the lease ends.

# Python 3.10+  — fetch a leased DB credential from Vault
import hvac

def db_creds(vault: hvac.Client, role: str) -> tuple[str, str, int]:
    resp = vault.secrets.database.generate_credentials(name=role)
    lease = resp["lease_duration"]
    return resp["data"]["username"], resp["data"]["password"], lease

PITR relevance: a per-run MySQL credential that expires on its lease means the replication-metadata account cannot be exfiltrated and reused later — the credential is dead before an attacker could pivot with it.

3. Renew or re-fetch before the lease expires #

Both patterns require the daemon to refresh before expiry; a long-running archiver renews rather than reconnecting with a dead credential.

# Python 3.10+
import time

def needs_refresh(issued_epoch: float, lease_s: int, skew: float = 0.7) -> bool:
    return time.time() > issued_epoch + lease_s * skew    # refresh at 70% of lease

PITR relevance: refreshing at a fraction of the lease avoids an archiver stalling mid-cycle on an expired credential, which would widen archiving lag and RPO.

4. Fail closed on a static credential #

The daemon should refuse to start if it detects a long-lived static key in its environment, forcing the short-lived path.

PITR relevance: fail-closed startup guarantees the archive is only ever written by an identity whose credentials rotate, closing the most common leak vector for a system that persists transaction history.

Configuration Snippet & Reference Table #

Verification Checklist #

• No static, long-lived credential exists in the archiver’s config or environment.
• The daemon fails closed if a static key is detected.
• Credentials are refreshed before expiry (renew at a fraction of the lease).
• Object-storage access is scoped write/verify-only; DB access is REPLICATION CLIENT only.
• Revocation is tested: pulling the role/lease immediately denies access.
• Every credential issuance and use is captured in the audit trail (CloudTrail / Vault audit).

Gotchas & Version-Specific Caveats #

IAM role scope creep. An instance role reused across services accumulates permissions; give the archiver its own tightly-scoped role, not a shared one, so its blast radius stays minimal.

Vault lease renewal storms. Many daemons renewing on the same schedule can hammer Vault; stagger renewals with jitter, the same discipline as fleet upload jitter.

Metadata service exposure. The instance metadata endpoint that serves IAM credentials must be protected (IMDSv2 / hop-limit) or an SSRF bug can steal the role’s credentials.

Dynamic DB users and connection pools. A pooled connection outlives a short lease; ensure the pool re-establishes connections with refreshed credentials rather than holding a connection authenticated by an expired user.

Frequently Asked Questions #

Related #

• Security & Access Frameworks — the least-privilege grants both patterns deliver.
• Securing Binlog Access with MySQL 8.0 Dynamic Privileges — scoping the MySQL side of the credential.
• Implementing AES-256 Encryption for Archived MySQL Binary Logs — the KMS keys these credentials also gate.

Back to Security & Access Frameworks.