Securing Cloud Privileged Roles: AWS, Azure, and GCP with PAM
DataDike Security Research
PAM Research & Field Engineering
Every major cloud platform now ships a role-elevation primitive: AWS has IAM Identity Center plus AssumeRole, Azure has Privileged Identity Management (PIM) for Entra ID and resource roles, GCP has IAM Conditions plus Recommender. These primitives are good — for what they cover. The problem is that they cover one layer of the privileged-access stack, and customers who treat them as the whole answer keep getting blindsided by the layers underneath.
What the cloud platforms do well
Cloud-plane role activation is genuinely solved. An engineer who needs "Production Database Admin" in AWS can request it through IAM Identity Center, get the role for two hours via STS AssumeRole, perform the work, and have the activation expire. The same pattern works in Azure PIM and (with more configuration) in GCP. The audit trail at the cloud-plane level — CloudTrail, Azure Activity, GCP Audit Logs — is comprehensive and tamper-evident.
For pure cloud-control-plane work — creating a load balancer, modifying a security group, attaching an IAM policy — the native primitives are sufficient. Most security teams that built their entire cloud privileged-access program around AWS Identity Center are not wrong; they have closed the part of the problem that lives on the cloud control plane.
Where the gaps sit
The cloud control plane is not where the data lives. The data lives on EC2 instances, RDS databases, Cosmos DB collections, BigQuery datasets, and SaaS applications the cloud platform has no native admin over. When an engineer needs to actually look at production data — debug a customer issue, investigate a billing dispute, run a one-off query — the AssumeRole gets them onto the box, but what they do once inside is invisible to CloudTrail.
- AssumeRole gets you SSH access to the EC2 instance — the SSH session itself is not recorded by any native primitive. The keystrokes, the commands, the data fetched are dark.
- Azure PIM activates the "SQL DB Contributor" role — the SQL queries you run as that role are not captured in Azure Activity. The database has its own audit if you enabled it, but you have not joined it to the activation.
- GCP IAM Conditions lets you reach the GKE cluster — kubectl exec into a production pod runs inside the cloud platform's blind spot. The container audit log is your only artifact if it exists.
The audit story collapses at the moment the engineer crosses from the cloud plane into the workload plane. For a routine misconfiguration, this is uncomfortable but tolerable. For an incident investigation or a regulatory inquiry, it is fatal — the regulator wants the keystroke trail, not the role-activation event.
The hybrid model that actually works
The architecture that closes both layers is hybrid: native cloud role activation for cloud-plane authorization, PAM gateway for the actual session that follows. The engineer requests "Production EC2 SSH" through the PAM workflow. The PAM gateway brokers the AWS AssumeRole step, gets the temporary credential, and then proxies the SSH session — recording every keystroke, command, and file transfer. The audit chain becomes: PAM session ID → AWS AssumeRole event ID → CloudTrail event ID → SSH command audit. Joined.
The same pattern works across the three major clouds. In Azure, the PAM brokers the Azure PIM activation, then proxies the RDP or SSH session that follows. In GCP, the PAM activates the role via IAM Conditions, then proxies the gcloud or kubectl session. The native primitives are not replaced — they are integrated. The PAM is the audit envelope wrapped around them.
The architectural smell test
If your incident-response team can describe a privileged session at the cloud-role level ("the engineer was Production Database Admin from 14:00 to 14:30") but cannot describe what the session did at the workload level ("what specific SQL ran"), you have the gap this article is about.
The cost asymmetry
Cloud-platform-native role activation is essentially free if you are already paying for the cloud subscription. Wrapping it in a PAM gateway has cost — the platform, the integration, the operator time. Customers often weigh those costs against each other and conclude the native primitive is "good enough." That conclusion is correct until the first incident.
A single privileged-access incident that requires regulatory disclosure typically costs millions in remediation, legal, and customer-trust impact. The marginal cost of the PAM gateway across the estate is, by comparison, a known and bounded operational expense. The decision framing is not "PAM vs. native" — it is "PAM next to native, so the audit chain closes."
How DataDike covers cloud privileged access
DataDike integrates natively with AWS IAM Identity Center, Azure PIM, and GCP IAM Conditions for the role-activation step, and provides the agentless session proxy + recording for the workload-level session that follows. The audit join — PAM session ID to cloud event ID — is automatic. A regulator who asks "what did this person do in production on Tuesday" gets one timeline, not three.
For multi-cloud customers, the same operator console covers AWS, Azure, GCP, OCI, and on-premises in one inventory. The privileged-access policy is defined once and enforced across the four planes; the audit stream is consolidated; the operator experience is consistent. That consistency is what scales as the estate grows across clouds — which it always does.
