61–65 of 65 posts
even with short-lived or well-scoped credentials, the behavior behind them can still be pretty opaque depending on the system
so you reduce risk on access, but what happens after can still be hard to reason about or observe
Honestly I would use a self signed certificate if there was a way to tell the browser it is a static blog and not to add friction to the user experience. It's not like LE is adding identity verification to the process any more than a self signed certificate would. It would be nifty if there was some naming standard that could tell the browser a blog is absolutely static and free of anything sensitive like staticblog.domain.tld so that it could dial down the you are about to be pwned! which I am sure some would abuse but that's fine, let them.
Earlier quoted context omitted.
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.
It’s like 12 lines of terraform to fully automate this, inside your existing IaC infrastructure. It’s not complex.
Earlier quoted context omitted.
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.
What’s your excuse?
Earlier quoted context omitted.
Part of the threat model for an Engineering team is that people come and go. They move teams which have different levels of access. They leave the organization, in most cases, on good terms. I want to set up infrastructure where I don't need to remember that your SSH pubkey is baked into production configuration after you leave the company. There are several options for setting up per-connection keys that are dispens…
This is completely solved by SSH certificates. You still have the same private key in the hardware, but instead of using the public key directly, you issue temporary (~1 hour) SSH key certificates. I even automated it using an SSH proxy. The target machines then just need to put the CA cert in the authorized_keys files.
Its still early, but my aim for this project is to be the simplest/easiest "SSH login via SSO" available on the market. open for feedback & suggestion