-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs: Client Count Concept clarity. #16795
Conversation
Hey @mladlow any chance you can kindly approve this for merger that relates to former PR's which were in conflict. |
It sounds like Vercel's holding this up. I can't authorize the Vercel build. |
You could try pushing a new empty commit, though I think Vercel might have a check to make sure there's been a change. You could try making a tiny change and pushing a new commit? |
Re the addition of:
This used to be true, but isn't any more. It was clearly resulting in runaway client count in perfectly reasonable use-cases, so now Vault deduplicates non-entity tokens with the same list of policies assigned. |
^^ I am not sure entirely sure of this - if I create tokens as per for example the default root token (which you should not be using anyway) then what relation would the policies bear on the fact that there are orphaned tokens thus +1 client counts which is what the paragraph is trying to highlight. |
What you wrote was correct in previous versions of Vault. It is no longer correct in current versions of Vault. All tokens with the same (namespace, policy set) now count as a single client. Lines 176 to 214 in f46941f
|
The text does seem applicable to most if not all versions of Vault and I'm not curtain in what @maxb is insisting on (probably for good reasons). Simply put - if I'm using username pass method to create root3 via root2 - even with the same policies then how do these things relate if I can see separate entities (after login) listed? - without some entity alias then how could matching policies suffice in themselves to determine the same count? - eg: vault auth enable userpass ;
vault policy write superuser > /dev/null -<<EOF
path "*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
EOF
vault write auth/userpass/users/root2 password="root" policies="superuser" ;
vault login -method=userpass username=root2 password=root -format=json ;
vault read /identity/entity/id list=true -format=json ;
VAULT_TOKEN=...root2... vault write auth/userpass/users/root3 password="root" policies="superuser" ;
vault login -method=userpass username=root3 password=root -format=json ;
vault read /identity/entity/id list=true -format=json ; hey @mladlow any input here or who may be able to help clarify. |
Hi @aphorise , Let me clarify that the only bit of the change I'm pointing out a problem with, is the discussion on "non-entity tokens" - i.e. tokens created using In your example of using the |
A textual proposal here would be easier to comprehend in terms of the what should be the text in the change than any debate / back and forward - so if you have a suggestion on how the part in question could be improved then I'm open to hearing / reading it - and I could appropriately update the PR to reflect. |
Co-authored-by: Max Bowsher <[email protected]>
Closes #12849 & #13197