Hi community.
I am currently struggling with an ACL behavior I dont quite comprehend.
Following situation:
we have a number of clients that have access to a PKI based on roles to create their own client certificates against our vault CA. Access Management and groups are managed with keycloak and it worked so far without problems. Recently we update from vault 1.11.x to 1.14x and yesterday to 1.15.x.
After that the behavior seems to have changed and clients lost permissions to access their role. The ACL granting access was/is like this
path "our-pki/*" { capabilities = ["list",] }
path "our-pki/client-role/*" { capabilities = ["list","read"]}
and then “create,list,read,update” on the sign and issue endpoints. (eg “our-pki/roles/clientA/*”)
The behavior was, that clients could list all roles, we can live with that, but not read within the roles of the other clients. Therefore only list was granted to the pki path.
But after the update clients got an access denied from their role subpath. I could reproduce the behavior.
When we change the first rule to [“list”,“read”,] the clients could again access their role. Problem is this allows every client to also read within every other role, which is … okayish but not optimal in our case.
My idea was to give explicit “list” permissions on “our-pki/”, “our-pki/roles/”, and then explicit “list, read” permissions on our-pki/roles/clientA/*.
But this still doesnt work and vault explicitly returns a 403 on the read action against “our-pki/roles/clientA/” path.
current workaround/compromise is to grant “list,read” on our-pki/roles/* with the stated behavior that clientA can read the role for clientB,clientC and so on.
What am I missing? Anyone has any idea where my misunderstanding is? I tested pretty much all iterations and I dont know where I am getting the 403 from.
Thanks for any input