The caller still needs at least the Reader role, so it was limited to accounts that were added to the Azure subscription as only Readers.
I'm glad they fixed it, but this doesn't seem too scary??
I'm glad they fixed it, but this doesn't seem too scary??
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)
The secret typically is a user account (OAuth token), but it could also be an App Id/Secret.
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]