Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Technology / AI SaaS |
| Cloud Environment | AWS (4 accounts: 1 Dev & Management, 3 Production) |
| Cloud Spend | ~$500K USD/month |
| Team Size | ~150 users |
| Security Posture | Highly security-conscious; dedicated security leads with detailed objections |
| Onboarding Model | CloudFormation stack creating IAM role for Cloudanix |
| Primary Concern | Cloudanix permissions scope too broad for JIT-only use case |
| Resolution | Stripped to JIT-only permissions, added deny statements, impact analysis |
| Cloudanix Scope | Cloud Console JIT (primary), CSPM as opt-in |
The Situation: “Why Does Your Platform Need S3:Get* If We Only Want JIT?”
When a security-conscious team evaluates a new platform, the first question isn’t “what can it do?” — it’s “what access does it require?” For this AI SaaS company, that question surfaced immediately during onboarding.
Cloudanix’s standard onboarding CloudFormation stack creates an IAM role with permissions covering the full platform capabilities: CSPM (misconfiguration scanning), CIEM (identity analysis), workload protection, and JIT access operations. For a customer deploying the full platform, these permissions are appropriate — read access to cloud resources for posture assessment, plus the specific write permissions for JIT (managing IAM Identity Center assignments).
But this team initially wanted JIT access only. They weren’t interested in CSPM findings flooding their dashboard. They weren’t ready for workload-level scanning. They wanted one thing: time-bound access management via JIT. And they wanted the Cloudanix role in their accounts to have permissions for only that one thing.
The security lead’s objections were specific and well-reasoned:
- “Cloudanix has permissions for
s3:Get*as part of ReadOnlyAccess. Why does a JIT platform need to read our S3 buckets?” - “Limit the permissions to bare minimum for IAM JIT. If you only manage Identity Center assignments, you only need Identity Center permissions.”
- “Can we remove all non-read permissions except for Events and Right Sizing?”
These weren’t unreasonable requests. They were exactly what a security team should ask when granting cross-account role access to a third-party platform.
The Core Challenge
A security team that practices least privilege internally applied the same principle to their vendor: give Cloudanix only the permissions needed for JIT operations, nothing more. The default onboarding stack was designed for the full platform, creating a mismatch that required deliberate scoping.
Where the Gaps Were
Default Onboarding vs. Single-Feature Deployment
Cloudanix’s standard onboarding creates a role with:
- Read permissions across multiple AWS services (for CSPM: S3, EC2, IAM, RDS, Lambda, CloudTrail, etc.)
- Identity Center permissions (for JIT: managing user/group assignments to permission sets)
- EventBridge permissions (for real-time event processing)
For a full-platform customer, this is correct and minimal. For a JIT-only customer, the read permissions across S3, EC2, and other services are unnecessary — they enable CSPM scanning that this team didn’t want active.
The team’s position was clear: “If we’re not using CSPM, don’t have permissions to read our S3 buckets. If we’re not using workload protection, don’t have permissions to describe our EC2 instances. Give us the minimum for what we’re buying.”
Specific Objection: s3:Get* in ReadOnlyAccess
The security lead identified that the Cloudanix role included s3:Get* as part of a broader ReadOnlyAccess policy. Their concern:
- S3 buckets contain sensitive data (application data, logs, backups, configurations).
- A compromise of the Cloudanix role would expose S3 data that’s irrelevant to JIT operations.
- The principle of least privilege means: if the platform doesn’t need S3 access for JIT, it shouldn’t have S3 access.
This is a textbook application of defense in depth. Even if the probability of role compromise is low, the blast radius should be minimized to what’s necessary for the function the role serves.
Concern About Third-Party Permissions Generally
Beyond the specific S3 objection, the team had a broader philosophy:
- Every cross-account role is an attack surface.
- Vendor roles should be audited and scoped with the same rigor as internal service roles.
- “We trust your platform, but we verify your permissions.” The trust relationship should be provable through permission boundaries, not assumed through vendor reputation.
This philosophy is exactly right, and it’s one Cloudanix supports. The platform should work within the permissions the customer is comfortable granting — and the customer should grant only what’s needed.
The Cloudanix Resolution: JIT-Only Permission Scope
Cloudanix worked with the security team to strip the IAM role to JIT-only operations, conducted an impact analysis of removed permissions, and implemented deny statements for additional assurance.
Step 1: Impact Analysis
Before removing any permissions, Cloudanix provided an analysis of:
- Which permissions are required exclusively for JIT operations.
- Which permissions serve CSPM/CWPP/other features that the customer isn’t using.
- Which permissions are shared (needed by both JIT and CSPM, e.g., reading IAM configuration).
- What functionality breaks if specific permissions are removed.
This analysis gave the security team confidence that the removal wouldn’t break JIT functionality while confirming that removed permissions genuinely weren’t needed.
Step 2: Revised CloudFormation Template
The updated CloudFormation template retained only:
For JIT Cloud operations:
sso:*— Managing IAM Identity Center assignments (the core JIT operation).identitystore:*— Reading users, groups, and group memberships for JIT configuration.organizations:Describe*,organizations:List*— Understanding account structure for multi-account JIT.
For operational necessities:
events:*— EventBridge for real-time sync of Identity Center changes.- Specific
iam:read permissions for understanding role/policy structure (needed to display permission sets meaningfully in the JIT request interface).
Removed:
- All
s3:*permissions. - All
ec2:Describe*permissions. - All
rds:Describe*permissions. - All
lambda:*permissions. - All other service-level read permissions that serve CSPM but not JIT.
Step 3: Explicit Deny Statements
Beyond removing unnecessary permissions, the team wanted explicit deny statements as a defense-in-depth measure:
{
"Effect": "Deny",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketPolicy"
],
"Resource": "*"
}Deny statements are a belt-and-suspenders approach: even if the permission boundary is accidentally expanded in the future (through a policy update or inheritance), the explicit deny prevents the Cloudanix role from ever accessing S3 objects. The security lead was clear: “I don’t just want the absence of permission — I want the active denial of it.”
Cloudanix supported this approach. The JIT engine doesn’t need S3 access, so denying it doesn’t impact functionality. It does provide the security team with a provable guarantee about the role’s boundaries.
Step 4: Disabled CSPM Scanning
Since the permissions for CSPM scanning were removed, no security findings from cloud posture scanning would appear in the customer’s Cloudanix dashboard. The platform operates in JIT-only mode:
- JIT Cloud request/approve/revoke flow: fully functional.
- CSPM dashboard: empty (no permissions to scan, no findings generated).
- Asset inventory: limited to IAM-related resources (users, groups, permission sets, accounts).
The customer later evaluated CSPM findings after using JIT successfully for several weeks. At that point, they made an informed decision about whether to expand the Cloudanix role to include read permissions for posture assessment — but on their timeline, not as a requirement for JIT adoption.
Why This Matters: Vendor Permissions Are Your Attack Surface
Every cross-account role a team creates is an entry point that an attacker could potentially leverage. The probability is low with a reputable vendor, but the principle remains: blast radius should be proportional to function.
When a vendor says “you need to give us ReadOnlyAccess to your entire AWS account,” the question should always be: “ReadOnly access to what specifically, and why?”
If the answer is “we need to read S3 to scan for misconfigurations” and you’re only buying JIT, the correct response is: remove S3 access. If the answer is “we need IAM Identity Center access to manage assignments” and you’re buying JIT, that permission is appropriate and justified.
Cloudanix’s willingness to:
- Provide an impact analysis of removed permissions.
- Support a revised CloudFormation template with minimal scope.
- Accept explicit deny statements that restrict the platform role.
- Operate in JIT-only mode without requiring full-platform permissions.
…demonstrates that the platform is designed to work within customer-defined boundaries, not to require blanket access regardless of which features are deployed.
Platform Impact
| Metric | Default Onboarding | JIT-Only Scope |
|---|---|---|
| AWS services with read access | 40+ services | 5 services (SSO, Identity Store, Orgs, IAM, Events) |
| S3 access | s3:Get*, s3:List* | Explicitly denied |
| EC2/RDS/Lambda access | Full describe | None |
| Blast radius if role compromised | Broad read across all services | Limited to IAM/Identity Center metadata |
| CSPM findings generated | Yes | No (opt-in later if desired) |
| JIT functionality | Full | Full (no degradation) |
Running a JIT-Only Deployment?
If your security team practices least privilege for vendor roles — and you want JIT access without granting broad read permissions across your AWS environment — Cloudanix supports JIT-only scoped deployments with permission boundaries defined by your security team, not by a one-size-fits-all onboarding template.
Book a Free Assessment to discuss a JIT-only deployment with permissions scoped to your security team’s requirements.
