Just-in-Time Access for AWS at Rippling
![[Blog – Hero Image] Identity management](http://images.ctfassets.net/k0itp0ir7ty4/5Hsu8HkmyPFWqWKMcgpz2z/d9c5dad0dae54b424f8977ee85388ae4/Header_Identity_Management_Software_02.jpg)
In this article
- 01. Background
- 09. Conclusion
For Senior Security Engineer Arta Razavi, figuring out how to manage who could access what in AWS became challenging — especially as Rippling scaled. Arta and her team decided they needed to build something better from scratch. Join Arta as she shares the story behind creating Just-In-Time Access (JITA) and how it's made getting secure, temporary AWS access at Rippling a breeze.
Background
At Rippling, our guiding principle is to “free smart people to work on hard problems.” In our technical organization, we put this into practice by empowering engineers to fully leverage AWS to build products and services for our customers. However, as the company grew and the number of teams and services expanded, managing individual access to AWS for tasks like debugging and one-off API calls became increasingly challenging. Initially, access was managed exclusively by the security and infrastructure teams, who did their best to configure permissions for other teams. But with limited insight into each team's specific needs, access policies were often broad and over-provisioned. As a result, engineers frequently had more permissions than necessary, leading to unnecessary security risks and inefficiencies.
As the complexity of our environment increased, we initially turned to the open-source version of Common Fate’s just-in-time access tool to bring more control and flexibility. Common Fate was instrumental in our early days, demonstrating the value of Just-In-Time access and establishing it as a critical part of our access strategy. However, as our environment scaled and our requirements became more specialized, the tool could no longer fully meet our needs. With the announcement of its end of life, we recognized the need for a more robust, custom solution that could support our growing demands.
Problem: Challenges with existing access management tools
With the end-of-life (EOL) of Common Fate’s tool, we began exploring off-the-shelf replacement solutions, including cloudanix, jit.io, and Tenable JIT. However, each of these had significant limitations that made them unsuitable for our needs. As we evaluated these options, we identified three key challenges that reinforced the need for a better approach:
Scalability issues: As our environment grew with numerous teams, each having unique access requirements, managing this complexity became increasingly challenging. This made it difficult for teams to get the access they needed without waiting, causing delays and blocking critical workflows.
Lack of democratization: Many of the tools we evaluated required admin access to manage and update access rules. This lack of democratization meant that only a select few had the authority to make changes, which slowed down the process and created bottlenecks. As a result, teams were often dependent on security or engineering to make changes, which added unnecessary delays to their work and added unnecessary operational load on the security team.
Difficulty auditing activities: While CloudTrail logs allowed us to track the actions users took during their access sessions, they didn’t provide insight into the reason for the access or why the request was made. Connecting the reason for access with the activities performed required manual reconciliation, which was time-consuming and error-prone. This gap made it difficult to ensure compliance, enforce security policies, and hold users accountable.
Solution: Just-In-Time-Access (JITA)
Given the problems with existing solutions listed above, we decided to build our own just-in-time access tool in-house. This tool, called Just-In-Time-Access (JITA), is a Python service with Slack as the user interface. It allows engineers to easily request and receive secure, temporary AWS access to critical resources only when needed. By granting elevated access for a limited time, JITA minimizes the risk of unauthorized access and enhances overall security.
Key features of JITA
Slack-based app: JITA’s Slack-based interface makes it easier for users to request and approve access quickly, leveraging a platform familiar to everyone for seamless interaction.
Scalable: JITA can handle a high volume of complex access requests while scaling efficiently. Currently, JITA processes over 500 requests per month across 80 teams, each managing their own unique access needs.
Maintained in code: Access rules in JITA are maintained in code, making it easy to track changes and roll back when needed. This approach not only increases the transparency of access management but also improves the overall security posture by enabling version control and automated checks.
Democratized access & self-service: JITA empowers teams to take ownership of their access requirements by allowing them to manage their own access rules. Teams have the most context about their own needs, which means they can make the most informed decisions about their own access rules. Users also have the ability to check their own access via GitHub, where they can easily see which resources and permissions they have access to, ensuring they are never in the dark about their access. This self-service capability removes the reliance on infra or security teams to verify or provide information about their access, allowing users to independently validate and, when necessary, update their access.
Reduced operational work: By allowing teams to manage their own access, JITA reduces the operational overhead for the security team. Security is only required to approve changes, significantly reducing manual intervention and enabling security engineers to focus on higher-impact work.
LLM summaries keep users honest: After a user has utilized their JIT session, an LLM-generated summary of their activities is produced. This feature helps maintain accountability by comparing the user’s access justification with their CloudTrail activities, ensuring the stated reason for access aligns with the actions taken.
Integration with Rippling: One of the unique aspects of JITA is its integration with Rippling’s user and group management system. This integration allows us to automate access control based on employee groupings and roles, making the management of permissions more efficient and aligned with Rippling's broader HR and organizational structure. In the future, this integration could expand further, becoming an even more formalized part of the Rippling product suite, maybe even potentially a future blog post.
Access to EKS clusters: JITA also extends its functionality to manage access to our AWS EKS clusters, providing engineers with secure, time-limited access to Kubernetes resources. This ensures that critical infrastructure access is handled with the same level of security and oversight as AWS resources.
Integrating IAM Identity Center with Rippling
JITA is built on top of our integration between Rippling and AWS IAM Identity Center.
At Rippling, we’ve configured Rippling as the identity provider (IdP) for IAM Identity Center, using SAML for authentication and SCIM for user and group provisioning. This setup makes Rippling the single source of truth for identity across our AWS accounts.
Rippling’s Apps team built an app that integrates with IAM Identity Center using SCIM, which is available in the Rippling App Shop. Once installed, we used Smart Rules to define which employees should be provisioned into which IAM Identity Center groups — using attributes like team, department, level, tenure, direct reports, or other custom fields from the Rippling employee graph.
This lets us:
Automatically create users and assign them to the correct IAM Identity Center groups when they are onboarded
Instantly deprovision users when someone leaves or changes roles
Keep user and group state aligned with org changes
The best part? This whole setup uses the same APIs and App Shop available to any Rippling customer. If you're an IT or engineering team already using Rippling, you can build tools like JITA too.
For more detailed information on how we set up AWS IAM Identity Center at Rippling, check out this blog post by my teammate Shreyas: Streamlining AWS access with Rippling at scale — Integrating IAM Identity Center and Just-In-Time access
Technical deep dive
Below, you’ll find the sequence diagram for JITA. In the sections that follow, we’ll explore each component in detail.
JITA code + access rules
Setting up Just-In-Time Access begins in the JITA code repository, where both the JITA code and access rules are maintained. This self-serve process empowers engineers to define access for their teams by writing YAML-based access rules.
YAML-based access rules
JITA access rules come from YAML files that specify the following properties:
Name: The name of the JIT access rule
Description: Description of what the access rule is used for
Request groups: IAM identity center group users that can request this access
Organizational units: The accounts within these organization units are able to be requested
AWS accounts: The accounts that are able to be requested
Permission sets: The permission sets that are able to be requested
Max duration: The amount of time you are able to request access for
Approver groups: IAM identity center group users that can approve this access request
Approver individuals: Users that can approve this access request
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
name: "JIT-Security-Infra-Prod-Administrator-Access"
description: |
This rule grants temporary access to the Administrator permission set.
request_groups:
- "Security-Infra"
organizational_units:
- "OU_1"
aws_accounts:
- "account_1"
permission_sets:
- "JITA-AdministratorAccess"
max_duration: 400
approver_groups:
- "Security-Infra"
approvers_individuals:
- "user@email.com"With these YAML rules, teams can independently manage and maintain their access configurations, reducing reliance on infrastructure or security teams.
User interface inside of Slack
Once the access rules are set up, the next step is requesting and managing access through JITA's Slack-based interface. This integration provides a seamless and intuitive user experience. Within Slack, users can:
Request access: Submit requests for temporary access to AWS resources.
Approve requests: Approvers can review, approve, or deny access requests.
Monitor sessions: View a live feed of active and expired JITA sessions, enabling real-time tracking of access.
By using Slack as the interface, JITA simplifies the process of managing access requests, allowing teams to interact with the system efficiently and monitor access in real-time—all without leaving Slack.
Slackbot backend inside AWS ECS
Now that you’ve seen how to define access rules and manage requests through Slack, let’s dive into what happens in the backend when a user requests access.
JITA’s Slackbot backend operates as a scalable service on AWS ECS (Elastic Container Service), orchestrating just-in-time access requests and approvals while seamlessly bridging Slack with AWS IAM Identity Center. Here’s how the process works:
Access rule filtering
When a user requests access, the Slackbot backend checks with AWS IAM Identity Center to determine the user’s IAM Identity Center group membership. Based on the user’s group membership, the backend filters which access rules the user is eligible to request. The filtered list of access rules is sent back to the Slack interface, showing only the options the user is authorized to request.
Access provisioning
Once the user requests access, the backend communicates with AWS IAM Identity Center to provision access by creating an account assignment for the user. Access duration is managed by AWS EventBridge, which triggers an AWS Lambda function to revoke access when the requested time expires.
Maintaining a just-in-time access audit trail
JITA’s Slackbot also maintains a dedicated Just-In-Time Access Audit Channel in Slack. This channel provides a real-time log of:
Access Requests: Records of all access requests made through JITA.
Active Sessions: Details of currently active sessions, including user information and access specifics.
Expired Sessions: Notifications and logs of expired sessions, documenting when access is revoked.
This audit trail serves as a transparent record of just-in-time access activities, helping teams monitor access usage.
Shared data inside AWS S3 and DynamoDB
To function as a distributed system, JITA relies on multiple AWS services to manage access, state, and coordination:
GitHub manages the access rules in code.
AWS ECS powers the Slackbot backend, acting as the interface for users and provisioning access.
AWS EventBridge handles schedules, triggering Lambda functions to revoke access when sessions expire.
Slack provides an audit trail of sessions, access requests, and expiration notifications.
Each of these components must share state seamlessly to ensure the application operates as a cohesive distributed system.
AWS S3 access rules bucket
To ensure that JITA always uses the most up-to-date access rules, the repository pushes access rules to an S3 bucket. When a user requests access, the Slackbot reads from this bucket, enabling real-time updates to the rules while allowing rules to be version-controlled in code.
AWS DynamoDB Slack state
Managing the Slack UI elements and interactions requires a stateful approach. JITA uses DynamoDB to keep track of:
Audit messages: Mapping which Slack audit message corresponds to which session, ensuring accurate updates for approvals, revocations, and expirations.
Approval and revoke buttons: Tracking the status of approval and revoke buttons associated with each request. Once a request is approved, the corresponding approval button is removed to prevent duplicate actions. Similarly, revoke buttons are removed when access expires, ensuring users cannot revoke access that has already been automatically revoked.
This shared state in DynamoDB allows the distributed components of JITA to coordinate seamlessly, ensuring accurate UI updates, reliable access provisioning, and consistent audit trails.
Access management via AWS IAM Identity Center
JITA operates based on user groups managed by IAM Identity Center. These groups determine which users are authorized to request access and which users are permitted to approve access.
At Rippling, we’ve integrated IAM Identity Center with the Rippling App, allowing group memberships to be managed dynamically via SCIM. Once the integration is set up and users and groups are provisioned, JITA interacts with IAM Identity Center to resolve access context in real time.
What is the AWS Identity Store?
The AWS Identity Store is the underlying identity directory for IAM Identity Center. It holds all user and group metadata and powers all group-based access decisions in IAM Identity Center. Using theIdentity Store API, you can programmatically fetch user IDs, group memberships, and group member lists.
Fetching a user’s group membership
To determine what groups a user belongs to], JITA first resolves the user ID from their email, then lists their group memberships:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Resolve the AWS user ID from their email
user_id = client.get_user_id(
IdentityStoreId="IDENTITY_STORE_ID",
AlternateIdentifier={
"UniqueAttribute": {
"AttributePath": "userName",
"AttributeValue": user_email,
}
}
)["UserId"]
# List all group memberships for that user
response = client.list_group_memberships_for_member(
IdentityStoreId=os.getenv("IDENTITY_STORE_ID"),
MemberId={"UserId": user_id},
)
group_ids = [m["GroupId"] for m in response["GroupMemberships"]]
# Optionally, resolve group IDs to display names
group_names = [
client.describe_group(
IdentityStoreId="IDENTITY_STORE_ID",
GroupId=group_id
)["DisplayName"]
for group_id in group_ids
]Fetching group members
To determine who is in a specific IAM Identity Center group, JITA fetches the group ID from its name, then resolves its members:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Resolve the group ID from its display name
group_id = client.get_group_id(
IdentityStoreId="IDENTITY_STORE_ID",
AlternateIdentifier={
"UniqueAttribute": {
"AttributePath": "displayName",
"AttributeValue": group_name,
}
}
)["GroupId"]
# List members of the group
response = client.(
IdentityStoreId="IDENTITY_STORE_ID",
GroupId=group_id,
)
member_ids = [m["MemberId"]["UserId"] for m in response["GroupMemberships"]]
# Optionally, resolve member emails from user IDs
emails = [
client.describe_user(IdentityStoreId="IDENTITY_STORE_ID", UserId=uid)["UserName"]
for uid in member_ids
]Provisioning and de-provisioning access with AWS SSO admin
AWS SSO Admin (part of the IAM Identity Center API suite) is the service we use programmatically to manage user access to AWS accounts and services. It allows us to provision and de-provision access dynamically in response to JITA requests.
What is AWS SSO admin?
AWS SSO Admin is the administrative interface for IAM Identity Center. While IAM Identity Center provides the central management of user permissions and single sign-on capabilities, AWS SSO Admin exposes programmatic methods to manage these permissions through APIs.
AWS SSO admin provision access
When a user requests access through JITA, the backend provisions access using the AWS SSO Admin API. Specifically, we call the CreateAccountAssignment method, which assigns access to a user (or group) for a specified AWS account using a specified permission set.
Here’s an example of how this works:
1
2
3
4
5
6
7
8
client.create_account_assignment(
InstanceArn='SSO_INSTANCE_ARN',
PermissionSetArn='permission_set_arn',
PrincipalId='user_principal_id',
PrincipalType='USER',
TargetId='account_id',
TargetType='AWS_ACCOUNT'
)
AWS SSO admin de-provision access
Similarly, when a user’s access duration expires, or if access is manually revoked, we use the DeleteAccountAssignment method from AWS SSO Admin to remove the access.
Here’s an example of how this works:
1
2
3
4
5
6
7
8
client.delete_account_assignment(
InstanceArn='SSO_INSTANCE_ARN',
PermissionSetArn='permission_set_arn',
PrincipalId='user_principal_id',
PrincipalType='USER',
TargetId='account_id',
TargetType='AWS_ACCOUNT'
)
Scheduled tasks via AWS EventBridge
When a user requests access in JITA, they specify the duration for which they need access. JITA uses this duration to create corresponding AWS EventBridge events. Upon the initiation of an access session, two key events are scheduled:
Revoke user access: This event ensures that the user's access is automatically revoked when the granted time expires.
Generate LLM summary: This event triggers the creation of an LLM-generated summary, providing insights into the user’s activities during their access session.
When these scheduled events are triggered, they invoke a Lambda function. This function handles either revoking the user’s access or generating the LLM summary, ensuring that all actions are performed in a timely and automated manner.
Here’s an example of how this works:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
client.create_schedule(
FlexibleTimeWindow={'Mode': 'OFF'},
Name='schedule_name',
GroupName='REVOKE_SCHEDULE_GROUP_NAME',
ScheduleExpression= '2024-07-16T12:05:00Z',
State="ENABLED",
Target=scheduler_type_defs.TargetTypeDef(
Arn='REVOKER_FUNCTION_ARN',
RoleArn='JIT_EVENTBRIDGE_ROLE_ARN',
Input=json.dumps(
{
'action': 'event_bridge_revoke' | 'llm_summary',
'revoke_event': revoke_event.json | summary_event.json,
},
),
),
)
Revoke access + generate LLM summary via AWS Lambda
As mentioned earlier, JITA uses AWS EventBridge to create schedules for revoking access and generating LLM summaries. When these schedules trigger, they invoke AWS Lambda functions designed to handle these tasks:
Revoke access:
The Lambda function removes user access from the specified AWS resources once the scheduled time has elapsed, ensuring that temporary permissions are promptly revoked.
Generate LLM summary:
Another Lambda function generates a summary of the user's activities during their access session. This summary helps verify that the user’s actions align with their stated reasons for access.
Highlight feature: LLM-generated summaries
One of the key features of JITA is the integration of LLM-generated summaries to help keep users honest about actions they took while they had access. By leveraging advanced language models, JITA ensures that users' actions during their access period are compared and verified against their initial justification for access.
Querying CloudTrail logs in Snowflake
To audit the actions taken by a user during their AWS access period, we examine the CloudTrail logs. At Rippling, we collect all our CloudTrail logs within Snowflake and use it to manage our Security Information and Event Management (SIEM) system.
To understand more about how we’ve set up our Snowflake SIEM here at Rippling, I recommend reading my coworker's detailed blog: Engineering a SIEM part 1: Why did we need to build our own SIEM?.
The following code snippet illustrates how we execute a SQL query within our SIEM system to retrieve the relevant CloudTrail logs:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SELECT
eventname,
sourceipaddress,
REGEXP_SUBSTR(useridentity:arn,'assumed-role/AWSReservedSSO_{permission_set}_[a-zA-Z0-9]+/([^/]+)',1,1,'e') AS username,
count(*) as event_count
FROM
AWS_CLOUDTRAIL_LOGS_VIEW
WHERE
recipientaccountid = '{account_id}'
AND useridentity:arn REGEXP 'arn:aws:sts::{account_id}:assumed-role/AWSReservedSSO_{permission_set}_[a-zA-Z0-9]+/{user_email}'
AND event_time BETWEEN '{starttime}' AND '{endtime}'
AND errorcode IS NULL
AND NOT sourceipaddress ilike any ('%amazonaws%', 'AWS Internal')
GROUP BY
eventname,
sourceipaddress,
username
ORDER BY
eventname,
sourceipaddress;The SQL query retrieves CloudTrail logs to audit user activities during their AWS access period. It filters logs based on the account ID and the specific role assumed by the user, focusing on actions within the exact timeframe of their access. The query extracts key details such as event names and source IP addresses, counts the occurrences of each event, and excludes internal AWS IPs to ensure only relevant user actions are analyzed.
Generating and comparing LLM summaries
Once we have retrieved the user's activity logs, we utilize OpenAI's API to generate a structured summary. This summary is then compared against the user's initial justification for accessing the AWS resources. The goal is to ensure that the actions taken align with the stated purpose of access, and to flag any discrepancies for further review.
Here’s the Python code that generates the LLM summary:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
def generate_summary(user_email, query_results, justification):
opena_api_key = SecretsManager().get_openai_tokens()
if opena_api_key is None:
logger.error("Failed to get openai creds")
return None
# Define the parameters for the API request
client = OpenAI(api_key=opena_api_key)
model_engine = "gpt-4o-2024-08-06"
# Prepare a detailed prompt for the AI model
prompt = f"""
Goal:
Analyze the following AWS CloudTrail log entries for a user {user_email} who was granted Just-In-Time (JIT) access to AWS resources.
Summarize the types of actions performed, the source IP addresses involved, and identify any significant patterns or exceptions.
User's stated justification:
Compare these activities against the user's stated justification for requesting JIT access.
justification: "{justification}".
Evaluate whether the actions align with their stated purpose.
Rules:
- Ignore login/auth/session-setup events such as ConsoleLogin, Federation, SSO, STS calls like GetCallerIdentity and GetSessionToken, ListAliases, and UseAliases.
- Focus on meaningful user activity after login.
- Only report IPs tied to those actions do not report AWS internal IPs or login activity.
Format:
Provide a structured summary that EXACTLY matches the following format:
Overview: <what they did, a few words of explanation>
IPs we saw: <comma-separated IPs tied to meaningful actions only (do not include IPs from: AWS internal & login activity)>
Alignment: <does it align with justification + a few words of explanation>
Discrepancy: <any discrepancies noted, or "none", with a few words of explanation>
length requirements:
Summary must be short and concise. It must not exceed 300 characters.
Note:
If no log entries are present, indicate that no actions were recorded during the JIT access period.
Log Entries:
{query_results}
Summary:
"""
# Make the API request with the prompt
response = client.chat.completions.create(
model=model_engine,
messages=[
{"role": "system", "content": prompt},
{"role": "user", "content": "Summarize the text above."},
],
)
# Extract the summary from the API response
summary = response.choices[0].message.content
return summaryBy integrating LLM-generated summaries into our JITA workflow, we’ve created a system that not only automates access management but also enhances security by holding users accountable for their actions. Additionally, this feature is cost-effective—each API call to generate a summary is relatively inexpensive, especially compared to the operational overhead of manual auditing. This makes it a scalable and efficient way to reinforce security protocols in dynamic cloud environments.
Metrics and feedback loop
As part of our continuous improvement process for Just-In-Time Access (JITA), we implemented a metrics system to track and analyze how teams interact with the tool. These metrics help us identify patterns, assess the effectiveness of access rules, and make informed decisions to improve the system.
Access request trends
: We monitor the total number of access requests over time to identify peak usage periods. This helps us evaluate overall demand and predict potential scalability challenges.
Team-specific usage patterns
: By tracking which teams submit the highest number of requests, we can pinpoint areas where teams may need additional or more granular access rules. This data helps optimize access management and reduce dependency on JITA.
Admin and over-permissive permissions utilization:
We track teams that rely heavily on admin access or over-permissive permissions, such as those with wildcard (*) access. Frequent usage of these broad permissions indicates gaps in access control and highlights areas where more granular, tailored access policies are needed to improve security and reduce reliance on overly permissive permissions.
Conclusion
JITA is a significant advancement in how we manage and monitor temporary access to critical AWS resources. By seamlessly integrating with Slack and leveraging the powerful capabilities of OpenAI’s LLMs, JITA not only handles access requests and approvals but also enhances accountability through user activity audits.
Beyond security and automation, one of the biggest wins has been the improved user experience. Engineers find JITA much more intuitive and efficient compared to our previous system. The seamless Slack integration makes requesting access feel frictionless, eliminating the need to navigate complex IAM policies or submit manual tickets. By streamlining the process, JITA empowers teams to get the access they need quickly while maintaining strong security controls. The feedback has been overwhelmingly positive—many users, myself included, prefer this system over the old one due to its ease of use and responsiveness.
At Rippling, we are committed to driving innovation in infrastructure security and access management. JITA exemplifies our dedication to improving operational efficiency while maintaining the highest standards of security. As we continue to refine and expand JITA’s capabilities, we hope to inspire others in the industry to explore and build upon these advancements.
One thing we would change if we could build this system again is prioritizing backend scalability. A distributed task processing system with multiple workers would have been a valuable improvement to handle high user volumes effectively and ensure reliability during peak usage. We’re actively working on implementing this improvement.
Thank you for joining us on this journey through JITA. For those looking to implement similar solutions or gain further insights into our security practices, we invite you to explore the resources and links provided throughout this blog or check out the other blogs available from Rippling.
And if you’re excited about building systems like this—Rippling Security is hiring!
Disclaimer
Rippling and its affiliates do not provide tax, accounting, or legal advice. This material has been prepared for informational purposes only, and is not intended to provide, and should not be relied on for tax, legal, or accounting advice. You should consult your own tax, legal, and accounting advisors before engaging in any related activities or transactions.
The Rippling Corporate Card is issued by Fifth Third Bank, N.A. Member FDIC, and Celtic Bank, Member FDIC, pursuant to a license from Visa® U.S.A. Inc. Visa is a trademark owned by Visa International Service Association and used under license. All trademarks are the property of their respective owners.
Hubs
Author
Arta Razavi
Senior Security Engineer
Arta Razavi is a Senior Security Engineer at Rippling, building products that drive innovation in infrastructure security and access management.
Explore more
How Rippling runs IT: Streamlining AWS access
Learn how to leverage the power of Rippling and AWS IAM Identity Center to supercharge developer productivity and bolster security.
Streamlining AWS access with Rippling at scale — Integrating IAM Identity Center and Just-In-Time access
Here's how we've leveraged the power of Rippling and AWS IAM Identity Center to supercharge our developers' productivity and bolster our security stance.
Engineering a SIEM part 3: Creating cost-effective, scalable detections
Streamlining the alert and detection flow of Security Information and Event Management system.
Rippling grants access and permissions “Just-In-Time” in a zero trust environment
Rippling’s IT team designed a custom app that ensured access requests happen directly in Rippling, saving hours per week
Must-have Identity & Access Management (IAM) RFP template in 2025
Learn how to evaluate top Identity & Access Management (IAM) solutions like Rippling and which criteria to include in your RFP.
Automate the boring parts of IT with Rippling
Learn how to automate IT onboarding, device management, and app access with Rippling.
10 Lessons: Containerizing our Django Backend
Discover 10 key lessons learned from containerizing Rippling's Django backend to enhance scalability and performance.
How Rippling used Spot instances to save and scale CI/CD
As of mid 2023, Rippling has 650 engineers pushing hundreds of pull requests every day. Learn how we used Spot Instances to save on infrastructure costs.
See Rippling in action
Increase savings, automate busy work, and make better decisions by managing HR, IT, and Finance in one place.