Max_versions not applying to a kv2 secrets engine

I have a kv2 secrets engine mounted on systemcreds.

systemcreds/    kv             kv_cb7a169c             system         system     false             replicated     false        false                      map[version:2]    n/a                                                        bb88e75a-b650-1af7-490d-45a34d206667    n/a        v0.13.0+builtin          n/a                                                                 supported

I’m generating secrets and storing them in systemcreds using this plugin GitHub - sethvargo/vault-secrets-gen: A Vault secrets plugin for generating high entropy passwords and passphrases. - which was demo’d as part of the Hashicorp “Painless Password Rotation” talk: Painless Password Rotation with HashiCorp Vault

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

Am I doing something wrong?

Doh! I has max_version not max_versions! Corrected and it works now

Update (if anyone is watching). I’ve made the setting correctly, but it’s not working. I’m still seeing more than 10 versions of a secret.

[root@m0947364 ~]# vault read systemcreds/config
Key                     Value
---                     -----
cas_required            false
delete_version_after    0s
max_versions            10

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?

I’m on vault v1.12.2

Screen Shot 2023-02-03 at 11.01.33 AM

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).

Any more help or suggestions would be welcome?

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! :person_facepalming:

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.