Docs: Client Count Concept clarity.

[aphorise]

Closes #12849 & #13197

[aphorise]

Hey @mladlow any chance you can kindly approve this for merger that relates to former PR's which were in conflict.

[mladlow]

It sounds like Vercel's holding this up. I can't authorize the Vercel build.

[aphorise]

It sounds like Vercel's holding this up. I can't authorize the Vercel build.

@mladlow any ideas what's the fix in these cases we've had a couple other PR's being held up the same (eg: #13092)

[mladlow]

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?

[maxb]

Re the addition of:

Without this, each token will be counted as a client instead.

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.

[aphorise]

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.

[maxb]

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.

vault/sdk/logical/token.go

Lines 176 to 214 in f46941f

	// CreateClientID returns the client ID, and a boolean which is false if the clientID
	// has an entity, and true otherwise
	func (te *TokenEntry) CreateClientID() (string, bool) {
	var clientIDInputBuilder strings.Builder
	// if entry has an associated entity ID, return it
	if te.EntityID != "" {
	return te.EntityID, false
	}
	// The entry is associated with a TWE (token without entity). In this case
	// we must create a client ID by calculating the following formula:
	// clientID = SHA256(sorted policies + namespace)
	// Step 1: Copy entry policies to a new struct
	sortedPolicies := make([]string, len(te.Policies))
	copy(sortedPolicies, te.Policies)
	// Step 2: Sort and join copied policies
	sort.Strings(sortedPolicies)
	for _, pol := range sortedPolicies {
	clientIDInputBuilder.WriteRune(SortedPoliciesTWEDelimiter)
	clientIDInputBuilder.WriteString(pol)
	}
	// Step 3: Add namespace ID
	clientIDInputBuilder.WriteRune(ClientIDTWEDelimiter)
	clientIDInputBuilder.WriteString(te.NamespaceID)
	if clientIDInputBuilder.Len() == 0 {
	return "", true
	}
	// Step 4: Remove the first character in the string, as it's an unnecessary delimiter
	clientIDInput := clientIDInputBuilder.String()[1:]
	// Step 5: Hash the sum
	hashed := sha256.Sum256([]byte(clientIDInput))
	return base64.StdEncoding.EncodeToString(hashed[:]), true
	}

#12820

[aphorise]

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.

[maxb]

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 auth/token/create and related APIs, which are not associated with any Identity Entity at all.

In your example of using the userpass auth method, there are entities involved as is now normal, so that part doesn't apply.

[aphorise]

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 auth/token/create and related APIs, which are not associated with any Identity Entity at all.

In your example of using the userpass auth method, there are entities involved as is now normal, so that part doesn't apply.

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.