Simplifying Just-in-Time Access Governance using Cedar

In a modern and secure cloud environment, just-in-time access is the pinnacle of best practice security and governance. By only provisioning access when it’s required, you limit the blast radius of any access granted, while still enabling your developers and engineers to build and maintain your systems productively.

Doing this at scale can be challenging, and the downsides of getting something wrong are scary, so building a solution with the right tools is critical to success.

This post will show the benefits of using Cedar to control your access management, as used by Common Fate.

Cedar policy language

Cedar is an open source language developed by AWS, made specifically for writing policies to secure your applications. It’s similarities to the AWS IAM policy syntax are easy to see, and the academic paper behind it is as extensive as you would expect from any piece of research. The project has extensive documentation and supporting resources.

Just-in-time access with Common Fate

Common Fate is an authorization engine for just-in-time cloud access management. Principals (aka. users) can make requests for grants that allow time-bound access to entitlements, like AWS accounts, GCP projects, and more. Grants can be requested, approved, closed, or activated (once approved).

Allow access requests

The first, and most important permission statement is to allow principals to make a request for access, which all principals can do with the following policy:

@advice("Anyone can request access")
permit (
    principal,
    action == Access::Action::"Request",
    resource
);

This statement allows all principals to use the Access::Action::"Request" action on all resources, which in the context of Common Fate is a Grant: time-based access to an entitlement, such as an AWS account or GCP project (among others).

The @advice syntax allows us to annotate our policy statements, and has no effect on evaluation. In Common Fate, the annotation is showing in the interface alongside the impact for clarity and to explain intent:

Enforce governance

With a request in progress, we now want to ensure that only the right users (aka. principals) can approve the access. Specifically, we want to prevent principals from approving their own requests:

@advice("You cannot approve your own access request")
forbid (
    principal,
    action == Access::Action::"Approve",
    resource
)
when { principal == resource.principal };

As with other statements, the resource is a grant, and by checking the resource’s principal (that is, the principal that created the grant), we can forbid them from taking the “Approve” action.

Manage requests

Preventing principals from approving their own requests doesn’t mean they can’t do anything to their requested grants. It’s perfectly reasonable for them to close their own requests that they no longer need:

@advice("You can close your own access request")
permit (
    principal,
    action == Access::Action::"Close",
    resource
)
when { principal == resource.principal };

Using the same when clause as the previous statement, we can give principals control over their own access requests, but not other principals.

Centralize request management

Even if principals can’t approve their own access request, someone has to be able to! This statement allows a specific group of principals to approve or close (reject) a request for access:

@advice("The security team can approve or close access requests")
permit (
    principal in Entra::Group::"ID_OF_SECURITY_GROUP",
    action in [ Access::Action::"Approve", Access::Action::"Close" ],
    resource
);

Common Fate integrates with identity providers like Microsoft Entra, so this particular statement relies on a specific ID for the Entra group of the security team to ensure that only the right principals can perform critical actions.

Access management made easy

Access request approvals are also a good example of the flexibility of Cedar. Who can or should approve specific requests varies greatly between different organizations, but Cedar can be used to define them explicitly and concisely.

Policy-as-code

Another benefit of Cedar is it allows you to adopt authorization-as-code. As a technology team, you already have great governance controls around source code - your software development lifecycle! Using Cedar means that you can reuse these same processes that you already have, and use existing tools like GitHub for policy review.

We provide a Validate Cedar Policies GitHub Action in the GitHub Marketplace that can be used in your own projects, as well as with Common Fate.

By using a purpose-built language with an established pedigree, common footgun scenarios are completely mitigated, and access management is streamlined without sacrificing speed or security. The clarity and customizability that Cedar provides means that policies can be verified by security teams without resorting to custom code solutions that increase complexity and maintenance cost.

Want to know more? Get a demo of the Common Fate platform.