At Common Fate we're big fans of authorization-as-code. Treating your authorization policies as source code means you can test and review changes using your existing tools like Terraform and GitHub. We use Cedar as the authorization-as-code framework in our product.

Here's an example Cedar policy you might write:

@advice("You can request access because you're currently on-call.")
permit (
  principal in PagerDuty::OnCall::"PDXYZ123",
  action == Access::Action::"Request",
  resource is AWS::IDC::AccountEntitlement
)
when
{
    resource.role == AWS::IDC::PermissionSet::"arn:aws:sso:::permissionSet/ssoins-12345abcdef/ps-12345abcdef" &&
    resource.target in AWS::OrgUnit::"ou-123abc" &&
    resource.target.tags.contains({key: "department", value: "engineering"})
};

As you can see above, Cedar is suuper flexible. We can slice and dice authorization based on the AWS account tags, our AWS organization hierarchy, and our users' on-call status in PagerDuty. Pretty neat!

What's not neat though is making typos in policies. If I fat-finger my policy code and write Access::Action::"Reqeust" instead of Access::Action::"Request", Cedar won't match the action and I'll see an Access Denied.

Fortunately, Cedar has some great tooling to validate your policies before they are deployed. We'll run through some of this tooling below, including a ✨ brand new ✨ GitHub Action we've just released to validate policies automatically.

Validating locally

Cedar has support for type definitions similar to programming languages like TypeScript. In Cedar, you use a schema file to define the principals, actions, and resources used for authorization.

Writing a schema is straightforward, but because we want to get stuck into validation you can use one we've prepared earlier. Create a new GitHub respository based on our Cedar template repository here. Once you've created it, clone the repository to your local machine.

The repository contains a demo policy, allowing everyone to view Document resources:

permit (
    principal,
    action == Action::"View",
    resource is Document
);

To get set up for local policy validation we'll install Rust, then install the Cedar CLI:

cargo install cedar-policy-cli

Then, we can validate policies by running cedar validate:

❯ cedar validate --schema test.cedarschema.json --policies demo.cedar
  ☞ policy set validation passed
  ╰─▶ no errors or warnings

It's passing!

This is great, but it would be even better if we could have GitHub Actions run policy validations automatically when we make changes.

Validating in GitHub Actions

Today we're releasing a GitHub Action allowing you to check for invalid policies as part of your Continuous Integration (CI) pipelines. Our GitHub Action adds annotations to your Pull Requests showing precisely where issues are.

You can add the action to your GitHub Actions workflows by adding a .github/workflows/cedar.yml file containing the following:

name: "Test"

on: [push]

jobs:
  cedar:
    name: Cedar
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Validate Policies
        uses: common-fate/cedar-validate-action@v1
        with:
          schema-file: ./example.cedarschema.json
          policy-files: "**/*.cedar"

Policy validation in Common Fate

If you'd like to learn more about validating policies in Common Fate, you can read our guide on developing authorization policies with continuous integration (CI).

What's next

We're planning on introducing additional tooling to help unit test Cedar policies using GitHub Actions. If you're interested in discussing this we'd love to hear from you in our Slack community - or you can follow us on X to stay updated.