infamousjoeg

SPIFFE/SPIRE could work for the identity layer. The risk engine concept is cool. Would love to see that applied to machine identities that are working "on-behalf-of" humans.

Exactly this. They just need to validate the JWT signature against a JSON Web Key Set (JWKS). There's no need to store the data.

Love this minimalist approach!

Check out the Secretless Broker at https://secretless.io. It's a cool open source project that allows applications to not need to know secrets which adheres to 12-factor app guidelines.

Yes, well, now I'll be slacking off at work due to it... so you'll continue to see that trend. Thanks for this!

I developed go-keyconfig after realizing that almost every CLI that I use on a daily basis that requires authentication of some kind drops the secrets in a local filesystem config file in plain-text. As one could imagine, this is ripe for an accidental git commit or easy reading from an attacker.

Every OS comes with a secrets manager of some kind... MacOS has OSX Keychain, Linux has GNOME Keyring, KWallet, and secret-service, even Windows has Credential Manager.

This module is designed to help developers creating apps or CLIs needing to store configuration values in config files a secure means of doing so. It supports All the secret managers mentioned above.

I would love to hear everyone's feedback and thoughts!

CyberArk already does this... it's called Vendor Privileged Access.

I found this game to only be fun to play in VR (I have the Oculus Quest 2). On PC, it's hard to use KBAM as hands as adamredwoods said.

R.I.P. Red Hat

This completely fails to mention the security issues with Jenkins, as well. https://www.cyberark.com/threat-research-blog/tripping-the-j...

Which sucks when it's 2am and you start blowing up a majority of shard holders phones to unseal it because it sealed itself causing a critical outage.

THIS! EVERYTHING THIS!

Sure, the master key is split into shards...

I'm talking about the account creating the database user. Let's take MSSQL, for example. The equivalent to a root account there is `sa`. So, Vault will have control of the `sa` account in order to create leased database users.

If I'm a malicious actor inside the environment, what's stopping me from compromising the `sa` account and mimicking dynamic secrets? I'd need to be comparing Vault logs with Database logs constantly to ensure it was legit.

It's just madness, if you ask me.

That was my first thought, too.

"But... there's a root account... creating another account... which is typically a privileged action. What's protecting that? Is that root account being rotated, too?"

My concern is how you can tell me whether a database user was created by Vault and not by a malicious actor with knowledge of Vault's Dynamic Secrets method mimicking it.

How the heck can I know if it was a legit created database user or not?

You're not the first I've heard going this route... +1

I prefer the RBAC and YAML policies Conjur provides... https://github.com/cyberark/conjur

I'll be there and looking for it :D

How long does the cracking process take? I remember WEP only taking 10 minutes using aircrack-ng in BackTrace... I imagine this takes substantially longer.