Integration/Feature Request: Get wallet to feed into Vault

[ljl-geek]

As you know, various institutions use wallet and Kerberos for secrets management. But the newfangled cloud way is to put things in Vault. So we generate secrets with wallet and kerberos, then stuff them into Vault so our cloud deployments can access them with the right credentials.

This is entirely too manual and clunky. It adds too much friction when dealing with Puppet, Kerberos, wallet, Terraform, Docker, Vault, Kubernetes, etc. It ends up being a manual mess, or a stack of clunky make files that still require manual upload of secrets to Vault.

I'm not really a good enough programmer to write the integration, especially since there is a security/secrets handling component to it. But it would provide a Kerberos compatible secret generation utility for Vault.

ljl

[jonrober]

I don't have time or pull to work on it, but just my own thoughts on how something like that would need to work. First up is what you want to put into Vault. Do you just want to put File objects there, or Password and Duo objects as well? Keytab objects don't have the data stored for security, just getting it direct from kerberos each time there's a query, so that's out of bounds.

If you just need generic File-type objects, then it's probably easiest to extend the File object to a VaultFile type that calls vault each time it creates/updates/deletes the data in the file, pushing the changes on into it. Probably using the vault API rather than CLI, but YMMV.

There'd have to be local configuration options for the vault server to push to, a vault token to use, and the path in vault to place wallet objects into. Also possibly a mapping regex to change the wallet names to something more suiting vault.

OTOH if you want multiple File/Password/Duo objects to just automatically push to vault, there'd need to be changes to those classes directly. In addition to the other configuration options, you'd want one to explicitly say whether or not vault is enabled. You'd be much more likely to need to do the mapping regex config option to massage paths when you have multiple types going on. But you can then have a generic update_vault function that just gets called with the namespace and data and have the various objects call it when they update their data.

The big messy point is security. You can't replicate the same permissions in wallet to vault without a lot of vault work as well as wallet work. Vault obviously doesn't understand netdb objects and its Kerberos support is limited, beta-only, and a mess to actually try to use at this point (IMO on the last). There's LDAP support, but I'm not sure how well it works.

So going to specifics, you'd need to write a NetDB module for vault to do NetDB lookups. Vault is in Go, so you couldn't use the normal NetDB API. Otherwise, while you could push the netdb admins into a Vault ACL, you wouldn't update it. More realistically, you could probably just drop NetDB ACLs on the floor and not copy into vault and state that as a limitation.

For kerberos objects, your best bet would be make absolutely sure that your process for setting up vault users allows only matching sunetids to vault id. If there's any way for johndoe to get a vault id for adamhl, then that's a huge problem. But if the vault user provisioning process were absolutely tied to sunetid in some way (probably with the same password reset policy that Kerberos /root principals have at Stanford), then you could map user kerberos identities to vault similarly to how you'd need to update the object class above. (Perhaps a wallet object that works similar to the Keytab object and only allows a user to create/request a username/password auth from vault where username == their Kerberos principal, to bring things full-circle. That could then be extended to machine names for letting machines request AppRole tokens to key themselves for vault off of Kerberos.)

Buuuuut that's all a bit of a mess, and more than it requires code, it requires a specific way of how you distribute vault access to make sure it's tightly tied to how you distribute Kerberos principals. Otherwise there's a lot of potential for secret leakage. No idea how you're currently doing that, so I don't know how sane that is or is not.

So speaking to the simpler case, perhaps you just don't handle ACLs via wallet at all. That's a definite potential security leakage, but if and only if the userbase is small, you could handle it. If, say, everything you would put into vault is owned by a small reasonable number of groups, you could make sure that the objects placed into vault have a namespace including the group and maintain the ACL for that group manually in vault.

The alternative is of course to just use vault instead of wallet. If they ever do bring in the patches to let you do auth via Kerberos, then that would make it potentially much easier to start moving everything but keytab distribution from wallet to vault. But they're not there now.