[bradford]

Suppose user U has read access to Subscription S, but doesn't have access to keyvault K.

If user U can gain access to keyvault K via this exploit, it is scary.

[Vendors/Contingent staff will often be granted read-level access to a subscription under the assumption that they won't have access to secrets, for example.]

(I'm open to the possibility that I'm misunderstanding the exploit)

[p_ing]

My reading on this is that the Reader must have read access to the API Connection in order to drive the exploit [against a secure resource they lack appropriate access to]. But a user can have Reader rights on the Subscription which does cascade down to all objects, including API Connections.

[dh2022]

But also the API connection seems to have secret reader permissions as per screenshot in the article… Giving secret reader permission to another resource seems to be the weak link.

[dh2022]

The API Connection in the example has permissions to read the secrets from the KeyVault -as per screenshot.

It seems to me the KeyVault secret leak originated when KeyVault K owners gave secret reader permissions to the API Connection. (And I will note that granting permissions in Azure requires Owner role-which way more privileged than the Reader role mentioned in this article.)

[edit - article used Reader role, not Contributor role]

[hland]

Your take is spot on, sir.