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.
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.
> 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.
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.
Why? If Sentry gets compromised, it's the exact same outcome—your Jira tickets get mined for production credentials and downloaded for random. What does automated token management save here?
How long the Jira access lasts depends on you / Sentry detecting and solving the initial intrusion. It doesn't matter how long the Jira token itself lasts if the attackers have access to the database in which its stored or log files in which its been dumped or something like that.
This assumes that the intrusion is persistent until Sentry catches it, that Sentry notifies me, that I successfully track all the places I have long-lived tokens that need to be rotated, etc.
