DEV Community

Cover image for From Permanent Access to Just-in-Time: A Startup's IAM Journey Part 2
Caesar Chan
Caesar Chan

Posted on

From Permanent Access to Just-in-Time: A Startup's IAM Journey Part 2

#security #aws #identity #azure

This is the second post in our 3-part series on implementing Just-in-Time access. In case you missed it, you can find Part 1 here.

In Part 1, we outlined the significant security risks of our "always-on" access model and introduced the blueprint for our new JIT architecture using AWS and Entra ID.

The Implementation

Now, let's dive into the step-by-step plan we followed to bring this architecture to life.

Architecture

Phase 1: Design and AWS Configuration

This phase was about laying the groundwork within our AWS Organization.

First, we held workshops to discuss and agree upon the new AWS IAM Groups and Roles needed for different teams (e.g., Infra, Dev, Product). This ensured the new structure met business needs.

We then built the core components in AWS.

  • In our AWS Management Account, we created new IAM Identity Center Permission Sets at the organization level, which define the granular permissions for each job function.

  • In our AWS Landing Account, we created new IAM Policies specifically designed to allow users to switch roles into the production and non-production accounts.

Sample Landing Account Switch Role Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::111111111111:role/InfraRole",
                "arn:aws:iam::222222222222:role/InfraRole",
                "arn:aws:iam::333333333333:role/InfraRole"
            ]
        },
        {
            "Effect": "Deny",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::111111111111:role/SecurityRole",
                "arn:aws:iam::222222222222:role/SecurityRole",
                "arn:aws:iam::333333333333:role/SecurityRole"
            ]
        }
    ]
}
Enter fullscreen mode Exit fullscreen mode
  • Finally in our AWS member accounts, we created the new target IAM Roles that users would ultimately assume to do their work, e.g. arn:aws:iam::111111111111:role/InfraRole.

Phase 2: Entra ID Integration and Configuration

With AWS ready, we connected our identity provider (IdP).

  • We set up the federation by connecting Entra ID SSO with IAM Identity Center. This allows AWS to trust Entra ID for user authentication.

  • Next, we mapped our Entra ID Groups with the IAM Identity Center Groups to ensure that a user in a specific Entra ID group (e.g., "Infra Team Production") would be associated with the correct permissions in AWS.

  • A crucial step was to configure Entra ID PIM on the production access groups, enabling the JIT request and approval workflow.

  • We also had to revamp our Conditional Access rules in Entra ID to enforce stronger authentication requirements (e.g. phish-resistant MFA, MDM compliance) when users access AWS production.

Phase 3: User Migration and Go-Live

This was our phased roll-out to users.

  • We started by assigning a few pilot users to the new groups for testing, allowing us to iron out any kinks in the workflow.
  • Pilot users will test out the entire self-service access request flow.

  • Once the pilot was successful, we proceeded to reassign all other users to the new groups according to their job function.

Phase 4: Cleanup and Hardening

The final and most important phase was to remove the old, insecure configurations.

Cleanup

  • We enabled IAM Access Analyzer in our organization management account to begin monitoring for overly permissive or unused access.
  • We began a process of removing obsolete IAM Policies, Accounts, Groups, and Roles.
  • Critically, we removed all permanent, long-lived CLI access keys used by employees, forcing all CLI access through the new temporary credential model.

Hardening

  • Finally, we performed a security review to lock down all IAM role trust policies, ensuring they could only be assumed by the specific IAM Identity Center roles, as detailed in the final part of the series.

With the 4 phases of our implementation covered, the technical foundation is now in place. However, the journey doesn't end with deployment. In the final part of our series, we'll zoom in on a security policy fix we discovered and share the lessons we learned about balancing security with developer productivity.

Top comments (0)