Hacker News Reader

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.

View on HN

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.

How does this apply to ssh public keys?

> 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.

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

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.

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

What’s your excuse?

Reply on news.ycombinator.com