keb
52b6257dd5
On an Azure account's group row, the Details pane now describes the account: | field | from | |---|---| | name | token `name` | | user (and "service principal") | az's account list | | tenant: name · ID | az's account list (the name is borrowed from another entry in the same tenant when az left it out) | | object ID | token `oid`; `y` on the row copies it | | sign-in: MFA or not, and how | token `amr` | | directory roles | token `wids`: built-in roles by name, others as `role 1a2b3c4d`, the default member role left out | | subs: count · default | az's account list | | cloud | az's account list, when not AzureCloud | Nothing is fetched for it: the claims are the ones from the token lazysecrets already gets for the account's own tenant, read without verification. The token itself is never stored or shown. Before the first token, only the az-list fields show. A failing account shows its sign-in problem there instead (from #4). New optional `provider.Accounts` interface; `azure.Provider` implements it. Tests: the fields from claims and az's list, sign-in methods, the UI showing it on the group row only, and `y` copying the object ID. Checked against a real signed-in account (name, MFA · password, default subscription) and an expired one (az-list fields only, since there's no token). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Karl-Einar Bergstrøm <karl-einarb@outlook.com> Reviewed-on: #5
2.3 KiB
Azure Key Vault
lazysecrets reads Azure with your az CLI login: run az login once, and
it reuses it.
Accounts
Every account signed in to az gets its own group in the Sources pane
(az login again with another account to add one), and each account's
vaults are read with that account. A subscription several accounts can see
is listed under each, since their permissions can differ.
A service principal is used instead when AZURE_CLIENT_ID,
AZURE_TENANT_ID and a secret or certificate are set in the environment.
On an account's group row, the Details pane shows who it signs in as: name,
user, tenant, object ID, whether the session used MFA, directory roles
(built-in ones by name) and its subscriptions. It's read from az's account
list and the token lazysecrets already has, so nothing is fetched for it.
y there copies the object ID, the one access policies and role
assignments ask for.
If an account's az login has expired, the status line says so once, and the
Details pane on that account's rows says it until you sign in: press L
there to run az login for it without leaving lazysecrets, and everything
reloads.
Permissions
Vaults are discovered with Resource Graph, so you need read access to the vault resources (e.g. Reader). Key Vault data-plane access is separate (Azure RBAC or access policies). With RBAC, typically:
| To | Role |
|---|---|
| list secrets, keys and certificates | Key Vault Reader |
| read secret values | Key Vault Secrets User |
| read certificate details | Key Vault Certificate User |
A missing permission is shown in the pane, including the action that was denied.
Vaults you can't discover
A vault you can read but not see through Resource Graph can be pinned in the config; it's listed under "Pinned vaults" and read with az's default account:
providers:
azure:
vaults:
- https://kv-foo.vault.azure.net/
hideSubscriptions: [platform-mgmt] # by name or ID
What's shown
Secrets, keys and certificates, each on their own tab of the Secrets pane
([/]). space reveals a secret's value, or the public material of a
key (PEM public key) or certificate; private key material is never
fetched. v lists an item's versions. Items expiring within
expiryWarningDays (30 by default) are marked ⚠ 12d, expired ones ✗.