Cert-based MFA Service Accounts
You set up cert based mfa service accounts by pairing a private key with an identity policy. The system checks both the signed cert and network rules before the bot logs in. Teams often use this flow to stop password leaks in automated scripts. Still, teams often grant these accounts broad roles so jobs do not fail. If an attacker steals that key, the bot can read or change anything. How cert based mfa service accounts work Human users can tap a phone prompt to prove who they are. Automated j
cert-manager for Kubernetes: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cert based mfa service accounts by pairing a private key with an identity policy. The system checks both the signed cert and network rules before the bot logs in. Teams often use this flow to stop password leaks in automated scripts. Still, teams often grant these accounts broad roles so jobs do not fail. If an attacker steals that key, the bot can read or change anything.
How cert based mfa service accounts work
Human users can tap a phone prompt to prove who they are. Automated jobs and backend apps cannot tap a phone screen during a run. To fix this, teams use digital certs as a strong login factor. First, your internal authority signs a cert for the specific service account. The admin then stores the matching private key on the host machine. Next, the admin links the public trust chain to the identity tool.
To finish the multi-factor setup, the team adds a second check. This second check is often a strict source IP rule or device check. Some teams also require a hardware chip on the server to hold the key. When the script runs, it sends the signed cert to the login server. The server checks the cert math, the expiry date, and the host IP. If both checks pass, the server gives the app a session token.
Managing key rotation and revocation
Static keys and long-lived certs create work for your platform team. If a cert lasts for a year, someone has to track that date. When a cert expires over the weekend, production jobs stop right away. Teams must build automated jobs to swap out certs before they die.
You also need a clear plan to block stolen certs fast. Standard trust lists can take hours to update across every database and host. During that window, a leaked key can still start new sessions. Keeping cert lifetimes very short helps shrink this risk window for your team.
cert-manager for Kubernetes: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native cert checks solve and what they miss
Using certs and IP rules stops attackers from guessing weak bot passwords. It ensures that only known hosts with valid keys can start a session. This setup solves the initial login problem for your automated apps.
Still, login checks only decide who gets through the front door. Once the service account logs in, the identity tool steps out of the way. The database or server trusts every command inside that open session. It cannot tell a normal daily backup from a sudden table drop. It also does not rewrite sensitive fields like emails or card numbers in results. If a script has a bug, the broad role lets it break production data. Native certs prove identity at the start, but they do not watch active commands.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can a service account use a normal phone prompt for MFA?
No, because automated scripts run on servers without a human at a screen. They need machine checks like digital certs, hardware keys, or strict IP rules.
What counts as the second factor for a bot account?
The first factor is usually a client cert stored on the host. The second factor is often a hardware module check, a workload token, or a network rule.
Do client certs stop a compromised script from reading private data?
No, a cert only proves identity when the script first logs in. After login, the script can read any table allowed by its database role.