However, when I try and set a max # of versions on this kv store, nothing happens. Also, according to your documentation, this should be defaulting to 10. It’s not - the config shows 0 and I can confirm that I’m seeing hundreds of versions of my secret being generated.
[root@m0947364 ~]# vault write systemcreds/config max_version=8
Success! Data written to: systemcreds/config
[root@m0947364 ~]# vault read systemcreds/config
Key Value
--- -----
cas_required false
delete_version_after 0s
max_versions 0
I’ll have to check to see if somehow I’m setting an unlimited version flag or something in my request, assuming you can overwrite the secrets engine config at the secret itself.
This is interesting. If I look at the metadata, I see maximum versions is set to 0. but, if I edit the metadata, I see that it’s 10. Could this be a bug?
It looks like a bug in the UI to me - substituting 0 for 10, presumably via some misfiring defaulting logic.
Regardless, if the number is set to 0 at the individual item metadata level, it should then be using the global value set in the secrets engine config.
I’m unable to explain how you’re managing to see so many secret versions - it shouldn’t be possible, unless the max_versions value was manually raised to a large number.
Thanks @maxb, much appreciated. I’ll open a bug for the UI issue and see what becomes of that.
As for the actual problem of my secret not respecting max_versions, I’m still at a loss. I’m very much a vault newbie here and I’ve basically just implemented the design for this POC “as is” from the Hashicorp design documentation. I took a look at the script that runs on my client server, calls the secret gen plugin to generate a password, stores that password in vault and then updates it on the client, and I see that it’s actually setting max_versions=12 in the JSON payload when writing it to vault. I’d think that there would be logic for what vault does when the secret is set to one value and the actual kv store another, and it wouldn’t be ‘do not honor either’.
I’m going to test maybe setting them to the same value and also removing the max_versions from the client JSON that’s posted to vault to see if either of those make a difference. I’ve already tested setting this in the script while the kv store itself is set to 0 (that was my initial setup).
Actually, this one is all on me. The main issue I was having was that I thought max_versions set at the kv store wasn’t being honored, but I was just thinking about it all wrong. I’m rotating a password every 5 min, so when I came back after several hours and noticed the version # going up by 30 or 40, I just assumed - “hey, that’s not limiting versions”. If only I had checked version history to see that in fact, setting max_versions at the kv store does limit the number of versions of the secret that are kept - but of course the version # still increments!
Also, the UI mismatch I think is a non-issue as well, or at best a clarification issue. I was looking at the metadata for a given secret, not at the kv store level. You can actually edit the max_versions at the secret level, and if you change that from 10 (which I think is just displaying as a default), it will in fact change it on the secret. Though I believe from my testing that the kv store value will trump one set at a specific version of a secret itself.
Not sure if this thread is close-able, but it should probably be closed.
