Summary
- A researcher alleges that Azure backup permissions could be converted into AKS cluster-administrator access.
- A separate Google Cloud finding claims Config Connector can use its privileged service account to grant organisation-level permissions.
- Microsoft and Google did not accept the reports as conventional vulnerabilities, and no exploitation has been established.
Separate identity findings involving Microsoft Azure and Google Cloud have exposed a disputed boundary between customer configuration and service design when managed identities hold more authority than the people able to invoke them.
Researcher Justin O’Leary describes both attack paths as confused-deputy weaknesses. In this class of failure, a less-privileged user causes a trusted service to use its own authority without confirming that the initiating user would have permission to perform the same action directly.
The Azure finding concerns Azure Kubernetes Service backup and the Trusted Access relationship used to let a backup vault interact with a cluster. O’Leary says a user holding the Backup Contributor role, which does not itself grant Kubernetes administration, could trigger operations that resulted in cluster-administrator access.
The issue was reported to Microsoft and the CERT Coordination Center. O’Leary says Microsoft did not classify the behaviour as a vulnerability, although the relevant path later changed in a way he describes as a silent fix. Microsoft has not publicly adopted that characterisation in the reviewed material.
The Google Cloud finding concerns Config Connector, an open source Kubernetes operator that manages Google Cloud resources. O’Leary alleges that a Kubernetes user with namespace-level access can submit an IAM policy object referencing an external organisation. Config Connector then sends the request to Google Cloud under its elevated service account without checking whether the initiating Kubernetes identity has equivalent authority.
Where the Config Connector service account holds broad organisation-level permissions, the researcher says the user could grant an external identity an owner role across the organisation. Google’s vulnerability-reward process concluded that the reported behaviour was working as intended because exploitation depended on customers assigning excessive authority to the service account.
O’Leary disputes that assessment and points to Google documentation supporting organisation-level resource management through Config Connector. His technical disclosure identifies the missing control as an authorisation check between the Kubernetes user and the cloud resource being changed.
No exploitation has been reported for either finding, and the most serious outcomes depend on particular roles, permissions, and deployment choices.
Effective privilege is built from a chain
Managed services frequently need permissions that ordinary users do not possess. Backup platforms, deployment controllers, infrastructure operators, integration services, and automation accounts all sit between a person or workload and the cloud control plane.
Risk develops when the service validates that a request is technically valid but does not establish whether the initiating identity is authorised for the target resource. The service account can then amplify authority that the user does not hold directly.
Audit trails can further obscure responsibility. Cloud logs may identify the privileged service account as the actor, while the lower-privileged Kubernetes or Azure identity appears in a different system. Investigators must correlate application, cluster, identity, and control-plane records to reconstruct who initiated the action.
The disagreement also shows the practical limits of shared-responsibility language. Customers control service-account permissions, but providers design the mechanism through which less-privileged users submit instructions to those accounts. A broad warning to apply least privilege does not resolve whether a service should verify the caller’s authority before using its own.
European regulated organisations need a full map of managed identities, their effective permissions, the users and workloads able to invoke them, and the resources they can change. DORA, NIS2, and sector-specific resilience requirements depend on establishing who can exercise privileged authority and what evidence survives after an action occurs.
Reviewing each role in isolation will not identify these paths. The relevant permission is the combined result of the initiating user, the intermediary service, the service identity, the target resource, and any cross-platform trust relationship connecting them.
Microsoft and Google may continue to reject the vulnerability classifications, but the underlying control remains measurable: where a service can take an action that its caller cannot, the authorisation boundary needs to be explicit, tested, logged, and understood.
