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 (Engineering ~100, DevOps ~10, Customer Success ~20) |
| Identity Provider | Google Workspace |
| IAM Model | AWS IAM Identity Center (DevOps), IAM Users (others) |
| Communication | Slack |
| Existing Automation | StackStorm for access provisioning, Jira for request workflow |
| Primary Interest | IAM JIT for Cloud, Databases, Kubernetes |
| Cloudanix Scope | Cloud Console JIT, Database JIT, Kubernetes JIT |
The Situation: Homegrown Automation That Worked — Until It Didn’t
This mid-stage AI SaaS company had done what resourceful DevOps teams do: they built their own access management system. Over time, the team assembled a workflow combining Jira for access requests, StackStorm for automated provisioning of read-only permissions in development environments, and manual intervention for everything else.
The system worked. For a while.
Engineers and Customer Success staff would raise a Jira ticket specifying the environment, purpose, and duration they needed. StackStorm automation would pick up tickets matching certain criteria (read-only permissions, development accounts) and provision access automatically. For anything elevated (write permissions, production accounts), a DevOps lead manually approved the request and assigned permissions by hand. A calendar reminder was set to revoke access later.
At ~150 users across 4 AWS accounts, the seams were showing. The DevOps lead who approved all requests had become a single point of failure. Calendar-based revocation was unreliable. Audit logs were scattered across Jira comments, StackStorm execution logs, and AWS CloudTrail — with no unified view of who had access to what, when, or why.
The team wasn’t looking to patch the existing system. They were looking to replace it entirely.
The Core Challenge
A homegrown access workflow built on StackStorm and Jira that served the team at 50 users was buckling at 150. The single-approver bottleneck, unreliable manual revocation, fragmented audit trails, and operational overhead of maintaining the automation itself had become the problem they were trying to solve.
Where the Gaps Were
StackStorm: Automation That Creates Its Own Maintenance Burden
StackStorm handled the “happy path” — read-only access to development environments for known request patterns. But it couldn’t handle the reality of how access actually works in a growing organisation:
- Rigid rule matching. Any request that didn’t fit the predefined StackStorm patterns fell through to manual handling. As the organisation grew and access patterns diversified, more requests missed automation and landed on the DevOps lead’s desk.
- No approval workflow. StackStorm executed actions based on ticket metadata. There was no human-in-the-loop approval for automated grants — it was either fully automated or fully manual, with no middle ground.
- Maintenance overhead. Every new AWS account, every new permission set, every new team or role required StackStorm rule updates. The automation itself became a project that competed for DevOps bandwidth.
- No revocation intelligence. StackStorm could provision access but had no built-in concept of time-bound grants or automatic revocation. That responsibility was offloaded to calendar reminders — which is to say, offloaded to hope.
Jira: The Wrong Tool for Access Governance
Jira is a project management tool pressed into service as an access request system. The friction was predictable:
- No structured approval routing. Approvals happened in Jira comments, not through a purpose-built workflow. There was no way to enforce that a specific person or role approved before access was granted.
- No integration with IAM. A Jira ticket marked “Done” didn’t automatically translate to an IAM action. Someone still had to read the ticket and execute the permission change manually (or configure StackStorm to match the ticket).
- Audit trail in the wrong place. Access decisions lived in Jira. Actual permission changes lived in CloudTrail. Correlating the two required manual effort — and was rarely done outside of incident investigations.
- No expiration enforcement. A Jira ticket has no concept of “this access expires in 4 hours.” Duration was a free-text field in the ticket description, enforced by nothing.
Calendar Reminders: The Last Line of Defence That Isn’t
The team’s revocation mechanism was a calendar reminder. This is worth stating plainly: the security control preventing standing privilege accumulation was a human remembering to check their calendar, navigate to the AWS console, find the correct user, and remove the correct permission assignment.
At 150 users making access requests across 4 accounts, calendar-based revocation means:
- Access that is granted for “4 hours” persists for days when the calendar reminder is missed, snoozed, or ignored during a busy week.
- Revocation that depends on the same person who granted access. If that person is on leave, the calendar event fires with no one to act on it.
- No verification that revocation actually happened. The calendar reminder is the end of the workflow — there’s no check that the permission was actually removed.
The Single-Approver Bottleneck
One DevOps lead approved all elevated access requests. This created:
- Latency. Engineers waiting hours for approval during the approver’s off-hours or busy periods. In a company with global operations, this meant blocked work.
- Burnout. The approver was spending meaningful time on repetitive access reviews that provided little security value for standard requests.
- Single point of failure. If the approver was unavailable (vacation, illness, meetings), the entire access workflow stalled. No delegation mechanism existed.
- No risk differentiation. Read-only access to a development account and admin access to production went through the same approval path, at the same speed, with the same human effort.
The Cloudanix Solution: One JIT Engine Replacing Four Systems
Cloudanix JIT replaced StackStorm, Jira-based requests, manual approvals, and calendar-based revocation with a single, unified Just-In-Time access engine integrated directly with AWS IAM Identity Center.
How It Works in This Environment
-
Engineer requests access directly from Slack — specifying the AWS account, permission set (role), and duration needed. No context switch to a ticketing system. No form fields that don’t map to IAM concepts.
-
Approval routes automatically based on the role and account sensitivity. Read-only access to development auto-approves per policy. Elevated permissions in production route to the designated approver(s) in Slack with one-click approve/reject buttons.
-
Cloudanix grants the permission set in AWS IAM Identity Center for the approved duration. The engineer sees the role appear in their AWS SSO portal within seconds — the same bookmark, the same SSO page they already use.
-
Access auto-revokes when the time window expires. No calendar reminder. No manual intervention. The permission set assignment is removed from Identity Center automatically.
-
Every step is audited — who requested, who approved, what was granted, when it was granted, when it was revoked, and what actions were taken during the session. One timeline, identity-stamped, exportable.
Replacing StackStorm’s Automation
StackStorm’s value was automating the “known good” patterns — read-only access to dev. Cloudanix replaces this with auto-approval policies that are:
- Configurable per role and account. Read-only access to development accounts can auto-approve for any engineer in the engineering group. No human intervention needed.
- Bounded by duration. Auto-approved access still has a hard time limit. The engineer gets access for the requested window (e.g., 2 hours), and it revokes automatically regardless.
- Audited identically to manual approvals. Whether access was auto-approved or human-approved, the audit trail is the same. Compliance teams see every grant with full context.
This isn’t StackStorm with a nicer UI. It’s a purpose-built access engine that understands IAM concepts natively — permission sets, accounts, groups, time bounds — without requiring DevOps to maintain automation rules for every access pattern.
Replacing Jira’s Request Workflow
Engineers no longer raise Jira tickets for access. The request happens where work happens — Slack. The benefits:
- Structured requests. The Slack command presents only valid options: accounts the engineer’s group has access to, permission sets configured for their team, and duration options within policy bounds.
- Instant routing. Approval notifications arrive in real time to the designated approver’s Slack channel — not buried in a Jira backlog.
- One-click decisions. Approvers see the request context (who, what, where, how long, why) and approve or reject with a single button click.
- Zero manual IAM work. Approval triggers automatic provisioning. No one needs to log into the AWS console to make permission changes.
Replacing Calendar-Based Revocation
This is the most meaningful change. Revocation is no longer a human responsibility:
- Hard time limits. Every access grant has a maximum duration set at the policy level. Even if the engineer requests 8 hours, the policy may cap it at 4.
- Automatic enforcement. When the window expires, Cloudanix removes the permission set assignment from AWS IAM Identity Center. The engineer’s next SSO page refresh shows the role is gone.
- Early revocation. Approvers can revoke access before the window expires if needed. Engineers can also release access early when they’re done.
- No forgotten grants. There is no scenario where access persists because someone missed a calendar event. The system enforces revocation whether the granter is awake, on vacation, or no longer at the company.
Integration with Existing Identity Architecture
The team uses Google Workspace as their Identity Provider, with AWS IAM Identity Center for the DevOps team. Cloudanix operates as an access governance layer on top of this existing architecture:
- Google SSO for authenticating into Cloudanix itself — no new credentials for users to manage.
- AWS IAM Identity Center as the target. Cloudanix reads groups, users, and permission sets from Identity Center and manages temporary assignments. It doesn’t replace Identity Center; it governs when and for how long assignments exist.
- Group-based access policies. The engineering group sees engineering-appropriate roles. The DevOps group sees elevated roles. The Customer Success team sees their scoped set. Policies map to existing group structures.
Platform Impact
| Metric | Before | After |
|---|---|---|
| Access request to grant | 15 min – 4 hours | Under 60 seconds |
| Revocation mechanism | Calendar reminders | Automatic, policy-enforced |
| Audit trail | Jira + CloudTrail + StackStorm logs | Single unified timeline |
| Approver bottleneck | 1 person | Multiple approvers + auto-approval |
| Standing privilege | Persistent until manually revoked | Zero — time-bound only |
| Maintenance overhead | StackStorm rules + Jira workflows | Zero DevOps maintenance |
Why the Homegrown System Hit a Ceiling
The team’s original workflow wasn’t poorly designed. It was designed for a smaller team. At 30 users, a Jira ticket and a manual IAM change is fine. At 50, StackStorm automation makes it sustainable. At 150 users across 4 accounts with production workloads generating $500K/month in cloud spend, the system needs to be purpose-built for access governance — not assembled from project management tools and general-purpose automation frameworks.
The ceiling isn’t complexity. It’s that Jira doesn’t understand IAM, StackStorm doesn’t understand time-bound access, calendar reminders don’t understand enforcement, and none of them produce a unified audit trail that satisfies compliance requirements.
Cloudanix JIT is built for exactly this problem. One engine that handles the request, the approval, the provisioning, the time-bounding, the revocation, and the audit — without requiring DevOps to build and maintain the glue between five different systems.
Running a Similar Setup?
If your team is managing cloud access through Jira tickets, homegrown automation (StackStorm, Rundeck, custom scripts), or manual IAM changes with calendar-based revocation — and you’re feeling the operational weight of that approach as your team grows — Cloudanix JIT replaces the entire stack with a single, audited, time-bound access engine that integrates with your existing Identity Center and SSO.
Book a Free Assessment to see how JIT access works with your AWS Identity Center setup in under 30 minutes.
Related Resources
- PAM for Credential Management, Password Rotation, and More in the Cloud
- Still Manually Granting Cloud Access? Here’s Why Your Security & Productivity Are Suffering
- Implementing JIT Access in AWS, Azure & GCP: Complete Guide for Security Leaders
- The End of Permanent Access: Just-In-Time Granular Database Security
- Mastering Third-Party Access with a Just-in-Time Approach
