Cloud Identity as the New Security Perimeter

Introduction

The cloud perimeter is no longer defined by where a workload is hosted or which IP ranges can reach it. Modern cloud environments are built around identities: human users, service accounts, managed identities, workload identities, roles, federated principals and temporary sessions. Once an identity is trusted, the cloud control plane determines what that identity can reach, what it can change and which additional identities it can become.

A compromised credential does not have to provide direct administrative access to be dangerous. A low-privileged principal may be able to assume another role, attach a more privileged identity to a resource, create or use a long-lived credential, modify a trust policy, or move into another account, project, or tenant. The security boundary is therefore not simply the identity itself - it is the graph of permissions and trust relationships surrounding that identity.

Google Cloud's Threat Horizons H2 2025 report reinforces this concern: observed incidents for the first half of 2025 identified weak or absent credentials as the predominant initial-access category at 47.1%, followed by misconfigurations at 29.4%. The report describes credential compromise and misconfiguration as persistent cloud entry points. MITRE ATT&CK similarly treats valid cloud accounts as a technique that can support initial access, persistence, privilege escalation and defense evasion across multiple stages of an adversary's operation.

Cloud identity has therefore become a security perimeter in its own right. Testing that perimeter requires understanding not only who can authenticate, but what an authenticated principal can become.

Identity Is the New Authorization Boundary

In a traditional network model, a security assessment begins with an internet-facing address, firewall rule, VPN, or exposed service. In cloud environments, the same application may be reachable through multiple managed services while authorization is enforced through IAM policies and identity-aware control planes. The network is no longer a meaningful security boundary - the identity layer is.

AWS IAM policies determine which actions a principal can perform against which resources. Azure uses Microsoft Entra identities, service principals, managed identities, role assignments and resource scopes. Google Cloud IAM uses principals, roles, service accounts, impersonation and resource hierarchy. Although the terminology differs, the underlying security problem is consistent: an identity receives a set of effective permissions from multiple policies, relationships and trust decisions - and those permissions may be far broader than intended.

A useful assessment asks a deeper question than "Does this account have administrator privileges?" It asks what the account can directly access, what it can modify, which identities it can assume or impersonate, which workloads it can control and whether those paths eventually lead to a more privileged security context.

Overly permissive policies are especially dangerous because a broad permission can become an escalation primitive when combined with another capability. An AWS identity that can perform permissions-management actions may be able to alter its own access controls. A Google Cloud principal that can impersonate a more privileged service account can effectively operate as that service account. In Azure, a service principal or managed identity becomes a powerful attack vector when it carries broad role assignments.

Exposed Access Keys: When Authentication Becomes Initial Access

Long-lived access keys remain one of the most reliable initial-access vectors in cloud environments. An access key stored in source code, a CI/CD variable, a container image, a developer workstation, a public repository, or an application configuration file can hand an external party a fully functional cloud identity - no exploitation required.

AWS recommends temporary credentials wherever possible, alongside least-privilege policies, regular removal of unused credentials and analysis of cross-account access. Google Cloud similarly warns that service account keys are powerful credentials and recommends workload identity federation as a more secure alternative. Despite this guidance, static keys continue to appear in repositories, build pipelines and artifact stores - often committed once and never rotated.

The important security question is not merely whether a key is exposed. It is what that identity can do once the key is used. A leaked developer credential with read-only access may expose source artifacts, configuration, or secrets that point toward another identity. A compromised deployment credential may be able to modify infrastructure. A service account key may directly authenticate as a highly privileged workload identity.

An assessment should therefore follow the credential into the cloud control plane and enumerate what is reachable from it:

aws sts get-caller-identity

That single command establishes the identity in play. Everything that follows - what the identity can read, modify, assume, or invoke - defines the true blast radius of the exposed key.

IAM Privilege Escalation: The Permission Behind the Permission

Cloud privilege escalation rarely looks like a single "become administrator" function. More often, it is a sequence of legitimate cloud capabilities that together cross an intended trust boundary - each step individually defensible, the combination dangerous.

Consider an AWS role with the following permissions:

json

{
  "Effect": "Allow",
  "Action": [
    "iam:PassRole",
    "lambda:CreateFunction",
    "lambda:UpdateFunctionCode"
  ],
  "Resource": "*"
}

Individually, these permissions may be justified for a deployment workflow. Together, they allow the principal to deploy code under an IAM role with broader permissions than its own - effectively inheriting a stronger identity through the platform itself. The finding is not that a permission exists; it is that the permission enables a transition into another security context.

Google Cloud documents that permissions such as iam.serviceAccounts.getAccessToken, iam.serviceAccounts.actAs, iam.serviceAccounts.signBlob and service-account key creation can allow principals to act as service accounts. If the target service account carries broader permissions than the initiating principal, the relationship is an escalation path - not a configuration error that is obvious in isolation.

Azure introduces equivalent risks through role assignments, application identities, managed identities and delegated permissions. A service principal granted the ability to create new role assignments, or to assign roles to other identities, may be able to escalate its own access without any further privilege.

The most meaningful assessment maps privilege transitions rather than enumerating roles. The central question becomes: "From this identity, which stronger identity can I cause the platform to use on my behalf?"

Service Account and Workload Identity Abuse

Cloud applications operate through non-human identities by design. Service accounts, managed identities and workload identities are not exceptions to the model - they are the model. That makes them attractive escalation and lateral-movement targets, precisely because they frequently carry broader permissions than individual users and are subject to less scrutiny.

Google Cloud explicitly describes service accounts as both principals and resources. A principal can be granted permission to impersonate a service account, while the service account itself holds access to other cloud resources. Impersonating a more privileged service account is therefore a privilege escalation primitive and service-account impersonation across projects can create lateral-movement chains that cross organizational boundaries without triggering obvious alerts.

Microsoft Entra distinguishes between applications, service principals and managed identities as workload identities. Managed identities remove the need for developers to manage credentials directly - a genuine security improvement - but the underlying identity still carries permissions that can be abused if the workload running under it is compromised. A managed identity assigned the Contributor role on a subscription is a powerful credential, whether or not a human operator ever handles a key.

The security boundary therefore extends into CI/CD pipelines, virtual machines, Kubernetes workloads, serverless functions and deployment platforms. If an attacker gains control of a workload that carries a powerful identity, the workload itself becomes the credential - no key extraction required.

Role Chaining and Temporary Elevated Access

Cloud platforms are built to support temporary changes in privilege and that design is intentional. AWS STS AssumeRole creates a session with temporary credentials and AWS explicitly supports role chaining - where one assumed role assumes another. Google Cloud service-account impersonation similarly allows an authenticated principal to operate as a service account for a bounded period.

Temporary access is safer than unmanaged permanent privilege, but only when the trust path is tightly controlled. A role intended for incident response becomes dangerous if routine operators can invoke it without additional authorization. A deployment role becomes an escalation path when it can assume a production administration role - even if each individual assumption step appears legitimate.

This is why role chaining must be understood as an identity graph rather than a list of individual role permissions. Starting from a compromised identity, an assessment maps each permitted transition:

Identity A → Role B → Role C → Sensitive Resource

Each arrow in that chain may reflect an individually approved trust relationship. The risk is the chain itself. A chain of three individually approved steps can move from a low-privileged developer credential to administrative access over production data without any single step appearing anomalous in isolation.

Metadata Service Attacks: The Workload Becomes the Credential

Cloud metadata services demonstrate particularly clearly why identity and infrastructure cannot be separated.

On AWS, an EC2 instance with an attached IAM role can retrieve temporary credentials through the Instance Metadata Service at a well-known local address. AWS recommends IMDSv2, which requires a session token and is more resistant to server-side request forgery attacks. If an attacker achieves code execution on a workload and can reach the metadata endpoint, the compromise moves from the application layer directly into the cloud control plane - without touching a single credential store.

The same conceptual risk exists across cloud platforms wherever workloads obtain tokens from platform-managed identity endpoints. Azure Instance Metadata Service and Google Cloud metadata endpoints provide similar capability. The security boundary is no longer the virtual machine alone - it is the relationship between the workload, its attached identity, the metadata mechanism and every resource that identity can reach.

Metadata exposure must therefore be evaluated alongside IAM privilege, not separately. A metadata endpoint that exposes a tightly scoped identity carries a different risk profile from one that exposes credentials for a privileged role. The metadata service is the delivery mechanism; the attached identity determines the blast radius.

Cross-Account and Cross-Tenant Trust Abuse

Multi-cloud environments contain another layer of complexity: trust does not stop at the account, subscription, project, or tenant boundary.

AWS supports cross-account role assumption through trust policies. Google Cloud supports service-account impersonation across projects. Azure supports cross-tenant workload identity scenarios. These capabilities are legitimate and often essential to enterprise architectures. They also create trust relationships that are frequently overlooked during security reviews, because they are documented separately from the resources they govern.

Consider an AWS environment where a development account contains a role trusted by a production account. If the development role is compromised and the production trust policy accepts it without sufficient conditions - such as an external ID or a source IP restriction - the account boundary provides less isolation than the architecture implies.

The same pattern appears in Google Cloud when a service account in Project A can impersonate a service account in Project B and that second account can continue the chain into additional projects. Each impersonation step crosses a project boundary with a separate access control review, but the chain as a whole creates a path to resources that no reviewer may have considered together.

Azure workload identity federation allows a workload in one tenant to access resources in another when the trust relationship is deliberately configured. The security question is whether the identity, issuer, subject, audience, scope and authorization conditions collectively restrict that trust to the intended workload - and whether anyone reviews those conditions after initial setup.

Use Case: Multi-Cloud Enterprise Environment

Consider a fictional enterprise operating across AWS, Azure and Google Cloud. Customer-facing services run in AWS, analytics workloads operate in Google Cloud and enterprise identity alongside automation services is integrated with Microsoft Entra ID. This is a representative architecture for many large organisations today - not specific to any one industry.

During an authorised assessment, the tester identifies an exposed deployment credential associated with a CI/CD workload. The credential initially provides limited access, but the role can pass another IAM role to a deployment service. That deployment role can update a workload running with a stronger identity.

The resulting path is:

Exposed CI/CD credential → Deployment role → Privileged workload → Temporary credentials → Sensitive cloud resources

The assessment then reveals that the privileged workload's identity can access a Google Cloud service account through an established federation relationship. That service account can impersonate another service account in a separate project, where sensitive data is stored.

The original credential never had direct access to the data environment. The eventual access resulted entirely from a chain of legitimate, individually approved trust relationships - none of which would have raised a flag in isolation.

This is the central lesson of cloud identity security: an identity should not be evaluated only by what it can do directly. Its security exposure depends on what it can cause other identities, workloads and accounts to do on its behalf.

Remediation and Recommendations

The response is not to remove all privilege. Cloud platforms require identities, roles, service accounts, federation and temporary access to operate at scale. The objective is to make each trust relationship deliberate, constrained, observable and short-lived where practical.

AWS recommends temporary credentials for workloads, least-privilege policies, conditions in IAM policies, IAM Access Analyzer, permissions boundaries and controls for public and cross-account access. Google Cloud recommends avoiding service-account keys where possible, using workload identity federation, limiting service-account impersonation and proactively identifying lateral-movement paths. Microsoft provides workload-identity controls for service principals, supports conditional access policies for workload identities and enables federation as an alternative to long-lived secrets.

Across all three platforms, several practical controls reduce exposure: enforce IMDSv2 on all EC2 instances; apply conditions to all cross-account trust policies; review service-account impersonation grants regularly; use just-in-time access for elevated roles rather than standing privilege; and instrument all AssumeRole, impersonation and federation events for anomaly detection.

The deeper architectural principle is consistent across all three providers: authentication should establish identity, but authorization must continuously constrain what that identity can become.

Conclusion

The modern cloud perimeter is an identity perimeter.

Credential compromise remains a practical entry point because cloud credentials are not merely authentication artifacts - they are portable representations of authority. Misconfiguration compounds the problem by creating permissions, trust relationships, or workload identities that extend beyond their intended scope. Google Cloud's H2 2025 Threat Horizons research confirms that weak credentials and misconfiguration continue to dominate cloud initial-access categories. MITRE ATT&CK documents how valid cloud accounts can support initial access, persistence, privilege escalation and defense evasion within the same campaign.

For defenders, the critical shift is from asking "Who has access?" to asking "What can this identity become?"

That means treating IAM privilege escalation, exposed keys, service-account abuse, role chaining, temporary elevated access, metadata-service exposure and cross-account or cross-tenant trust as connected parts of one identity attack surface - not as separate configuration issues owned by separate teams.

When identity becomes the perimeter, the most important security boundary is no longer the network segment surrounding the workload. It is the set of permissions and trust relationships that determine what the workload, user, or service can become - and the visibility needed to detect when that boundary is being tested.

Connect with QuassrCyberTech Experts

Ready to strengthen your organization's security posture?

At QuassrCyberTech, our specialized cybersecurity solutions help organizations stay ahead of evolving risks. From Vulnerability Assessment and Penetration Testing (VAPT) to Security Operations Center (SOC) implementation, Red Team exercises, and Governance, Risk, and Compliance (GRC) frameworks, we provide the expertise and tools needed to secure your digital assets and infrastructure.