docs: correct KMS admin token transport (RPC field, not HTTP header)

Author: kvinwang

docs/deployment.md

@@ -439,7 +439,7 @@ curl http://<new-kms>:9203/finish
 >
 > If you skip this, `Onboard.Onboard` or later trusted RPCs will fail with KMS authorization errors.
 
-> **Admin authentication.** Onboarding itself is gated by attestation and the authorization backend above — not by a token. Separately, the KMS *admin* RPCs (for example clearing the image cache) are guarded by an admin token: set `admin_token_hash` (SHA-256 hex of your token) in the KMS `kms.toml` and send the token on admin requests via `Authorization: Bearer <token>`. An empty hash denies all admin RPCs (fail-closed). See [dstack-kms admin authentication](../dstack/kms/README.md#admin-api-authentication).
+> **Admin authentication.** Onboarding itself is gated by attestation and the authorization backend above — not by a token. Separately, the KMS *admin* RPCs (for example `ClearImageCache`) are guarded by an admin token: set `admin_token_hash` (SHA-256 hex of your token) in the KMS `kms.toml`. Unlike VMM/gateway, the KMS admin token is not an HTTP header — it is passed as the `token` field of the admin RPC request (the raw token; the server hashes and compares it). An empty hash denies all admin RPCs (fail-closed). See [dstack-kms admin authentication](../dstack/kms/README.md#admin-api-authentication).
 
 ---
 

docs/security/security-best-practices.md

@@ -97,11 +97,11 @@ App key release and KMS key handover still require verified caller attestation f
 
 The VMM, gateway, and KMS management surfaces must have authentication enabled in production:
 
-- VMM: set `[auth] enabled = true` with `tokens` (or `htpasswd_file`) — this guards the entire VMM HTTP/pRPC/UI surface. Never bind to a non-localhost address without it.
-- Gateway: set `[core.admin] admin_token` (or `htpasswd_file`) and keep `insecure_no_auth = false`.
-- KMS: set `admin_token_hash` (SHA-256 hex of the admin token); an empty hash denies all admin RPCs.
+- VMM: set `[auth] enabled = true` with `tokens` (or `htpasswd_file`) — this guards the entire VMM HTTP/pRPC/UI surface. Never bind to a non-localhost address without it. Clients send `Authorization: Bearer <token>` or `X-Admin-Token`.
+- Gateway: set `[core.admin] admin_token` (or `htpasswd_file`) and keep `insecure_no_auth = false`. Clients send `Authorization: Bearer <token>` or `X-Admin-Token`.
+- KMS: set `admin_token_hash` (SHA-256 hex of the admin token); an empty hash denies all admin RPCs. The KMS admin token is not an HTTP header — it is passed as the `token` field of the admin RPC request.
 
-Only bcrypt htpasswd entries are accepted (create with `htpasswd -B`), and credential comparisons are constant-time. Clients authenticate with `Authorization: Bearer <token>` (or `X-Admin-Token`). All three are fail-closed.
+VMM and gateway share the HTTP authenticator (bcrypt-only htpasswd via `htpasswd -B`, constant-time comparison). The KMS admin token is compared as a constant-time SHA-256 match. All three are fail-closed.
 
 ## Keep private material owner-only