[ferngodfather]

But then you just move the security issue elsewhere with more to secure. Now we have to think about securing the automation system, too.

This is the same argument I routinely have with client id/secret and username/password for SMTP. We're not really solving any major problem here, we're just pretending it's more secure because we're calling it a secret instead of a password.

[Flimm]

Secrets tend to be randomly-generated tokens, chosen by the server, whereas passwords tend to be chosen by humans, easier to guess, and reused across different services and vendors.

[collabs]

How does this apply to ssh public keys?

[akerl_]

> Long-lived production SSH keys may be copied around, hardcoded into configuration files, and potentially forgotten about until there is an incident. If you replace long-lived SSH keys with a pattern like EC2 instance connect, SSH keys become temporary credentials that require a recent authentication and authorization check.

[orf]

It’s like 12 lines of terraform to fully automate this, inside your existing IaC infrastructure. It’s not complex.

[KetoManx64]

Seems like you work in an organization with one developer. It's never just a "small configuration change" when you need to change the workflow and habits of your entire company.

[orf]

I work for a gigantic tech company, and it’s still just a small configuration change.

What’s your excuse?