Launched this week
Korvalis
Just-in-time cloud access with a guard watching the session
16 followers
Just-in-time cloud access with a guard watching the session
16 followers
Korvalis watches your cloud and shuts down any destructive session in seconds, whoever's behind it. Just-in-time access, no proxy, live in minutes. Free to start.
the "judges intent instead of matching commands" part is the interesting bet and also the scary part. what happens on a false positive, say a real planned migration that drops and rebuilds a table during a maintenance window, and it looks exactly like the thing you'd want stopped. is there a fast override so the engineer doing legitimate destructive work isn't the one who gets locked out mid-task, or does getting flagged always mean a human has to intervene from outside the session to let it continue
@galdayan For planned work there are two options: open a maintenance window for a user, or switch termination off globally. It keeps watching either way, it just won't cut.
That exists because you're right. When the DROP fires the rebuild hasn't happened yet, so it looks exactly like someone wrecking a table. Intent doesn't save you there, which is why the window has to.
If nobody opened one, though, there's no per-session override today. The session gets cut, you reconnect, carry on. Turning termination off for one specific session is basically what you're describing, and it's the obvious gap. Would that solve it?
The reason it doesn't fire on you constantly is that the sessions you want stopped mostly don't behave like yours. A burglar doesn't know where the safe is, so he opens every drawer. Someone running a planned migration walks straight to the table. Attackers and confused agents wander before they wreck.
That's a signal, not proof, so termination stays off by default and observe mode just tells you what it would have killed until you trust it.
And either way, we end sessions, we don't undo them. If the DROP already reached the database, cutting the terminal changes nothing.
@nickkrykunov yeah, a per-session override closes the gap you're describing. one thing that'd worry me though - if maintenance windows get approved through the same Slack flow as regular access grants, doesn't that just move the attacker's job from covering their tracks to getting one window rubber-stamped first? feels like the window-granting step needs to be harder to fake than the thing it's protecting.
@galdayan Ha, you're right. Our thinking was that high-severity actions like flipping the guard off shouldn't live in Slack alone, they'd need a second confirmation out of band, email or similar, so popping one channel isn't enough.
Though that stops a stolen Slack account more than a rubber-stamp. For the rubber-stamp case it probably wants a second person too, not just a second channel.
@nickkrykunov that makes sense as the fix. is the second-approver step something Korvalis enforces today, like the window doesn't open until a different person reacts in Slack, or is it on you to set that policy up yourselves right now? asking because if it's just a convention your team follows rather than something the tool requires, it'll be the first thing a busy team skips under pressure.
the no-proxy setup is a really smart call, makes the whole "live in minutes" promise actually believable instead of a marketing line. curious how it handles edge cases with shared sessions
@sudenureliqx6g Good question, and it's the one I get asked least.
We do see who it is. Every session carries the IAM identity that started it, the ARN, the email where we can resolve it, source IP, user agent. So attribution isn't really the gap.
The gap is when several people share one IAM identity, or everyone assumes the same role. Then the ARN is the same for all of them and you're down to source IP and user agent, which is weak. And if they're genuinely on one live session together, cutting it cuts everyone on it.
Which is a big part of why the product also hands out short-lived creds per person per task. Not just least-privilege hygiene, it's what makes attribution mean anything in the first place. And it starts in observe mode, so you watch what it would have killed before you let it kill anything.
set it up on a tiny aws sandbox and watched it kill a rogue root session while i was still reading the docs, very impressive how fast the just in time access kicks in
@sleymanimefent Ha, love that it worked before it exists. Once we actually launch it'll also make you coffee and take the 3am page for you. Waitlist's open for the real thing.
The setup was surprisingly painless, and seeing a rogue session get killed in real time gave me real peace of mind. Just-in-time access without a proxy is a genuinely nice touch.
@tubauwvo Ha, appreciate it, but honestly nothing to set up yet. We're still at the waitlist stage, so whatever that was, it wasn't us. Real thing's coming, list's open if you want in early.
Really like how you cut straight to the core problem without burying it under a ton of marketing jargon. The no-proxy setup is a smart call, since those are usually a pain to maintain and slow everything down.
@asyabuldukatas Thanks. Maintenance and latency are the obvious costs, but the one that actually sinks proxies is adoption, nobody wants a second terminal. And when the proxy's down, nobody gets to prod at all.