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)
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.
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.
The API Connection in a Logic App contains a secret in order to read/write (depending on permission) a resource. Could be a Key Vault secret, Azure App Service, Exchange Online mailbox, SharePoint Online site..., etc.
The secret typically is a user account (OAuth token), but it could also be an App Id/Secret.
But somebody gave the API Connection permissions to read the KV secrets from, Exchange Mailbox, SharePoint folder etc… And anybody who has access to the API Connection now has access to the KV, SharePoint folder, etc… I do not think this is a problem with Azure, this is just how permissions work…
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]
I'm glad they fixed it, but this doesn't seem too scary??