azure-rediscache-regeneratekey-can-control

regenerateKey/action allows rotating the Redis access keys, enabling session revocation and credential rotation for persistence. Treated as control capability.

derived azure emits CanAdminister

match

A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.

where

emit

source type	`Identity`
target type	`Cache`
source	`?principal`
target	`?cache`
permissions	`Microsoft.Cache/redis/regenerateKey/action`
conditions	`iam_permission`
state logic	if a deny assignment or deny Azure Policy covers regenerateKey/action: BLOCKED; else ACTIVE. The principal can call the ARM regenerateKey REST API to rotate the primary and secondary access keys. Once rotated, old keys no longer authenticate to the Redis data-plane (revoking all existing sessions), and the new key can be retrieved via listKeys/action to establish persistence with attacker-controlled credentials.

source type

Identity

target type

Cache

source

?principal

target

?cache

permissions

Microsoft.Cache/redis/regenerateKey/action

conditions

iam_permission

state logic

if a deny assignment or deny Azure Policy covers regenerateKey/action: BLOCKED; else ACTIVE. The principal can call the ARM regenerateKey REST API to rotate the primary and secondary access keys. Once rotated, old keys no longer authenticate to the Redis data-plane (revoking all existing sessions), and the new key can be retrieved via listKeys/action to establish persistence with attacker-controlled credentials.

Narrative

{principal.name} holds Microsoft.Cache/redis/regenerateKey/action on {cache.name}, allowing key rotation to revoke all existing client sessions and (if combined with listKeys permission) establish persistence with new attacker-controlled keys.

Raw rule rules/derived/azure/rediscache.yaml

id: azure-rediscache-regeneratekey-can-control
emits: CanAdminister
description: regenerateKey/action allows rotating the Redis access keys, enabling session revocation and
  credential rotation for persistence. Treated as control capability.
match:
- - principal: null
  - HasPermission
  - cache: null
where:
- node_type(?cache) == Cache
- ?cache.provider_type == 'Microsoft.Cache/redis'
- ?principal has EFFECTIVE Microsoft.Cache/redis/regenerateKey/action at ?cache scope
emit:
  source_type: Identity
  target_type: Cache
  source: ?principal
  target: ?cache
  permissions:
  - Microsoft.Cache/redis/regenerateKey/action
  conditions:
  - iam_permission
  state_logic: 'if a deny assignment or deny Azure Policy covers regenerateKey/action: BLOCKED; else ACTIVE.
    The principal can call the ARM regenerateKey REST API to rotate the primary and secondary access keys.
    Once rotated, old keys no longer authenticate to the Redis data-plane (revoking all existing sessions),
    and the new key can be retrieved via listKeys/action to establish persistence with attacker-controlled
    credentials.'
  confidence: '0.93'
  derived_from:
  - <HasPermission edge_id (regenerateKey/action)>
  false_positive_note: "regenerateKey is a distinct action from listKeys. A principal with regenerateKey\
    \ can rotate keys but may not have listKeys permission \u2014 however, Contributor and Owner roles\
    \ typically include both. If regenerateKey is present without listKeys, the impact is session revocation\
    \ only (availability); if both are present, the attacker can establish persistence (confidentiality\
    \ + integrity)."
  narrative: '{principal.name} holds Microsoft.Cache/redis/regenerateKey/action on {cache.name}, allowing
    key rotation to revoke all existing client sessions and (if combined with listKeys permission) establish
    persistence with new attacker-controlled keys.'