Topic starter
06/11/2026 6:55 pm
TL;DR: IaC SSH authentication still relies on runner-held credentials in many deployments, according to Twingate's analysis of Ansible, Terraform, and similar tools. For practitioners, the issue is less about the tool and more about where authentication state lives, how it is rotated, and how much blast radius one key creates.
Editorial analysis by NHI Mgmt Group, based on content published by Twingate: “Ansible & Terraform SSH Auth Without Static Keys”.
Key questions
Q: Why do CI runners become a high-risk place for SSH access?
A: CI runners become high-risk because they often hold build secrets, SSH private keys, deploy tokens, and broad network reach for short-lived jobs.
Q: What is the difference between SSH keys and SSH certificates for governance?
A: SSH keys are reusable credentials that can persist indefinitely unless administrators remove them, while SSH certificates are time-bounded identities signed by a central authority.
Q: Why do SSH certificates reduce risk compared with passwords?
A: SSH certificates reduce risk because they remove reusable passwords, narrow access to specific identities, and support time-bound trust.
Practitioner guidance
- Replace runner-held SSH keys Move provisioning access away from static private keys stored on laptops, CI runners, or controller databases and into a model that does not duplicate the secret across execution environments.
- Inventory every automation credential copy Map every place Ansible and Terraform can read SSH material, including local files, injected secrets, and orchestration databases, then remove orphaned copies first.
- Adopt short-lived SSH certificates where keys must remain Use CA-issued certificates for workflows that still need SSH so the trust window is minutes, not months, and host access can be revoked without reissuing long-lived keys.
Bottom line: IaC does not remove SSH governance work when the automation path still depends on private keys.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:56 pm
SSH credentials used by IaC are a lifecycle problem, not a tooling detail. When the same key is copied into a laptop, a CI runner, and a controller database, ownership, rotation, and revocation stop being single actions and become an estate-wide hunt. That is why provisioning access so often outlives the person or pipeline that first needed it. Practitioners should treat automation credentials as governed identities, not convenience artifacts.
A question worth separating out:
Q: How should teams remove secrets from infrastructure automation?
A: Remove secrets by replacing embedded credentials with short-lived, centrally issued credentials or identity-based access. Use a vault, OIDC-backed federation, or cloud instance roles so the access model where the runner fetches secrets at runtime, rather than storing SSH keys, passwords, or API tokens in code, variables, or state files. Rotate any residual secrets and block plaintext output in logs.
👉 Read our full editorial: IaC SSH access creates credential debt when runners hold keys