An Azure RBAC action that allows a principal to retrieve storage account access keys. Once those keys are obtained, the principal may gain access far beyond the original role design, including data operations that were not explicitly assigned. It is a sensitive permission because it can convert management access into full storage access.
How List Keys Permission Works
List Keys Permission is an Azure RBAC action that exposes storage account access keys, so the real security boundary is not just the management plane. If those keys are retrieved, they can be used to reach data and operations that were never granted directly in the original role design.
This makes the permission materially different from ordinary read access to a resource configuration. It is a control-plane action with data-plane consequences, which is why organisations often treat it as a high-sensitivity privilege rather than a routine administrative convenience.
Why It Is Sensitive in Azure Storage
Storage account access keys are effectively bearer credentials for the account. Anyone who can list them may be able to act outside the original intent of role assignment, because the keys can unlock broad access that bypasses finer-grained authorization checks.
That design creates an important distinction between identity governance patterns discussed in the Ultimate Guide to NHIs and ordinary permission scoping: once a secret key is exposed, the effective access surface can expand well beyond the principal that requested it.
The risk is amplified when keys are long-lived, shared, stored in code, or reused across systems. In practice, the permission is sensitive because it can turn a narrow administrative right into a much broader trust relationship with the storage account.
Common Misunderstandings and Related Controls
A common mistake is to treat List Keys Permission as harmless because it does not directly grant data operations in the RBAC model. In reality, it may be the step that hands over the material needed to perform those operations anyway.
That is why key exposure, rotation, vaulting, and offboarding are closely related to this permission. NHIMG’s Key Challenges and Risks section is useful context for the broader patterns of over-privilege, unmanaged credentials, and visibility gaps that often surround secret-bearing access.
For a framework lens, Azure key-listing concerns align naturally with OWASP Non-Human Identity Top 10 because the control problem is really about secret exposure, excessive privilege, and the governance of access material, not just role labels.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Sprawl and Credential Management | List Keys Permission exposes storage account keys, a core secret-sprawl and credential-control issue. |
| NHI-03 — Overprivilege and Access Governance | The permission can expand access far beyond the original RBAC intent. | |
| Recommendation — Restrict key-listing rights and rotate exposed storage keys promptly. Apply least privilege to key retrieval paths and review elevated roles regularly. | ||
| CIS Controls v8 | 6.3 — Manage Data Access Based on Need-to-Know | Retrieving storage keys can bypass intended data access boundaries. |
| 5.3 — Manage Account and Access Provisioning | The permission is an access-provisioning decision that can broaden effective access. | |
| Recommendation — Limit who can obtain credentials that unlock broader storage access. Review account privileges that can reveal reusable access credentials. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | The action changes what a principal can effectively access through delegated authorization. |
| PR.DS-1 — Data-at-Rest Protection | Storage keys protect access to data at rest and materially affect exposure. | |
| Recommendation — Map key-listing rights to access-authorisation reviews and remove unnecessary delegation. Protect storage keys as sensitive data-bearing credentials and monitor their use. | ||
Practitioner Guidance
Why practitioners should care: Review this permission as a privilege-escalation path, not a convenience feature. If a principal can list keys, it may be able to bypass the intended granularity of Azure RBAC and convert management access into effective storage access.
Governance implication: Assign it only where there is a clear operational need, and keep ownership of who can retrieve account keys tightly defined. When the permission is unavoidable, treat the resulting keys as sensitive secrets with lifecycle controls, monitoring, and revocation discipline.
Practitioner takeaway: The key question is not whether the role is “read-only” or “admin-like”, it is whether the principal can obtain the secret that changes the access model entirely.
Related resources from NHI Mgmt Group
- What breaks when privileged access reviews rely on a static list instead of actual permission data?
- What is the difference between workload identity and API keys for AI agents?
- How should security teams govern API keys used for generative AI access?
- What problem does ownership attribution solve for service accounts and API keys?
