
Today I have an important update to share: Common Fate is winding down operations.

Throughout our journey building Common Fate, we've been dedicated to creating Identity & Access Management tooling with a top-notch developer experience. Our access management platform has helped organizations effectively manage privileged access across integrations like AWS, Google Cloud, Okta, and more.

This journey wouldn't have been possible without the incredible support we've received along the way. I'm deeply grateful to our team members who helped build Common Fate, our customers who trusted us to manage their access, our investors who believed in our vision, and our community who provided invaluable feedback and support.

## Granted is being donated to fwd:cloudsec

We're pleased to announce that we are donating our open source project [Granted](https://granted.dev) to [fwd:cloudsec](http://fwdcloudsec.org) so that it can continue serving the cloud practitioner community. fwd:cloudsec will provide vendor-neutral governance for the project.

Chris Farris, Cloud Security Consultant and fwd:cloudsec association board member, shares:

> I work with a large number of cloud accounts across multiple clients and use Granted in my day-to-day work. With fwd:cloudsec, we're excited the independent cloud security community can help continue to shepherd the project, ensuring that everyone who needs a secure and easy-to-use way of accessing AWS can continue to rely and build on it for years to come."
Granted has become an essential tool for many cloud engineers, providing a seamless way to access and switch between AWS accounts and roles. We're confident that under fwd:cloudsec's stewardship, Granted will continue to thrive and serve the needs of the community.
We encourage all current users and contributors to continue engaging with the Granted project in its new home. Your ongoing support will be crucial to its future success.

Thank you to everyone who has been part of the Common Fate story. While this chapter is closing, we're proud of the impact we've made and grateful for all the connections we've built along the way.


Today I have an important update to share: Common Fate is winding down operations.

Common Fate is winding down


Today we're releasing a new browser extension for Granted which makes authenticating to AWS IAM Identity Center faster and more secure. The extension protects users from being phished for AWS credentials.

When users authenticate to IAM Identity Center using a CLI, a browser window like the below is opened. Clicking "Confirm and continue" begins a login flow where users are prompted to authenticate using their single-sign on credentials, including entering MFA.

![IAM Identity Center login screen](/blog_posts/granted-mitigates-device-phishing/sso_confirm.png)

The problem with this process though is that an attacker who knows your IAM Identity Center URL can craft a malicious login URL and send it to you. If you're unlucky enough to open it, this is what you'll see:

![Malicious IAM Identity Center login screen](/blog_posts/granted-mitigates-device-phishing/malicious_sso_confirm.png)

Looks similar to the first screenshot, right? And what's worse, if you click "Confirm and continue" here and enter your SSO credentials, the attacker will gain access to all of the AWS roles available to you in IAM Identity Center.

![Phishing for AWS credentials via AWS SSO device code authentication](/blog_posts/granted-mitigates-device-phishing/attack_flow.png)

Sebastian Mora has created a [proof-of-concept](https://github.com/seb1055/obfuscated-openssh/tree/main/aws-sso) for the attack here.

## How Granted helps

The Granted browser extension reads the code on the IAM Identity Center confirmation page and confirms that it matches the Granted CLI. If the code matches, the extension clicks the "Confirm and continue" button on your behalf. This makes the login process faster.

![Granted extension auto-confirm](/blog_posts/granted-mitigates-device-phishing/auto_code_confirm.png)

If you're ever sent a malicious login URL by an attacker, Granted disables the confirmation button to prevent your credentials being stolen.

![Granted extension preventing phishing](/blog_posts/granted-mitigates-device-phishing/protect_bad_code.png)

Under the hood, the browser extension uses the native messaging API to communicate with the Granted CLI. Using native messaging means that other browser extensions or applications can't read the user code from Granted.

The extension works in all Chromium-based browsers and requires Granted version 0.35 or later.

A big thanks to Rami McCarthy - this feature originated from a discussion I had with Rami at fwd:cloudsec EU last month where he suggested we build this into Granted.


Today we're releasing a new browser extension for Granted which makes authenticating to AWS IAM Identity Center faster and more secure.

Granted now mitigates device auth phishing in AWS IAM Identity Center


In [part 1 of our Cloud Access Maturity Model](/blog/cloud-access-maturity-model-part-1), we outlined four stages of access management maturity in the cloud: Administrator-centric, Role-Based Access Control (RBAC), Just-in-Time (JIT), and finally Adaptive.

In this follow-up piece we provide more detail about what each level looks like, how to measure maturity with metrics, and ultimately how to progress to the next stage.

![Overview of stages, showing 'Administrator-centric', followed by 'Role Based Access Control', followed by 'Just-in-time Access', followed by 'Adaptive Access'](/blog_posts/cloud_access_maturity_model_part_2_stages.png)

## **Stage 1: Administrator-centric**

In the Administrator-centric stage, access management is at its most basic level. This stage is characterized by over-provisioned access, where most - and often all - users have administrator privileges. This stage prioritizes functionality and ease of use over security, which poses significant business risks.

## Pains

This stage of maturity is like running on a legacy system, since it’s missing the security advances of the last 10 years. This stage also goes hand-in-hand with long-term credentials (for example, IAM user access keys) that are one of the main sources of compromise.

The main mitigation available in this stage is to limit the number of people that have access to the system. Adding additional layers of authentication, like multi-factor authentication (MFA), at least adds additional verification that the user is who they claim to be, but still doesn’t address the excess permission granted.

Obtaining compliance certifications at this stage is very difficult due to such a low level of maturity. Any business that requires or prioritizes official compliance recognition needs to make changes immediately.

### Metrics

![Stage 1 metrics](/blog_posts/cloud_access_maturity-metrics-stage-1.png)

**The number of entities with administrator access**, which should be as low as possible. If administrator access can’t be avoided, it should at least be tracked and measured, so that it can be improved over time.

**The number human users without MFA enabled**, which should be zero. Ideally, MFA should be enforced by the identity provider.

**The age of long-term credentials**, which should be lower than an agreed threshold, for example 30 days. This can and should be enforced by the identity provider, for example password rotation. Additionally, any user-controlled credential should meet minimum complexity requirements, for example password strength, and it should be enforced.

### Advancement

The key to success at this level of maturity is to spend as little time as possible at it! By tracking the metrics and reviewing them periodically will help push them in the right direction. It’s not hard to mature beyond this stage, which makes it even less forgivable to spend excessive time at it.

Adding a centralized identity provider (IdP) for human users will de-couple identity from access, help reduce duplication, and push activities towards using roles and short-term credentials.

Identifying and tracking machine users with administrator access gives a focus point for access to remove or reduce over time, and regularly reviewing this list will encourage people to do the right thing on a day-to-day basis.

## **Stage 2: Role-Based Access Control (RBAC)**

The RBAC stage represents a significant step forward in access management maturity. At this stage, organizations move away from universal administrator access approach to more focused, business-aware roles. This stage requires upfront thinking about access requirements and defining roles that meet these needs appropriately, which represents a move towards deliberate, context-aware security.

### Pains

Even though this approach greatly improves on the previous stage of maturity, there’s still lessons to be learned. Working out what each role should have access to, and how many roles is appropriate is a process that takes time, feedback, and practice - You don’t know you’ve got too many roles until you’ve got too many roles! A lack of ownership or agreement roles’ scope is almost guaranteed to happen at this stage. In addition to roles still being too permissive, another potential source of pain at this stage is roles not being permissive enough, or not accurately scoped to the task requirements. This leads to users falling back to administrator-level (or similarly over-permissive) roles to get their job done on a day-to-day basis.

### Metrics

![Stage 2 metrics](/blog_posts/cloud_access_maturity-metrics-stage-2.png)

**Number of permissions granted to individuals**, which should go down to as close to zero as possible. When this metric is high, it suggests roles are poorly defined.

**The number of roles available**, which should go up, and eventually reach a stable number. The exact number will depend on things like the team structure and business requirements, but regardless should eventually stabilize.

### Advancement

Reviewing the approach towards resource containment can be a valuable exercise at this stage, since it will directly impact the scoping of roles. This means accounts in AWS, projects in GCP, and subscriptions in Azure.

Automation can be used to help generate roles based on historical activities. The increased resource management that comes with RBAC means that automation in general becomes more valuable, since it helps address the associated management overhead. More specifically, automation can also be used to help generate roles based on historical activity, giving higher levels of confidence.

## **Stage 3: Just-in-time (JIT) Access**

In the Just-in-time Access stage, organizations add a temporal dimension to their access management, so that access is not only role-based but also time-limited. This represents an additional dimension of access management that is still tied to specific business requirements. Adding a time limit to access significantly reduces the “standing access” available to entities, and aligns permissions more closely with actual needs.

### Pains

Introducing a time-based approval step to access undoubtedly increases security, but that comes at the cost of convenience. If approvals take too long, users may try to revert back to using standing or long-term access to avoid being blocked. This highlights the need for automation to streamline the approval process as much as possible.

A common trap to fall into at this stage is to require manual/human approvals for all access, even if it’s a non-critical level of access. As much as possible, the additional friction of approvals should be used for higher, more business-critical levels of access, to reduce productivity bottlenecks.

### Metrics

![Stage 3 metrics](/blog_posts/cloud_access_maturity-metrics-stage-3.png)

**Standing hours of access**, which should go down to as low as possible.

**Access request approval rate**, which should be as high as possible. If this number is low, it suggests that the policies around access are not fit for purpose i.e. users are requesting access they shouldn’t have been able to request.

**Percentage of approvals that are auto-approved**, which should be high but stable. This should be as high as possible for entitlements that are not critical.

**Time to approval response**, which should be as low as possible, to a reasonable expectation. This means that requests are approved or denied in a reasonable and consistent timeframe.

### Advancement

This stage requires extensive automation, and advancing beyond it requires even more! This level of security becomes prohibitively limiting to productivity if not entirely automated.

Counter intuitively, this stage is not focused on limiting the permissions granted, only they are granted for an appropriate reason and time period. This means that you might be granting more privileges, but for less time - In this stage, less really is more!

Roles and levels of access should be well understood and defined, and only change periodically, for example when new teams or projects are spun-up. As part of the automation process, activity and audit actions need to be extensively and consistently logged, so that they can be used in the next stage of maturity.

<aside>
  [CommonFate.io](http://CommonFate.io) is self-hosted JIT access to your AWS
  accounts, GCP projects, and more.
</aside>

<div className="mb-8">
  <WaitlistCta />
</div>

## **Stage 4: Adaptive Access**

The Adaptive Access stage represents the pinnacle of access management maturity. At this level, access is dynamically adjusted based on historical usage patterns, and real-time context. Permissions are automatically scoped to the least privileges required for specific tasks, making the principle of least privilege the default rather than the exception.

Additional pieces of context are included, such as on-call rotation status, and other variable information that would otherwise need to be manually managed by a user.

## Pains

Even this level of maturity is not without its pains and challenges. The baseline automation required at this stage is extensive, and represents significant commitment and investment of time and effort to achieve. No organization “accidentally” achieves this level of access management. This level of maturity will also require a significant learning curve for new engineers and developers, as they are unlikely to have experienced much or at all at previous organizations, almost all of whom are operating at a lower level of maturity.

### Metrics

![Stage 4 metrics](/blog_posts/cloud_access_maturity-metrics-stage-4.png)

**Privilege access usage**, which should be approaching zero. If there is access, there should be an associated incident or justification for unusual/break-glass access.

**Permissions denied errors**, which should be very low. If this metric is too high, it means that the generated access is not sufficient.

### Advancement

At this level, there is no advancement steps because least privilege and limited time access is built-in. What is required is consistent, pro-active review to ensure that the system is continually performing as expected, while still supporting users to do their job and meet business needs and requirements.

## Conclusion

Cloud access management maturity is a critical journey for organizations seeking to balance security, compliance, and productivity. As we've explored, this journey progresses through four key stages: Administrator-centric, Role-Based Access Control (RBAC), Just-in-Time (JIT), and finally Adaptive.

Each stage brings its own challenges and benefits, requiring organizations to continuously evolve their practices, metrics, and technologies to address pains and challenges. The goal is to achieve a state of Adaptive Access, where permissions are dynamically adjusted based on context and need, practicing the principle of least privilege.

By understanding these stages and actively working to advance through them, organizations can enhance their security posture, streamline operations, and better meet compliance requirements.


Metrics to manage and improve to raise maturity

A Cloud Access Management Maturity Model: Part 2


Today we have released [Common Fate CLI v1.15](https://github.com/common-fate/cli/releases/tag/v1.15.1). This release adds support for running [Access Tests](https://docs.commonfate.io/authz/testing).

Access Tests allow you to verify the behaviour of authorization policies and confirm that Common Fate resource syncing is working as expected. You can write tests to check for invariants, such as "an external contractor should never have auto-approved production access", or "a security team member should have auto-approved access to an account in the Security Organization Unit in AWS".

Access Tests are specified using a YAML file, similar to the following:

```yaml
# group-tests test whether a user is a member of a group or not.
group-tests:
- user: alice@example.com
  group: 2df6c5c4-0e09-477a-b796-9ad9bd756d83
  is-member: true

# access-tests test whether a user is allowed to access a particular entitlement or not.
access-tests:
- user: alice@example.com
  target: development-aws-account
  role: AWSReadOnlyAccess
  expected-result: auto-approved

- user: alice@example.com
  # you can also use Cedar entity IDs here for the target or role
  target: AWS::Account::"123456789012"
  role: AWS::IDC::PermissionSet::"3d06e8e5-93d3-4bfd-ae4f-e5caf43c99ad"
  expected-result: requires-approval

- user: alice@example.com
  target: very-sensitive-aws-account
  role: AWSReadOnlyAccess
  expected-result: no-access
```

You can run tests by using `cf tests run -f tests.yml`. You'll see an output similar to the below:

```
retrieving users for email address lookups...
retrieved 126 users
-------------- ACCESS TESTS --------------
running 2 access tests...

[PASS] chris@commonfate.io requires-approval to Sandbox-1 with role ViewOnlyAccess

[FAIL] chris@commonfate.io auto-approved to Sandbox-2 with role ViewOnlyAccess: got requires-approval
	policies contributing to requesting access: [basic.policy0]
	policies contributing to activating access: []

-------------- GROUP MEMBERSHIP TESTS --------------
running 2 group membership tests...

[PASS] chris@commonfate.io is member of c9bed4d8-d091-7057-4ed7-6d60bcf1e8bf

[PASS] chris@commonfate.io is not member of 790e94a8-2071-7016-a43c-86e66212a43d

1 Access Tests failed
All Group Membership Tests passed
```

You can also [run tests in Continuous Integration providers like GitHub Actions](https://docs.commonfate.io/authz/ci#access-testing-in-ci). Here's an example GitHub Actions workflow:

```yaml
name: Test

on:
  push:

jobs:
  access:
    name: Access Testing
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install Common Fate CLI
        uses: common-fate/install-cli-action@v1
        with:
          oidc-client-id: abcdefGHIJKL12345678 # replace this with your Client ID
          oidc-client-secret: ${{ secrets.CF_OIDC_CLIENT_SECRET }}
          oidc-issuer: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_abcdeFGH # replace this with your Issuer
          api-url: https://commonfate.example.com # replace this with your Common Fate API URL

      - name: Run Access Tests
        run: cf tests run -f tests.yml
```

To learn more about this feature, [read our documentation on access testing](https://docs.commonfate.io/authz/testing).


Write test cases for access policies using the Common Fate CLI

Access Testing


# Cloud Access Management Maturity Model: Part 1

Cloud access represents an important challenge to businesses using the cloud in 2024. Unlike historical data center-based environments where the physical network was the perimeter of a company’s digital estate, now identity and access management (IAM) represents the most important boundary that requires protection. This is because in a software defined system like the cloud, the right identity has permission and the ability to change all other resources, including the network.

## Identity is the Customer’s Responsibility

Modern hyper-scale cloud providers operate on a shared responsibility model (for example [AWS](https://aws.amazon.com/compliance/shared-responsibility-model/) and [GCP](https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate)), and the configuration of IAM is one of the first customer-owned aspects of the approach. Cloud providers pledge to provide a secure identity access solution for customers to use, but require that customers use it correctly to ensure appropriate access to their resources.

In a public cloud environment, where most costs are incurred on a usage/pay-as-you-go basis, access to resources represents not only a data security issue, but also a cost risk. Unauthorized access to your environment is bad not only for your reputation and brand, but also your budget.

## Overview of the Cloud Access Maturity Model

This presents new and unfamiliar challenges in the modern, global and distributed workplace, and in this piece we will define a series of maturity levels for businesses to measure themselves, and hopefully aim towards to improve their security in the cloud over time.

1. Administrator-centric
2. Role-Based Access Control (RBAC)
3. Just-in-time (JIT) Access
4. Adaptive Access

As with any real-world environment, organizations will rarely fit neatly into a single stage of maturity. Different teams and applications will demonstrate different levels of maturity.

The value of this model is to give a common vocabulary and shared understanding of what “good” looks like for cloud access. With a common goal in mind, even large organizations can move towards higher levels of maturity.

A company’s maturity will be reflective of the least mature systems, or the maturity of the majority of their systems. This makes common tooling, centralized oversight, and demonstration of good patterns even more valuable and useful in an environment.

![Overview of stages, showing 'Administrator-centric', followed by 'Role Based Access Control', followed by 'Just-in-time Access', followed by 'Adaptive Access'](/blog_posts/cloud_access_maturity_model_part_1_stages.png)

## Stage 1: Administrator-centric

In the early stages of a business, functionality takes priority over security, and access is over-provisioned. At this level, access is concerned only with “who” is doing actions, rather than any other considerations. This approach is commonly seen in early-stage organizations and have less than 20 engineers.

The starting point for almost all organizations is an administrator-centric approach, where most - if not all - users receive administrator access, or something close enough to not make a difference to the risk profile. This is because a user with over-provisioned access can do their job, while a user with under-provisioned access cannot do their job.

### Common Scenarios

This level of maturity is demonstrated in many “getting started” guides and blogs, where the first step is to provision an entity (like an AWS IAM User) with administrator privileges, so that the documentation can focus on the functional aspects, rather than the security concerns.

Many best practices approaches and techniques are not possible, because business and operational requirements are still being discovered and defined. For example, [the principal of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) requires a legitimate purpose to define what “least” means for a particular user or principal.

### Challenges

Symptoms of this stage include things like self-inflicted damage and outages. The common concept of “blast radius” describes the worst-case scenario if something goes wrong, and at this stage of maturity it can mean damage to **any and all** of the business systems.

![Blast radius for Administrator Access](/blog_posts/cloud_access_maturity-blast_radius_administrator.png)

Key person risk is a legitimate concern, since individual users have non-trivial access. Attribution of actions can be difficult or impossible due to the levels of access provisioned. Even if an audit log exists, it may not be trust worthy, because the users it audits have access to change it.

## Stage 2: Role-Based Access Control (RBAC)

The next level of maturity focuses on a move away from administrator access for all activities, to more focused, business-aware, role-based access. At this level of maturity, a business centric, up-front thinking approach must be taken to requirements, and define the roles that to meet those requirements appropriately. This represents a shift to “what” level of access, rather than just “who” is accessing. This stage is common in organizations with 20 to 50 engineers.

### Business Benefits

Even though administrator access is still available, day-today usage is greatly reduced, and users like developers (who don’t have a business requirement for administrator access) are no longer given elevated privileges.

![Blast radius for RBAC](/blog_posts/cloud_access_maturity-blast_radius_rbac.png)

This means that day-to-day exposure to blast radius exposure and damage is limited. Key person risk is reduced, since the shared roles represent the access required to operate the business systems, not an individual user.

### Challenges

Defining the right level of access for roles can be a challenge in the early days of this stage of maturity. Managing and updating roles as they evolve over time can be burdensome for teams that have a low level of automation. If roles don’t meet the requirements of the users, they will fall-back in to old habits of using administrator access for everything, removing the benefit of having roles to assume. Even when users do the “the right thing” and assuming specific roles, the extra noise and indirection can be overwhelming if not managed appropriately, leading to a lack of auditability and understanding of their own environment.

## Stage 3: Just-in-time (JIT) Access

At this level of maturity, access is not only role-based and linked to business activities, but the permission to use those levels are only provided when an approved business requirement is demonstrated. Access management is now about the “why” of access, not just “what” level of access is requested. JIT access to environment represents the alignment of access management with business requirements: if you don’t have a valid reason for access, you don’t have it.

### Time-Limited Permissions

Access to a particular role or level of access is subject to an approval, and granted for a limited time window. Requests are approved by the appropriate business-level stakeholders, or by pre-existing rules, such as developers assigned to manage a particular account. Access is removed when the requirement is over, resulting in less standing access that could be accidentally used or abused. This approach dramatically reduces the problem of blast radius, because while mistakes are still possible, their impact is greatly reduced due to less standing or implicit access.

This level of advanced and deliberate access is more mature than most cloud-based businesses today, and is a common aspirational goal of many organizations. It makes most sense in organizations with 50-100 engineers, so that the investment in automation has a positive return on the effort required.

### Challenges

Including an approval process, regardless of how well this aligns access to business requirements, introduces friction. To avoid this friction, teams or users might hoard access, or use access like build systems to accomplish tasks that should be done in a different manner. If approvals are not granted in a smooth and timely manner, they become a barrier to productivity and time to resolution of issues. Due to these challenges, automation becomes an absolute requirement at this level of maturity, which represents its own set of challenges for an organization.

<aside>
  [CommonFate.io](http://CommonFate.io) is self-hosted JIT access to your AWS
  accounts, GCP projects, and more.
</aside>

<div className="mb-8">
 <WaitlistCta />
</div>

## Stage 4: Adaptive Access

> Least privilege equals maximum effort
>
> - Eric Brandwine, VP & Distinguished Engineer at Amazon

Adaptive cloud access management takes historical access in to consideration, and automatically scoped to the least privileges required to enable the business tasks at hand. Access is based not on what users think they need, but on what they actually use and require. Due to the cost and effort involved, this high level of maturity is usually only attainable for teams of more than 100 engineers.

### Data-Driven Permissions

This most advanced level of access management represents the most efficient alignment of technical requirements with business needs, making least privilege access the standard, not the exception. In many cases, common actions are performed via automation, so elevated access is not required or granted to users.

This level of access is the pinnacle of access management, since it builds upon the earlier levels, and refines the process of identifying and provisioning access.

### Challenges

This level of maturity and automation requires the most up-front effort and work. It requires automation in all areas. The requirement for automation also provides the ability to produce an exhaustive audit trail and visibility in to the system. At this stage there should be zero manual access to production, but break-glass access is available with appropriate checks and balances, notifications and alerts, for the inevitable unusual scenarios. Especially in the early days of this maturity, access needs to be reviewed, not a blocker to access but as “trust, but verify” in action. The main drawback to this level of maturity is the human adjustment and learning curve required, since most engineers are used to working with lower levels of maturity.

## Conclusion

This first piece introduces the different levels of cloud access maturity in a cloud environment.
In following pieces, the practical implementations of the different maturity levels will be detailed, and how organizations can progress their maturity level.

[Read Part 2 of our maturity guide here.](/blog/cloud-access-maturity-model-part-2)


A Roadmap for Businesses in the Cloud Era

A Cloud Access Management Maturity Model: Part 1


At Common Fate we're big fans of [authorization-as-code](https://docs.commonfate.io/authz/introduction). 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](http://www.cedarpolicy.com) as the authorization-as-code framework in [our product](https://docs.commonfate.io/introduction).

If you're unfamiliar with Cedar, you can [check out our introductory blog post here](/blog/jit-using-cedar).

We have released a [Cedar Terraform Provider](https://registry.terraform.io/providers/common-fate/cedar/latest/docs) to make authoring Cedar policies easier in Terraform. The provider allows you to write authorization policies using [HCL](https://developer.hashicorp.com/terraform/language/syntax/configuration), Terraform's configuration syntax. Here's a simple example:

```hcl
data "cedar_policyset" "example" {
  policy {
    effect = "permit"

    annotation {
      name = "advice"
      value = "You can request access because you are in the Engineering team."
    }

    principal_in = {
      type = "AWS::IDC::Group"
      id   = "12345-12345-12345"
    }
    action = {
      type = "Access::Action"
      id   = "Request"
    }
    any_resource = true

    when {
      text = "resource.target in AWS::OrgUnit::\"ou-123\""
    }
  }
}

resource "commonfate_policyset" "example" {
    id = "example"
    text = data.cedar_policyset.example.text
}
```

The `cedar_policyset` resource renders a Cedar policy, available as `data.cedar_policyset.example.text`. Here's what the resulting policy looks like:

```
@advice("You can request access because you are in the Engineering team.")
permit (
  principal in [AWS::IDC::Group::"12345-12345-12345"],
  action == Access::Action::"Request",
  resource
)
when {
  resource.target in AWS::OrgUnit::"ou-123"
};
```

The provider allows you to use Terraform variables in your policies. For example, we can configure an on-call rotation in PagerDuty, as well as authorization policies for access workflows in one place:

```hcl
resource "pagerduty_schedule" "example" {
  name      = "Daily Engineering Rotation"
  time_zone = "America/New_York"

  layer {
    name                         = "Night Shift"
    start                        = "2015-11-06T20:00:00-05:00"
    rotation_virtual_start       = "2015-11-06T20:00:00-05:00"
    rotation_turn_length_seconds = 86400
    users                        = [pagerduty_user.example.id]

    restriction {
      type              = "daily_restriction"
      start_time_of_day = "08:00:00"
      duration_seconds  = 32400
    }
  }

  teams = [pagerduty_team.example.id]
}

data "cedar_policyset" "example" {
  policy {
    effect = "permit"

    annotation {
      name = "advice"
      value = "Access is automatically approved because you are on-call in the ${pagerduty_schedule.example.name} rotation."
    }

    principal_in = {
      type = "PagerDuty::OnCall"
      id   = pagerduty_schedule.example.id
    }
    action = {
      type = "Access::Action"
      id   = "Activate"
    }
    any_resource = true
  }
}
```

You can [learn more about the provider here](https://registry.terraform.io/providers/common-fate/cedar/latest/docs).


We've released a Terraform Provider which makes it easier to create authorization policies.

Introducing the Cedar Terraform Provider


# Community Newsletter: July 2024

Hey everyone! Shwetha here with the latest tech update. If you want to contribute to what we're building or would like more regular weekly updates, please join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech)!

## RDS access

We are excited to announce that our [AWS RDS Integration](https://docs.commonfate.io/integrations/awsrds) is now generally available. This integration allows users to request Just-In-Time (JIT) access to RDS databases, leveraging [AWS SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) to connect via the [Common Fate AWS Proxy](https://registry.terraform.io/modules/common-fate/common-fate-proxy-ecs/aws/latest) service deployed to ECS in your account.

The proxy service captures audit logs of all SQL commands executed by the user during their session which can be viewed in real-time. Want to learn more about setting up RDS access with Common Fate? Book a live demo using [**this link**](https://savvycal.com/common-fate/d3c7f2e9).

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/eb5a6691-3caa-e35c-6f76-f8e4ddc276c0.png)

## Cedar Terraform Provider

We have released a [**Cedar Terraform Provider**](https://registry.terraform.io/providers/common-fate/cedar/latest/docs) to make authoring Cedar policies easier in Terraform. The provider allows you to write authorization policies using [**HCL**](https://developer.hashicorp.com/terraform/language/syntax/configuration), Terraform's configuration syntax. Please read our latest blog post [here](https://www.commonfate.io/blog/cedar-terraform-provider) to learn more!

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/a49c88c9-1150-b2b8-6150-03aabd593caa.png)

## Insights

Common Fate now shows key metrics to measure the impact of using Just-In-Time access. Access Hours Reduction measures the risk reduction compared to persistent access. Protected Users helps you track adoption of Common Fate.

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/e6d37a64-07b2-27c9-591c-b0797df2aafb.png)

## New User Directory

We have revamped how we manage users and groups in Common Fate. Users with [read administrator access](https://docs.commonfate.io/observability/preview-access#grant-the-required-permissions) will now find a dedicated panel in the taskbar dedicated to the Directory.

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/55290346-0ada-14ce-33de-1852264e13fc.png)

## Granted Updates

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

**AWS RDS Proxy Plugin**

You can now use Granted’s [AWS RDS Proxy Plugin](https://docs.commonfate.io/granted/plugins/aws-rds) to connect to an AWS RDS database over [AWS SSM Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html). The connection is routed through a [Common Fate AWS Proxy](https://registry.terraform.io/modules/common-fate/common-fate-proxy-ecs/aws/latest) which captures audit logs of the SQL statements executed. The plugin uses the Common Fate control plane APIs to determine which databases a user is authorized to access, so to use this plugin a Common Fate instance is required.

**Check JIT request status**

You can now use `granted request check` to check the status of a Just-In-Time Access Request, for AWS profiles protected by Common Fate: `granted request check --aws-profile Production/ViewOnlyAccess`

A big shoutout to our first-time contributor:

- [@dnrce](https://github.com/dnrce) made their first contribution in [#708](https://github.com/common-fate/granted/pull/708)

For a comprehensive list of changes, please visit our [changelog](https://github.com/common-fate/granted/releases).

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for July.

Community Newsletter: July 2024


# Community Newsletter: June 2024

Hey everyone! Shwetha here with the latest tech update. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

### Our latest blog post: **Simplifying Just-in-Time Access Governance using Cedar**

Check out our latest blog post in which AWS IAM expert Rowan Udell has conducted a deep dive into AWS's open-source policy language Cedar and how we utilize it for Just-In-Time access [here](https://www.commonfate.io/blog/jit-using-cedar). Want to learn more about how we use Cedar? Book a live demo using [**this link**](https://savvycal.com/common-fate/d3c7f2e9).

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/1e19494a-fd96-89f4-14eb-24dc8699abdf.png)

### Featured at re:Inforce

We were pleasantly surprised to be acknowledged by AWS recently during the re:Inforce 2024 keynote for our utilization of Cedar. Our work with Cedar showcases how the open-source policy language can be used to control your access management. We are proud to be at the forefront of this new technology!

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/e7114543-d4cb-ad66-c0a4-3ba97e66b24f.png)

## New Request UI

We're excited to announce improvements to our request access UI. The new interface now displays the AWS organizational unit and GCP folder that accounts belong to, providing a better context for users. Additionally, the web console now encourages users to select read-only/view-only access by default, though other roles remain available via the drop-down menu.

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/d2ffc9ca-28dc-c30b-990e-ecc6701810b5.png)

## Breakglass Access

We have recently added Breakglass access, which allows a user to optionally bypass approval requirements on an access request in situations where immediate access is required. By default, no Breakglass access is permitted in your Common Fate deployment.
![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/3c507757-cecb-d4b5-87df-4cbcc6e95740.png)

## Granted Updates

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

**Support for Firefox Nightly**

You can now use Granted with Firefox's Nightly browser. To set this up, run `granted browser set` , select `Firefox Nightly`, and enter the path to your browser. Thanks, [@meuxx](https://github.com/meuxx) for this contribution.

**Added the option to clear the entire Granted cache**

You can now run `granted cache clear --all` and choose which secure storage you want to clear the cache. The command will then clear all credentials for the selected secure storage.

A big shoutout to our first-time contributor:

- [@meuxx](https://github.com/meuxx) made their first contribution in [#685](https://github.com/common-fate/granted/pull/685)

For a comprehensive list of changes, please visit our [changelog](https://github.com/common-fate/granted/releases).

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for June.

Community Newsletter: June 2024


# 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](https://www.cedarpolicy.com/) to control your access management, as used by [Common Fate](https://www.commonfate.io/solutions/pam).

## 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](https://arxiv.org/pdf/2403.04651) is as extensive as you would expect from any piece of research. The project has [extensive documentation](https://docs.cedarpolicy.com/) and [supporting resources](https://github.com/cedar-policy/cedar-awesome).

## 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](https://docs.commonfate.io/setup/glossary#grant) that allow time-bound access to [entitlements](https://docs.commonfate.io/setup/glossary#entitlement), like AWS accounts, GCP projects, and more. Grants can be requested, approved, closed, or activated (once approved).

<figure>
  <img
    src="/images/access-flow.png"
    alt="Grant request lifecycle in Common Fate"
  ></img>
  <figcaption>Grant request lifecycle in Common Fate.</figcaption>
</figure>

### 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:

```rust
@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](https://docs.commonfate.io/setup/glossary#grant): time-based access to an entitlement, such as an AWS account or GCP project (among others).

The `@advice` syntax allows us to [annotate](https://docs.cedarpolicy.com/policies/syntax-policy.html#term-parc-annotations) 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:

<figure>
  <img
    src="/images/request.png"
    alt="Advice annotations appear alongside entitlements in Common Fate"
  ></img>
  <figcaption>
    Advice annotations appear alongside entitlements in Common Fate.
  </figcaption>
</figure>

### 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:

```rust
@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:

```rust
@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:

```rust
@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](https://docs.commonfate.io/integrations/sso/entra), so this particular statement relies on a specific ID for the [Entra group](https://learn.microsoft.com/en-us/entra/fundamentals/concept-learn-about-groups) 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.

<figure>
  <img
    src="/images/ga.png"
    alt="Annotations show issues with Cedar policies inline for easy resolution, before they get deployed."
  ></img>
  <figcaption>
    Annotations show issues with Cedar policies inline for easy resolution,
    before they get deployed.
  </figcaption>
</figure>

We provide a [Validate Cedar Policies GitHub Action](https://github.com/marketplace/actions/validate-cedar-policies) 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](https://en.wiktionary.org/wiki/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](https://savvycal.com/common-fate/d3c7f2e9?sid=f3d2ed6e-baaf-486d-9e2e-3ca82717230d) of the Common Fate platform.


The benefits of using Cedar to control your access management with Common Fate

Simplifying Just-in-Time Access Governance using Cedar


We are now publishing signed Debian releases of [Granted](https://granted.dev) to an APT repository, hosted at `https://apt.releases.commonfate.io`. If you are using Ubuntu or another Debian-based operating system, you can add our repository with the following command:

```bash
wget -O- https://apt.releases.commonfate.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/common-fate-linux.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/common-fate-linux.gpg] https://apt.releases.commonfate.io stable main" | sudo tee /etc/apt/sources.list.d/common-fate.list
```

After adding the repository, you can install and update Granted with:

```bash
sudo apt install granted
```

Our APT repository is hosted on AWS, using S3 and CloudFront to maximise package availability. We've also published [linuxpack](https://github.com/common-fate/linuxpack), an open-source project we are using to package and publish releases to the APT repository.

Our APT packages include the same Linux binaries published to `https://releases.commonfate.io`. You can find the full installation instructions in the [Granted documentation](https://docs.commonfate.io/granted/getting-started#installing-the-cli).

Our Linux releases are signed with a separate PGP key, available at `https://apt.releases.commonfate.io/gpg`. The key's fingerprint is `783A 4D1A 3057 4D2A BED0 49DD DE9D 631D 2D1D C944`. We've updated our [security documentation](https://docs.commonfate.io/granted/security) to include details on the key.


Installing Granted on Linux is now easier with our new APT repository.

The Common Fate Linux Repository


# Community Newsletter: May 2024

Hey everyone! Shwetha here with the latest tech update. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

## **GCP Role Group**

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/435ad2cf-3186-6721-5eb1-8914aacec306.png)

Common Fate now supports [GCP Role Groups](https://docs.commonfate.io/integrations/gcp#gcp-role-group-access). This feature allows you to streamline permissions across multiple GCP roles by defining role groups. Role groups enable you to bundle multiple predefined roles, such as folder admin and owner, into a single entity. Users can then request access to these role groups for GCP projects or folders. GCP Role Groups allow you to work around the permission count restriction in custom roles.

## **Auth0 integration**

<img
  src="https://mcusercontent.com/69860be79239e5e8d492037c9/images/957cc4f5-1a75-72d2-5ea2-e13acd7945b6.png"
  style={{
    backgroundColor: "white",
  }}
/>

Common Fate now integrates with [Auth0](https://auth0.com/) to provision Just-In-Time access. This integration allows users to request temporary access to Auth0 Organizations.

## S3 Log Destination

<img
  src="https://mcusercontent.com/69860be79239e5e8d492037c9/images/95d0af58-a754-6825-7a2b-df8d3a81de3b.png"
  style={{
    clipPath: "inset(5px 5px 5px 5px)",
  }}
/>

Common Fate can now send audit log events to an [Amazon S3 bucket](https://docs.commonfate.io/integrations/s3-log-destination). This allows you to maintain an archive of actions taken within Common Fate or to build custom reports based on access activity and gain insights into access patterns.

## Granted Updates

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

**Common Fate built-in Profile Registry**

Granted can now automatically [sync AWS profiles for available roles in Common Fate](https://docs.commonfate.io/granted/usage/profile-registry#common-fate-built-in-profile-registry). This feature automatically syncs available AWS profiles into your ~/.aws/config file.

**Enhancements to Granted's SSO Populate/Generate**

Starting from version [v0.25.0](https://github.com/common-fate/granted/releases/tag/v0.25.0), Granted now allows configurations for granted sso generate and granted sso populate to be persisted in the Granted config file (~/.granted/config by default). This update also includes support for using [Sprig](https://masterminds.github.io/sprig/) template functions, enhancing customization options.

A big shoutout to our first-time contributors:

- [@mikesarver](https://github.com/mikesarver) made their first contribution in [#648](https://github.com/common-fate/granted/pull/648)
- [@ckluy31](https://github.com/ckluy31) made their first contribution in [#663](https://github.com/common-fate/granted/pull/663)

For a comprehensive list of changes, please visit our [changelog](https://github.com/common-fate/granted/releases).

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for May.

Community Newsletter: May 2024


# Community Newsletter: April 2024

Hey everyone! Shwetha here with the latest tech update. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

## **Preview Access**

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/e86d1613-e117-2559-d168-89693916a4d5.png)

Preview the access granted to each Common Fate user as per your authorization policies. By default, users in Common Fate lack permission to view authorization logs. Refer to [our documentation](https://docs.commonfate.io/observability/preview-access) to learn how to configure this.

## **BigQuery Access**

<img
  src="https://mcusercontent.com/69860be79239e5e8d492037c9/images/c50b22fa-ff3f-7f1c-f86f-000842e9fa47.png"
  style={{
    clipPath: "inset(5px 5px 5px 5px)",
  }}
/>

Common Fate now [integrates with BigQuery](https://docs.commonfate.io/integrations/bigquery) to provision Just-In-Time access to data. The integration creates an inventory of BigQuery resources across a Google Cloud organization and allows access to be requested to individual Tables or Datasets.

## Webhook Integrations

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/760c9683-08bf-24b9-7b88-7a09a319cded.png)

Connect Common Fate to other security tools or build custom integrations using our [new webhook integration](https://docs.commonfate.io/integrations/webhook). Using webhooks you can stream audit log or authorization events to any HTTP endpoint.

## Granted Updates

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

**Just-In-Time (JIT) access using Common Fate + Granted**

Granted can now be used with **[Common Fate](https://docs.commonfate.io/introduction)** for just-in-time access to privileged AWS roles. For more information on JIT access, check out the [JIT recipe](https://docs.commonfate.io/granted/recipes/access-requests) in our documentation.

A big shoutout to our first-time contributors:

- [@Nepoxx](https://github.com/Nepoxx) made their first contribution in [#631](https://github.com/common-fate/granted/pull/631)
- [@gautamg795](https://github.com/gautamg795) made their first contribution in [#635](https://github.com/common-fate/granted/pull/635)
- [@treuherz](https://github.com/treuherz) made their first contribution in [#636](https://github.com/common-fate/granted/pull/636)

For a comprehensive list of changes, please visit our [changelog](https://github.com/common-fate/granted/releases).

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for April.

Community Newsletter: April 2024


# Common Fate Product Updates

Today we’re releasing new integrations for Common Fate, as well as an improved support experience for your end users using our access platform.

## BigQuery Access Integration

Common Fate now integrates with BigQuery to provision Just-In-Time access to data. The integration creates an inventory of BigQuery resources across a Google Cloud organization and allows access to be requested to individual Tables or Datasets.

[Read our integration guide here.](https://docs.commonfate.io/integrations/bigquery)

<img
  src="/blog_posts/bigquery.png"
  style={{
    clipPath: "inset(5px 5px 5px 5px)",
  }}
/>

## GCP Organization-Level Access

We’ve added support for provisioning Just-In-Time access at the organization level.

[Read our integration guide here.](https://docs.commonfate.io/integrations/gcp#organization-level-access)

## Embedded Product Support

You can now reach out to Common Fate support directly within the web console for assistance and feedback.

<img
  src="/blog_posts/embedded_product_support.png"
  style={{
    clipPath: "inset(5px 5px 5px 5px)",
  }}
/>

## **Webhook Integrations**

Connect Common Fate to other security tools or build custom integrations using our new webhook integration. Using webhooks you can stream audit log or authorization events to any HTTP endpoint. Get started: [Webhook Integration Guide](https://docs.commonfate.io/integrations/webhook).

![](/blog_posts/webhook.png)

## CLI improvements

The [Common Fate CLI](https://github.com/common-fate/cli) now automatically populates your local AWS configuration file when access is provisioned.

![](/blog_posts/cli_improvements.png)


Here's our most recent product update

Common Fate Product Updates


At Common Fate we're big fans of [authorization-as-code](https://docs.commonfate.io/authz/introduction). 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](http://www.cedarpolicy.com) as the authorization-as-code framework in [our product](https://docs.commonfate.io/introduction).

Here's an example Cedar policy you might write:

```cedar
@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.

<figure>
  <img
    src="/blog_posts/validating-cedar-with-github-actions/authorization-log.png"
    alt="Screenshot of authorization logs inside Common Fate showing many 'Access Denied' events"
  ></img>
  <figcaption>
  This is what our <a href="https://docs.commonfate.io/observability/authorization">
  authorization log</a> looks like when you fat-finger a policy.
  </figcaption>
</figure>

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](https://github.com/marketplace/actions/validate-cedar-policies) to validate policies automatically.

## Validating locally

Cedar has support for type definitions similar to programming languages like [TypeScript](https://www.typescriptlang.org/). In Cedar, you use a [schema file](https://docs.cedarpolicy.com/schema/schema.html) 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](https://github.com/new?template_name=cedar-github-actions-testing-example&template_owner=common-fate). Once you've created it, clone the repository to your local machine.

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

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

To get set up for local policy validation we'll [install Rust](https://www.rust-lang.org/tools/install), then install the Cedar CLI:

```bash
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](https://github.com/marketplace/actions/validate-cedar-policies) 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.

![Screenshot of GitHub annotations created by the Cedar Validate action](/blog_posts/validating-cedar-with-github-actions/annotation-screenshot.png)

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

```yaml
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)](https://docs.commonfate.io/authz/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](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) - or you can follow us on [X](https://twitter.com/CommonFateTech) to stay updated.


A guide on how to validate Cedar authorization policies using GitHub Actions.

Validating Cedar policies with GitHub Actions


# Community Newsletter: March 2024

Hey everyone! Shwetha here with the latest tech update. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

## DataStax Integration

We've introduced a built-in [DataStax](https://www.datastax.com/) Integration for seamless, just-in-time access to roles within DataStax. Learn more about the setup and process [here](https://docs.commonfate.io/integrations/datastax). Want to see this in action? Book a live demo using [this link](https://savvycal.com/common-fate/d3c7f2e9).

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/6dee01e1-9d74-0060-e64f-9947eba145f3.png)

## Authorization Logs

We have added authorization logs to inspect and debug authorization events within Common Fate. Each time an authorization decision is made, Common Fate stores a log of the evaluation. In [this guide](https://docs.commonfate.io/observability/authorization), you’ll learn how to use authorization logs to debug your authorization policies.

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/79f55254-4a0c-f4e9-f13b-7a1a6a6f67d6.png)

## Fourtheorem Blog Post

We were recently featured on Fourtheorem’s blog post on Managing AWS accounts like a PRO, which goes through the process of setting up IAM Identity Center with Granted to obtain credentials through Granted.

[You can read the blog post here](https://fourtheorem.com/managing-aws-accounts-part-1/)

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/21cbc61d-de82-86e0-6380-71a03eaeb007.png)

## Granted Updates

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

**Added support for refreshable AWS SSO:**

- You can now add `granted_sso_registration_scopes = sso:account:access` to your `~/.aws/config`, which will cause Granted to respect the [session duration](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-user-session.html) in IAM Identity Center. This can be extended to prompt less frequently. Supplying the `sso:account:access` scope will cause IAM Identity Center to return a refreshable access token, with a total allowed session time in accordance with your configured AWS SSO session length.

**IAM Federated logins now have attributable username in Cloudtrail**

- The changes refactor the way federation token ID is used for AWS IAM credentials. Instead of relying on the `userID` which was previously parsed, the code now uses the `userName` which is more easily attributable to the IAM user name in the Cloudtrail events list view. Thank you to [@matthewhembree](https://github.com/matthewhembree) for their contributors on this.

A big shoutout to our first-time contributors:

- [@CodyDunlap](https://github.com/CodyDunlap) made their first contribution in [#611](https://github.com/common-fate/granted/pull/611)
- [@matthewhembree](https://github.com/matthewhembree) made their first contribution in [#626](https://github.com/common-fate/granted/pull/626)
- [@keymon](https://github.com/keymon) made their first contribution in [#619](https://github.com/common-fate/granted/pull/619)

For a comprehensive list of changes, please visit our [changelog](https://github.com/common-fate/granted/releases).

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for March.

Community Newsletter: March 2024


# Community Newsletter: February 2024

Hey everyone! Shwetha here with the latest tech update. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

## **Common Fate IAM Analytics**

Common Fate now provides analytics to identify unused entitlements. We can audit trails across each cloud account and create a centralized usage report. Your cloud provider has some built-in services to provide IAM analytics, like **[AWS IAM Access Analyzer](https://aws.amazon.com/iam/access-analyzer/)**. Our analytics are different in that our results span usage across all of your cloud accounts, rather than findings for an individual IAM role.

In practice, we’ve found this to be complimentary with analysis tooling like IAM Access Analyzer. Currently, we support entitlements analysis for AWS IAM Identity Center. Want to learn more? Book a live demo using [this link](https://savvycal.com/common-fate/d3c7f2e9).

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/619552eb-8f5d-4a60-ec6f-4ba345683955.png)

## **Common Fate's New and Improved UI**

We're excited to announce the upgraded web UI for our platform, enhancing your experience, particularly focusing on streamlining the Access Requests process. This change also makes it possible to request multiple entitlements at once.

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/a3ae3a44-601a-3416-72fe-2ec5b984a0ae.png)

## **Sunsetting Glide**

Our open-source project, [Glide](https://github.com/common-fate/glide), will be transitioning to a sunset phase, with the project being archived in May. Glide will be put into maintenance now and the project will be archived on 16th May 2024. During the maintenance period, we will publish critical operations or security fixes where required. After the maintenance period, we will archive the project and the project source code will become read-only.

We appreciate all of you for contributing to Glide and our community. However, as a small team, keeping up with multiple projects has proven to strain our resources and is not sustainable. If you are a current Glide user and would like to transition to our identity platform, please contact us, and we'll ensure your transition is smooth and provide support throughout the process. We have more details on why we had to make these decisions in our [blog post here](https://www.commonfate.io/blog/sunsetting-glide).

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for February.

Community Newsletter: February 2024


Today, we would like to make some important announcements:

1. Our open source project Glide is being sunset.
2. Our team’s focus will shift exclusively to Common Fate’s identity platform, which also supports a JIT access use case.

## Sunsetting Glide

We have decided to sunset the Glide open source project.

Glide will be put into maintenance now and the project will be archived on 16 May 2024. During the maintenance period, we will publish critical operations or security fixes where required. At the conclusion of the maintenance period, we will archive the project and the project source code will become read-only.

Existing releases of Glide will remain published for the foreseeable future, including our CloudFormation deployment templates and `gdeploy` deployment CLI.

The main reasons for this decision are:

1. Our broader cloud identity security product, Common Fate, was to be built on top of Glide. During 2023 following user feedback and months of experimentation, we made a number of technical decisions and changes to the Common Fate product. Our codebase has diverged from the open source Glide project.
2. As a result, the differences that now exist between Glide and Common Fate would require us to resource and support both of these projects separately. We are still a small team and this has proven to be a strain on our resources and is not sustainable.
3. We believe that the changes we made to Common Fate during 2023 have improved the product and the overall user experience. This is a great outcome and paves the way for us to build the best product we can.

## Common Fate - Identity Platform

Our goal at Common Fate is to build an identity security platform fit for modern cloud-native teams. We believe that Common Fate’s identity platform is the way we will realise our goal and ultimately provide the greatest value for the greatest number of teams. As such, all of our team’s focus will be on this product from now onward.

Within the identity platform, we currently support the following use cases:

- JIT access for AWS
- JIT access for GCP
- Secure and auditable access for AWS RDS databases
- Risk monitoring and least privilege analytics for AWS Identity Centre

In future, we intend to expand our library of integrations, as well as expand out to non-human identities (more on this in another blog post).

You can read the docs for Common Fate’s identity platform [here](https://docs.commonfate.io/common-fate/introduction/).

## Next Steps

We understand that this announcement could create challenges for your company and we’re here to help. If you need assistance or would like to discuss this with us, please email support@commonfate.io or ping us in our [community Slack](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg). We’re happy to take calls and help your team through this transition as best as we can.

If your team would like to transition from Glide to Common Fate’s identity platform, we’re on hand to help. We’re committed to offering the follow to minimise interruption:

- Hands on migration support.
- Introductory pricing discounts and premium support.
- Glide support up until 16 May 2024.

We appreciate the support of the community to date and look forward to building something great and continuing to service you all.

## FAQs

1. When will Glide be sunset?

   Glide will be immediately put into maintenance mode, with the project archived on 16 May 2024. After this date, the Common Fate team will no longer support or maintain the project.

2. What will happen to past versions of Glide?

   These versions will remain available for the foreseeable future and your team can continue to use them, although they will be unsupported by our core team beyond 16 May 2024.

3. How can I get support?

   The Common Fate team will offer support up until 16 May 2024. If you need support during this transition, please email support@commonfate.io or join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) and ask one of our team members for help.

4. What happens to Granted?

   Nothing. Granted will continue to be supported and maintained by the Common Fate team and the strong community of Granted users.


Our open source project Glide is entering maintenance mode and will be sunset.

Sunsetting Glide


# Community Newsletter: January 2024

Hello everyone, wishing you a Happy New Year! Shwetha, here with the latest tech update. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

## **Common Fate Enterprise RDS Integration**

We're actively working on incorporating audited, just-in-time access to AWS RDS databases within Common Fate Enterprise. Our initial focus is on supporting RDS Instances running Postgres, with plans to extend compatibility to other database technologies like MySQL and SQL Server, as well as other runtimes such as Aurora.

The RDS Database Access Integration utilizes AWS EC2 and SSM Session Manager to facilitate controlled database access. It employs a mechanism where users gain access to the database through port forwarding to an ephemeral database proxy. This proxy is responsible for logging each query, contributing to an audit trail for monitoring and compliance purposes.

If you have a specific use case or request, please don't hesitate to reach out to us or book a live demo using [this link](https://savvycal.com/common-fate/d3c7f2e9).

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/02fc6ea2-8606-49b0-e511-b74af90afc85.png)

## **Granted Updates**

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

**Added better error handling for oauth2 `invalid_grant` error**

we have added better error handling for the oauth2 `invalid_grant` error. Now, whenever this error is encountered, Granted automatically clears the cached token and sends a message.

**Fix for assume --exec with multiple arguments/spaces**

The output from `goassume` when `--exec` is provided now returns the arguments with proper escaping/splitting to ensure they are evaluated when passed to `sh -c` in the `assume` script.

For a comprehensive list of updates, check our [changelog](https://github.com/common-fate/granted/releases).

As the year comes to an end, we want to express our gratitude for being a part of our community. We are so thankful for your support and excited to continue this journey with you into 2024, with exciting things in store. Happy holidays!

Until next time,

The Common Fate Team


Here's our product and community news for January.

Community Newsletter: January 2024


# Community Newsletter: December 2023

Hey everyone, Shwetha here with the last tech update for the year. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

## **Enterprise Privileged Access Management**

Exciting news! The enterprise version of our [open-source privileged access management framework](https://github.com/common-fate/glide) has been officially released and is ready for deployment. This enterprise edition comes with a host of features and integrations designed to elevate your privileged access management capabilities:

- **GCP Support**: JIT access workflows for Google Cloud Platform.
- **Advanced Policy Layer**: Allows for conditional approval based on user and resource attributes, such as tags associated with an account.
- **Managed IAM Policies for GCP and AWS**: Incorporate best practices and secure policies continuously audited and refined by the Common Fate team.
- **On-call Integration**: Grant access automatically when a user is on an on-call rotation with OpsGenie and/or PagerDuty integration.
- **Improved Slack Integration**: Approve Access Requests directly from Slack without needing to open the Common Fate web application.
- **Support**: Support SLA (24x5) with a dedicated Slack Connect channel.
- **SCIM User Provisioning**: User profile synchronization via industry-standard SCIM (rather than custom integrations, as is used in Common Fate OSS).
- **Multi-region and Multi-cloud High Availability**: Host the Common Fate Access Plane workers across multiple regions and cloud providers to improve availability.

Want to learn more? Dive into our comprehensive documentation [here](https://enterprise.docs.commonfate.io/deploy) or book a live demo using [this link](https://savvycal.com/common-fate/d3c7f2e9).

## **Identity Risk Index Assessments**

Looking ahead to the coming year, we are actively developing a free identity risk assessment service. This service aims to help you identify and manage risk in crucial areas such as:

- Excessive Permissions
- Policy Misconfiguration
- Privileged Access

If you’d like a FREE identity risk assessment, let us know [here](https://www.commonfate.io/identity_risk) and we’ll be in touch early in 2024.

## **Granted Updates**

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

**Generate JSON output for SSO token expiry**\
Run granted `sso-tokens expiry --json` to print the SSO token expiry in JSON. Additionally, you can use jq to filter and display only the expired tokens in JSON format: `granted sso-tokens expiry --json | jq -r '[.[] | select(.is_expired == true)]'`

**Added TTY support for --exec**\
`--exec` now uses the shell script to execute commands instead of Go; this enables TTY applications to work as expected.

**ExportSSOToken Configuration and --export-sso-token Flag**\
[@cedieio](https://github.com/cedieio) has introduced the `--export-sso-token` flag, which exports the SSO token to ~/.aws/sso/cache. The ExportSSOToken configuration automatically exports the SSO token by default.

A big shoutout to our first-time contributors:

- [@eserte](https://github.com/eserte) made their first contribution in [#552](https://github.com/common-fate/granted/pull/552)
- [@paulhobbel](https://github.com/paulhobbel) made their first contribution in [#553](https://github.com/common-fate/granted/pull/553)
- [@cedieio](https://github.com/cedieio) made their first contribution in [#518](https://github.com/common-fate/granted/pull/518)
- [@Mallear](https://github.com/Mallear) made their first contribution in [#561](https://github.com/common-fate/granted/pull/561)
- [@XargsUK](https://github.com/XargsUK) made their first contribution in [#559](https://github.com/common-fate/granted/pull/559)

For a comprehensive list of updates, check our [changelog](https://github.com/common-fate/granted/releases).

As the year comes to an end, we want to express our gratitude for being a part of our community. We are so thankful for your support and excited to continue this journey with you into 2024, with exciting things in store. Happy holidays!

Until next time,

The Common Fate Team


Here's our product and community news for December.

Community Newsletter: December 2023


# Community Newsletter: November 2023

Hello everyone! Shwetha here with the latest tech update from Common Fate. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech). Your curiosity and expertise drive our innovations, and we welcome your contributions!

Here's what's been happening in the world of Common Fate over the past month:

## **Rippling and Common Fate**

We were recently featured on Rippling's blog, which discusses how they streamlined AWS access at scale. The blog delves into the integration of the IAM Identity Center with our Just-In-Time access tool, [Glide](https://github.com/common-fate/glide).

[You can read the blog post here](https://www.rippling.com/blog/streamlining-aws-access-with-rippling-at-scale)

![Screenshot 2023-09-29 at 1.21.40 pm.png](https://mcusercontent.com/69860be79239e5e8d492037c9/images/a937b0ed-98fc-8f34-38cd-4c8be686ff45.png)

## **Commercial Privileged Access Management**

Exciting update! The enterprise version of our [open-source privileged access management framework](https://github.com/common-fate/glide) , Glide is set to launch in the first two weeks of December. This version offers hosting options in your preferred cloud environment, and it's compatible with AWS, GCP, PagerDuty, and Slack. Some key features include Just In Time (JIT) access, customizable policies, and unlimited audit retention. We've also streamlined user management with Single Sign-On (SSO) and SCIM.

If you're interested, you can use this [link](https://savvycal.com/common-fate/d3c7f2e9?sid=f9c2dfa8-abc1-4b93-878b-f20975d6bf70) to book a demo or reach out to us with any questions!

## **Granted Updates**

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

- **Chain flag for Inline Role Assumption:** You can now use the new `--chain` flag to assume another role inline. This feature can be utilized in conjunction with either the `--exec` option or as part of a regular profile definition.
- **DefaultExportAllEnvVar config:** You can now include the `DefaultExportAllEnvVar=true` configuration in your `~/.granted/config` file. This configuration will enable the automatic export of all environment variables by default when credential_process is used.
- **ExportCredsToAWS config:** You can also include the `ExportCredsToAWS=true` configuration in your `~/.granted/config` file. This will enable credentials to be exported to `~/.aws/credentials` by default.

**Kudos to our first-time contributors:**

- [@eserte](https://github.com/eserte) in [#552](https://github.com/common-fate/granted/pull/552).
- [@paulhobbel](https://github.com/paulhobbel) in [#553](https://github.com/common-fate/granted/pull/553).

For a comprehensive list of updates, check our [changelog](https://github.com/common-fate/granted/releases).

## **Feedback**

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for November.

Community Newsletter: November 2023


# Community Newsletter: October 2023

Hello everyone! Shwetha here with the latest tech update from Common Fate. If you're eager for deeper insights and real-time updates, make sure to join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech). Your curiosity and expertise drive our innovations, and we welcome your contributions!

Here's what's been happening in the world of Common Fate over the past month:

## **Introducing Common Fate**

We are thrilled to introduce Common Fate, the evolution of our platform, building on the strong foundation of Granted and focusing on enhancing the user experience. Key features include:

- **Comprehensive Visibility:** Effortlessly oversee all your AWS accounts from a single interface for total cloud control.
- **Streamlined Workflow:** Navigate AWS seamlessly, eliminating constant context-switching, and effortlessly move between accounts, regions, and resources.
- **Intelligent Search:** Quickly find what you need with powerful and responsive search capabilities, ensuring you stay proactive in managing your cloud infrastructure.

Common Fate is a promise of security and convenience. It's a desktop application, right on your device, safeguarding your AWS credentials - they never leave your control.

We're actively integrating access management workflows into Common Fate, powered by our [trusted privileged access management framework](https://github.com/common-fate/glide), offering a seamless transition for Glide users.

Join the waitlist at [Common Fate](https://commonfate.io) for an exclusive early experience.
![Screenshot 2023-09-29 at 1.21.40 pm.png](https://mcusercontent.com/69860be79239e5e8d492037c9/images/ccfa0e4e-36b8-7d8d-1441-92561ce7c6ac.png)

## **AWS Confessions**

As we dive into the world of Common Fate, we know that AWS journeys aren't always smooth sailing. So, we created AWS Confessions, the safe haven to anonymously share your unfiltered thoughts and experiences with AWS. It's a place to compare stories and realize you're not alone in this cloud adventure. So, don't hold back – share your confession now at [https://awsconfessions.com/](https://awsconfessions.com/)!

![Group 2383.png](https://mcusercontent.com/69860be79239e5e8d492037c9/images/1a0e7f04-c2f5-5b79-6ab0-b21866e42805.png)

## **Privileged Access, Rebranded**

Our [open-source privileged access management framework](https://github.com/common-fate/glide) has been renamed to Glide. Rest assured, it's only a name change, and nothing else about this project will be affected. If you have any questions or just want to chat, don't hesitate to reach out.
![Glide](https://mcusercontent.com/69860be79239e5e8d492037c9/images/b968ff14-c9e9-caa2-f786-37ad8e0b66a2.png)

## **Granted Updates**

In our ongoing commitment to enhancing Granted, we're excited to share the latest updates:

- **Auto-refresh for Credential Process:** We've introduced automatic credential refresh for roles using the credential process. The default export now covers the AWS_PROFILE environment variable. To export all variables, simply use the `-export-all-env-vars` flag during execution.
- **Waterfox Browser Support:** Thanks to the fantastic work of [@dowster](https://github.com/dowster), we're now compatible with the Waterfox browser. Activate this feature with a simple `granted browser set` and update your browser preference.

**Kudos to our first-time contributors:**

- [@polleydium](https://github.com/polleydium) in [#494](https://github.com/common-fate/granted/pull/494).
- [@Jeff-SearchPilot](https://github.com/Jeff-SearchPilot) in [#510](https://github.com/common-fate/granted/pull/510).
- [@dowster](https://github.com/dowster) in [#512](https://github.com/common-fate/granted/pull/512).
- [@dlambda](https://github.com/dlambda) in [#520](https://github.com/common-fate/granted/pull/520).

For a comprehensive list of updates, check our [changelog](https://github.com/common-fate/granted/releases).

## **Feedback**

Your voice shapes our tools. We value your feedback, suggestions, and ideas, so please don't hesitate to get in touch.

Until next time,

The Common Fate Team


Here's our product and community news for October.

Community Newsletter: October 2023


Since the beginning, our mission at Common Fate has always been clear. We're uniting developers and security teams with an exceptional user experience. We're making the fastest way to get access the most secure way.

Our project Granted is an example of this. Many companies over the past 12 months have standardised on Granted for AWS access. Why have they done this? Granted makes getting access faster, and additionally encrypts AWS credentials. In other words: speed _and_ security.

But when it comes to most access management products, speed and security do not exist in harmony. Many products force employees to context-switch and message a Slackbot. Or, even worse, file an access request ticket into the void and hope for a response this week. These steps add friction. This friction makes these solutions difficult to deploy at scale as end users must change their behaviour to account for the friction. We can speak to this first hand - we made these mistakes in the early days of building our own product.

We digress, back to speed and security. Our product announcement today is about _speed_.

We’re excited to announce our new product, Common Fate. Common Fate extends on our values and the wins we’ve had so far with Granted.


We’ve focused on speed and reducing friction within end user workflows. This brings us a step closer to seamless access management designed for the cloud. Here are some of the ways that we make your day-to-day work faster:

**See the full picture** - connect all your AWS accounts and capture your entire cloud footprint.

<video autoplay loop muted playsinline>
  <source src="/blog_posts/announcement-2023-10-05/full-picture.mp4" />
</video>

**Less context switching** - move faster between accounts, regions and resources.

<video autoplay loop muted playsinline>
  <source src="/blog_posts/announcement-2023-10-05/context-switching.mp4" />
</video>

**Find the needle in a haystack** - powerful and intelligent search without the lag. This is especially useful for CloudWatch logs, which we have native support for.

<video autoplay loop muted playsinline>
  <source src="/blog_posts/announcement-2023-10-05/needle-in-haystack.mp4" />
</video>

Common Fate is available as a desktop application and runs on your own device. The AWS credentials you use with Common Fate stay on your device and don't pass through our servers. We don’t have any access to them.

On the _security_ side, over the coming months we'll be connecting access management workflows into Common Fate. Our [privileged access management framework](https://github.com/common-fate/glide) will power these workflows. This framework is currently used by a number of elite engineering teams across the world and has already delivered significant security wins. We’re looking forward to making this experience available to everyone within Common Fate very soon. Beyond that, we’ll also be adding support for more cloud providers.

You can join the waitlist below. We’re onboarding people deliberately to ensure a high quality experience. We will begin sending invites on Monday next week for the first batch of users so keep an eye on your inbox.


 <div className="mb-8">
  <WaitlistCta />
</div>

Accessing your cloud just got a lot faster with our new desktop client, Common Fate.

Announcing: Speed + Security


# Community Newsletter: September 2023

Hey everyone! Shwetha here with a monthly update for you. If you want to contribute to what we're building or would like more regular weekly updates, please join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past months:

## Granted Updates

We've been hard at work bringing some exciting feature requests to life. Here are a few highlights:

**Introducing the `--exec` Flag with Double Dash (--) Prefix**

- You can now use the `--exec` flag with a double dash (--) prefix to execute more complex commands that involve quotations.

**Support for Specific Browser Profiles**

- We've added support for launching specific browser profiles using the `-browser-profile` flag, compatible with browsers like Chrome, Edge, and Chromium variants.

**New Cache Commands**

- Securely remove cached credentials with `granted cache clear`.
- View available cached credentials and their storage type using `granted cache list`.

**Caching IAM Credentials and MFA Token Code**

- For AWS profiles requiring an MFA prompt, Granted will now cache your credentials. If you can obtain an MFA token through a script, you can use the `mfa-token` flag with `assume` to bypass the MFA prompt.

A big shoutout to our first-time contributors:

- [@wayne-folkes](https://github.com/wayne-folkes) made their first contribution in [#483](https://github.com/common-fate/granted/pull/483)
- [@katsumex](https://github.com/katsumex) made their first contribution in [#465](https://github.com/common-fate/granted/pull/465)
- [@admackin](https://github.com/admackin) made their first contribution in [#437](https://github.com/common-fate/granted/pull/437)

For a comprehensive list of changes, please visit our [changelog](https://github.com/common-fate/granted/releases).

## Common Fate

### Product Launch - Next Week

Next week, we will be launching something we’ve been working on for the past few months. We’re super excited to share it all with you!

Our inspiration for this new product is to create an aspirational AWS experience without needing to migrate infrastructure somewhere else. We can probably all agree that despite AWS providing us with powerful tools we use every day, they are incredibly complex, frustrating to use and feel very slow and ultimately difficult to secure (to put it mildly). We’re going to change this.

Here is a sneak peek of what’s to come next week:

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/d9e7ccdc-f79a-422d-d62f-f4bfd424e4e8.png)

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/060fb11e-4a87-2514-372c-68858a4816a9.png)

## AWS Confessions

In line with our upcoming product launch, a very consistent theme in our discussions with our community members over the past 12 months has been the frustrations associated with using AWS. So we thought we would create a space where we can share our gripes and air our grievances together!

I’m pleased to say that we will be releasing AWS Confessions - a place where you can anonymously say what you really think about your AWS experience and compare AWS horror stories.

We've already seen some great confessions and will open this up to you all next week to enter your own.

![Group 2383.png](https://mcusercontent.com/69860be79239e5e8d492037c9/images/1a0e7f04-c2f5-5b79-6ab0-b21866e42805.png)

## Feedback

As always, we want to hear from you! If you have any feedback, suggestions, or ideas for how we can make Granted and Common Fate even better, please don't hesitate to reach out.

Until next time,

The Common Fate Team


Here's our product and community news for September.

Community Newsletter: September 2023


Community Newsletter: July 2023
================================


Hey everyone! Fraser here with a monthly update for you. If you want to contribute to what we're building, or would like more regular weekly updates, please join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past months:

### Common Fate Cloud - Beta

We're opening up the Common Fate Cloud beta to more users and the product is improving each week. You can keep an eye on what we're releasing in our [Changelog](https://commonfate.notion.site/Changelog-7c8bf06597cb4315838ec93c0896e9ac).  
  
Currently, we support the following:

*   Just-in-time access to AWS, Kubernetes and databases (Postgres).
*   Deep Slack integration - request and approve requests right from Slack.
*   Configurable access triggers - set up automated access, approval rules and incident response workflows for your team.
*   Fine grained auditing of all actions performed against your critical infrastructure. 

[Get Started!](https://savvycal.com/chris-common-fate/cloud-intro "Get Started!")

If you'd like to get started with Common Fate Cloud, click the button above and a member of our team will give you a demo of the product, answer your questions and help you onboard. 

Common Fate and fwdcloudsec
---------------------------

  
We were recently featured in a presentation by Rami McCarthy at the 2023 fwdcloudsec event titled ['Beyond the AWS Security Maturity Roadmap'](https://speakerdeck.com/ramimac/beyond-the-aws-security-maturity-roadmap). Granted and Common Fate Cloud were both featured as solutions in the Scaling Access Management category.

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/0f4aac49-f0b5-df8c-2572-8349c1342b86.png)

Granted
-------

  
We've released some small improvements to Granted recently. Summary below:

*   Request duration added via flag by [@JoshuaWilkes](https://github.com/JoshuaWilkes) in [#432](https://github.com/common-fate/granted/pull/432)
*   Add support for MFA with IAM credentials by [@mfzl](https://github.com/mfzl) in [#429](https://github.com/common-fate/granted/pull/429)
*   Add auto-login flag to credential-process by [@sosheskaz](https://github.com/sosheskaz) in [#418](https://github.com/common-fate/granted/pull/418)
*   Remove grant overlaps error in exp request aws workflow by [@shwethaumashanker](https://github.com/shwethaumashanker) in [#431](https://github.com/common-fate/granted/pull/431)
*   Fix access message when duration flag is used by [@shwethaumashanker](https://github.com/shwethaumashanker) in [#434](https://github.com/common-fate/granted/pull/434)
*   Make assume script a little more robust by [@alexjurkiewicz](https://github.com/alexjurkiewicz) in [#435](https://github.com/common-fate/granted/pull/435)
*   Automated sso populate and removed extra log messages by [@shwethaumashanker](https://github.com/shwethaumashanker) in [#433](https://github.com/common-fate/granted/pull/433)
*   Fixed formatting by [@shwethaumashanker](https://github.com/shwethaumashanker) in [#436](https://github.com/common-fate/granted/pull/436)

Shoutout to [@mfzl](https://github.com/mfzl) who made their first contribution in [#429](https://github.com/common-fate/granted/pull/429).   
  
Full release notes here for  [v0.13.1](https://github.com/common-fate/granted/releases/tag/v0.13.1) and [v0.14.0](https://github.com/common-fate/granted/releases/tag/v0.14.0) here.

### Some amazing love for Granted too!

  
> Stop what you're doing and setup Granted, not tomorrow, not next week, just do it now. I promise it is a simple as it sounds and you'll be wishing you had done it sooner. Everything just works and it greatly improves your workflow.  
  
[Check out the full blog post here](https://dev.to/aws-builders/easy-as-sso-tooling-with-granted-aws-12n9). 

Feedback
--------

As always, we want to hear from you! If you have any feedback, suggestions, or ideas for how we can make Granted and Common Fate even better, please don't hesitate to reach out.

Until next time,

The Common Fate Team


Community Newsletter: July 2023



Community Newsletter: May 2023
==============================

Hey everyone! Fraser here with a monthly update for you. If you want to contribute to what we're building, or would like more regular weekly updates, please join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

Temporal and Common Fate
------------------------

  
Our friends at Temporal have recently written about their experience with Common Fate to date and how it's been important for their security posture. Importantly, by using Common Fate, they've reduced their administrative access by 90% +.   
  
[You can read the blog post here](https://temporal.io/blog/rolling-out-access-hours-at-temporal). 

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/1ccabeed-7b9e-ecf9-6c74-e85c1fcef536.png)


<br/>

Common Fate Cloud - Beta
------------------------

We're delighted to announce that Common Fate Cloud is now in private beta!   
  
Common Fate Cloud is our take on safe production access and mitigates the need to give engineers administrative access roles altogether. Some of the use cases that Common Fate Cloud solve include automated runbooks, secrets operations, technical customer support, and database access.  
  
Over the next few weeks, we will be releasing a bunch of new features and we're eager to take any and all feedback.   
  
If you'd like to be invited to the private beta, please reach out to [hello@commonfate.io](mailto:hello@commonfate.io) and we will send you an invite link. 

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/619bd373-b9fe-24c7-e6e2-770b5effb98b.png)

Here's a sneak peak of the Common Fate Cloud beta and how to get started. 

Granted
-------

  
We've released some small improvements to Granted this month. Summary below:

*   Add AWS 'sm' shortcut for secrets manager by [@alexjurkiewicz](https://github.com/alexjurkiewicz) in [#422](https://github.com/common-fate/granted/pull/422)
*   Add console-destination switch to enable bookmarking, use regional endpoints by [@perpil](https://github.com/perpil) in [#419](https://github.com/common-fate/granted/pull/419)
*   Remove trailing slashes from `granted_sso_start_url` by [@perpil](https://github.com/perpil) in [#411](https://github.com/common-fate/granted/pull/411)
*   Auto detect SSO region using html from sso-start-url by [@perpil](https://github.com/perpil) in [#413](https://github.com/common-fate/granted/pull/413)

Full release notes here for [v0.12.0](https://github.com/common-fate/granted/releases/tag/v0.12.0) and [v0.13.0](https://github.com/common-fate/granted/releases/tag/v0.13.0)

Community Shoutouts
-------------------

  
One of our active community members [@perpil](https://github.com/perpil) has built his own integration with his tool Speedrun and Granted. Check out [#419](https://github.com/common-fate/granted/pull/419) and the demo video below: 

<iframe width="560" height="315" src="https://www.youtube.com/embed/hE_GkDSosBM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

This shows how Granted can be used as a credentials broker with Speedrun.

Upcoming Events
---------------

  
We have some exciting events coming up in the near future! Mark your calendars for:

*   [AWS London Summit](https://aws.amazon.com/events/summits/london/), 7 June 2023. Chris (our co-founder and CTO) will be there in person

Feedback
--------

As always, we want to hear from you! If you have any feedback, suggestions, or ideas for how we can make Granted and Common Fate even better, please don't hesitate to reach out.


Community Newsletter: May 2023


Community Newsletter: April 2023
================================

Hey everyone! Chris here with a monthly update for you. If you want to contribute to what we're building, or would like more regular weekly updates, please join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech).

Here's what's been happening in the world of Common Fate over the past month:

Provider Registry
-----------------

  
We've released the Provider Registry - a central repository that serves as a public database for storing and sharing Access Providers. The Provider Registry allows developers to discover, publish, and deploy Access Providers built by the Common Fate community.

[Read our announcement](https://www.commonfate.io/blog/provider-registry) or visit the registry at [registry.commonfate.io](https://registry.commonfate.io).

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/8b72a880-8862-d14c-d970-9f79f1df253f.png)

### Common Fate featured at AWS Community Day Nordics

  
[Theodoros Mylonidis](https://www.linkedin.com/in/tmylo/), a CloudOps Engineer at [Qred](https://en.qred.se/), gave a presentation at AWS Community Day Nordics this month on how Qred uses Common Fate to manage privileged access to their AWS organisation. Theo has led the deployment of Common Fate at Qred and is an advocate for developer-friendly privileged access workflows.  
 

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/f183dbd7-c0e4-7f32-54d6-866ad2a22bfc.jpeg)

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/7c83fd87-f3ea-14b3-1a6f-3b6573c04c26.jpeg)

Granted user experience improvements
------------------------------------

[Granted](https://granted.dev/) uses the system keychain to securely store cloud credentials. This month, we released improvements to our keychain integration which make Granted a lot faster to use with tools like [kubectl](https://kubernetes.io/docs/reference/kubectl/):

*   [Improved caching of AWS credentials](https://github.com/common-fate/granted/pull/396) (released in [v0.10](https://github.com/common-fate/granted/releases/tag/v0.10.0))
*   [Improved MacOS keychain UX](https://github.com/common-fate/granted/pull/404) (released in [v0.11](https://github.com/common-fate/granted/releases/tag/v0.11.0))

A big thankyou to [Luke Young (@lyoung-confluent)](https://github.com/lyoung-confluent) for contributing these improvements.  
 

Granted CLI Access Requests
---------------------------

  
In [Granted v0.11](https://github.com/common-fate/granted/releases/tag/v0.11.0), team members using the AWS CLI can now request access to AWS roles using Common Fate directly from the terminal. [Read about this in our documentation here.](https://docs.commonfate.io/granted/recipes/access-requests)

![](https://mcusercontent.com/69860be79239e5e8d492037c9/images/f1c10683-feb5-8ca3-6e4b-b0f41e26a973.gif)

Upcoming Events
---------------

  
We have some exciting events coming up in the near future! Mark your calendars for:

*   [AWS London Summit](https://aws.amazon.com/events/summits/london/), 7 June 2023
    *   Chris (myself! Co-founder and CTO) will be there in person

Feedback
--------

As always, we want to hear from you! If you have any feedback, suggestions, or ideas for how we can make Granted and Common Fate even better, please don't hesitate to reach out.

Until next time,

The Common Fate Team

Community Newsletter: April 2023


Last month, we announced the release of our [Access Provider Framework](https://commonfate.io/blog/access-providers), a tool for building integrations with Common Fate.

Today, we are thrilled to introduce the [Provider Registry](https://registry.commonfate.io/), a central repository that serves as a public database for storing and sharing Access Providers. The Provider Registry allows developers to discover, publish, and deploy Access Providers built by the Common Fate community.

Learn how you can deploy an Access Provider from the Provider Registry by following this [deployment guide](https://docs.commonfate.io/common-fate/providers/deploying).

We built the Access Provider Framework and the Provider Registry with the vision of allowing teams to quickly get started with least privileged access specific to the cloud services and technologies that they use.

![A screenshot of the registry.commonfate.io website, showing the 'aws', 'azure-ad', 'cloudwatch-log-groups', and the 'google-workspace' Access Providers](/blog_posts/provider-registry/screenshot.png)

The final piece of this puzzle is allowing members of the Common Fate community to build and publish your own Access Providers. Stay tuned for more updates on this!

We are excited to share the Provider Registry and look forward to further building it out with your feedback and contributions. Together, we can make least privileged IAM more accessible for all.


A central repository that serves as a public database for storing and sharing Common Fate integrations.

Introducing the Common Fate Provider Registry 


Hi everyone.

Welcome to the March 2023 edition of the Common Fate Community Newsletter! If you want to contribute to what we're building, or would like more regular weekly updates, please join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech)!

Here's what's been happening in the world of Common Fate over the past month:

# New Features

**Common Fate**

We've been hard at work developing new features to make the Common Fate experience even better. Here are just a few of the new features we've recently released:

- [Access Providers](https://commonfate.io/blog/access-providers) are here. We can now build integrations with the Core Framework of Common Fate and provision access to virtually any service or application. Check out the release notes [here](https://github.com/common-fate/common-fate/releases/tag/v0.15.0).
- [Provider Development Kit (PDK)](https://github.com/common-fate/common-fate-provider). The PDK makes is super simple to develop and deploy Access Providers using Python.

```go
class Provider(provider.Provider):
    api_url = provider.String()

@access.target()
class Target:
    ...

@access.grant()
def grant(p: Provider, subject: str, target: Target):
    # perform API calls here to grant access
    ...

@access.revoke()
def revoke(p: Provider, subject: str, target: Target):
    # perform API calls here to revoke access
    ...
```

# Coming Soon

A few exciting things we’re working on that are set to be released very soon:

**Provider Registry**

- Very soon, a large library of Access Providers will be released and ready for you all to try.
- In the Registry, all Community built providers and Common Fate built providers will be made available for users.

![A screenshot showing Common Fate's Provider Registry](/blog_posts/community-update-march-2023/common-fate-registry.png)

**Approval Policy Engine**

- Teams can define their own approval workflows and automate the process of handling the granting or revoking of access.
- Depending on how teams wish to handle this workflow, the approval process can be customised to suit a number of uses cases.
- Below the ‘multi-party’ approval workflow has been defined.

![A screenshot showing a proof of concept of the Approval Policy Engine](/blog_posts/community-update-march-2023/approval-policy-engine.png)

**Common Fate Cloud**

- The team is hard at work on a managed, self-serve version of Common Fate which includes additional organisational features for larger teams, compliance features and is supported by an SLA.

- If you’d like to know more, you can [join the waitlist](https://commonfate.io/sign-up) and we will be in touch.

# Community Spotlight

A few shoutouts from this month to Common Fate Community members:

**Granted**

- [decisivedevops](https://github.com/decisivedevops) made his first contribution in [#377](https://github.com/common-fate/granted/pull/377). Thank you for this and appreciate your help updating our documentation.
- Shoutout to [lyoung-confluent](https://github.com/lyoung-confluent) for sharing his thoughts on a new credential store for Granted ([#395](https://github.com/common-fate/granted/issues/395)). Thank you and appreciate your first contribution.
- Thanks to dsech for opening issue [#390](https://github.com/common-fate/granted/issues/390) regarding allowing a specifying destination profile with `assume --export`
- Thank you to [matthewhembree](https://github.com/matthewhembree) for suggesting another improvement to Granted in [#387](https://github.com/common-fate/granted/issues/387).
- Thanks to [jhuntwork](https://github.com/jhuntwork) for contributing an improvement to our shell support in [#389](https://github.com/common-fate/granted/pull/389).

**Common Fate**

- A bunch of other community members using Common Fate have made some excellent UX suggestions. We really appreciate this feedback!
- special thanks to: Shreyas Damle, Brandon Sherman, Flavio Elawi, David Behroozi, Mike Peachey and Alex Jurkiewicz just to name a few.

If you want to be part of the action, [join our Community Slack here](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg).

# Upcoming Events

We have some exciting events coming up in the near future! Mark your calendars for:

- [AWS Sydney Summit](http://aws.amazon.com/events/summits/sydney/?trkCampaign=aws-summit&trk=), 4 April 2023 (next week)
  - Josh (engineer), Ellie (product) and Jack (engineering) will all be there
- [AWS London Summit](https://aws.amazon.com/events/summits/london/), 7 June 2023
  - Chris (co-founder, CTO) will be there in person

# Feedback

As always, we want to hear from you! If you have any feedback, suggestions, or ideas for how we can make Granted and Common Fate even better, please don't hesitate to reach out.

Until next time,

The Common Fate Team


Community Newsletter: March 2023


One of the unique problems you encounter when building a framework to manage internal access is that your framework itself needs sensitive permissions to be able to automate access to things.

Let’s say that we want to automate permissions in GitHub. Using the framework, a user might want to temporarily elevate their access to a repository, so that they can set up some secrets in GitHub Actions.

That’s great (and good on your users for keeping secrets out of their source code) — but it means the framework itself needs permissions which allow roles to be created.

This problem is something we’ve been thinking a lot about as we build [Common Fate Cloud](https://commonfate.io/sign-up). Sure, self-hosting everything is certainly an option, but we think that having a third party (like us) keeping your internal access workflows running helps avoid nasty cascading issues if you have an outage you need to deal with. We want to provide a managed permissions orchestration service with an SLA to boot, but we don’t want to force you to hand over the keys to your kingdom.

We’ve built something that helps to solve this problem, and we call it the Access Provider framework.

## Anatomy of an Access Provider

First and foremost, an Access Provider’s main job is to hold the credentials required to automate permissions. Sometimes, these credentials are static secrets like API keys. In the case of access to cloud providers like AWS, GCP, or Azure though, the credentials might also be short-lived session tokens attached to a certain role.

_(Also, if you’re interested, we’ve written about [how we mitigate secrets being logged in Go](https://commonfate.io/blog/prevent-logging-secrets-in-go-by-using-custom-types))_

As I mentioned in the GitHub access example above, we need to have these credentials _somewhere_ in order to automate role assignments, so we’ll give them to the Access Provider.

![A diagram showing an Access Provider connected to some credentials](/blog_posts/access-providers/access-provider-1.png)

An Access Provider’s second job is to keep these credentials safe, and not give them to anyone — not even Common Fate. To achieve this, we designed a restrictive API around the Access Provider which has four permitted actions: `Grant`, `Revoke`, `Load`, and `Describe`.

![A diagram showing Common Fate connecting to an Access Provider. The connection shows Grant, Revoke, Load, and Describe as available API calls](/blog_posts/access-providers/access-provider-2.png)

When your tireless developer requests access to the GitHub repository, Common Fate uses the `Grant` and `Revoke` actions to trigger the Access Provider. The Access Provider then calls GitHub’s API with its credentials to create and remove the role.

The `Load` action is used to determine who has access to which resources, and `Describe` runs a health-check on the Access Provider.

This approach means we can treat the internals of an Access Provider as totally opaque — heck, we don’t care if the Access Provider is dialing [@ashtom](https://twitter.com/ashtom)’s mobile phone to provision access — as long as it is successfully provisioned when we ask. Treating the internals as opaque gives us the nice property we’re looking for, in that Common Fate has no knowledge or direct access to sensitive credentials.

The last piece of Access Providers is how they are hosted. Access Providers are packaged as serverless functions and run in your own cloud environment (not Common Fate’s). At the moment, we support running Access Providers in AWS Lambda, but we’re working on support for Azure Functions and Google Cloud Functions too. Using serverless functions for this has frankly been great, as it allows us to use cloud-native IAM permissions to ensure that **only** Common Fate can trigger the Grant/Revoke/Load/Describe actions. We’ll write more about this soon.

You can take a look at our AWS Lambda Access Provider implementation [here](https://github.com/common-fate/common-fate-provider/blob/main/commonfate_provider/runtime/aws_lambda.py).

## Access Providers Released

We’ve been working towards having Access Providers since the initial release of Common Fate. [Our latest release v0.15](https://github.com/common-fate/common-fate/releases/tag/v0.15.0) contains the full implementation of the Access Provider framework. From this release onwards, Access Providers will be developed and released independently of our core framework.

If you’d like to learn more about how to set up Access Providers you can [get started in our docs](https://docs.commonfate.io/common-fate/providers/providers).


Our framework for building integrations with Common Fate.

The Access Provider Framework


Below is what we've been working on the past month or so and what we're focusing on next. If you want to contribute to what we're building, or would like more regular weekly updates, please join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or follow us on [Twitter](https://twitter.com/CommonFateTech)!

# Product Updates

**Common Fate**

We've shipped a bunch of improvements to Common Fate in 2023.

- Released the Common Fate Terraform provider.
- Improvements to Google Workspace IDP integration
- Use Granted to populate local AWS config file with roles from Common Fate Access Rules

For a full change log, head to our release notes for [v0.12.1](https://github.com/common-fate/common-fate/releases/tag/v0.12.1) and [v0.13.0](https://github.com/common-fate/common-fate/releases/tag/v0.13.0).

**Granted**

We've implemented some improvements to Granted in 2023. Check out the below:

- Update to Granted Profile Registry.
- Adding support for a custom template when generating profiles from SSO.
- Ability to open a CLI and a console at the same time with a one liner (`assume -t -c`)
- Improvements to automatic profile generation, including `--prune` to remove stale generated profiles ([docs here with usage examples](https://docs.commonfate.io/granted/usage/automatic-config-generation))

For a full change log, head to our release notes for [v0.6.0](https://github.com/common-fate/granted/releases/tag/v0.6.0), [v0.7.0](https://github.com/common-fate/granted/releases/tag/v0.7.0) and [v0.8.0](https://github.com/common-fate/granted/releases/tag/v0.8.0).

# Community & Content

We love hearing what you have to say, so here's a roundup of our latest Requests for Discussion (RFD) and recent activity.

- [Common Fate Terraform Provider](https://github.com/common-fate/rfds/discussions/9): some excellent discussions in here and really appreciate the detailed feedback from [Zordrak](https://github.com/Zordrak) and support from [nicgrayson.](https://github.com/nicgrayson)

Have something you want to shout about? The RFD repo is always open, [drop us your thoughts here](https://github.com/common-fate/rfds).

### Community Spotlight

We're very grateful for our community contributions and product feedback. Here's a shout out to a few community members who have contributed to our projects recently:

- Shout out to [@holly-evans](https://github.com/holly-evans) for helping us improve our CLI help text ([#364](https://github.com/common-fate/granted/pull/364)). Thanks for catching this Holly!
- Thanks [@vdesjardins](https://github.com/vdesjardins) for adding support for a custom template when generating profiles from SSO ([#327](https://github.com/common-fate/granted/pull/327)).
- Thanks to [@connorads](https://github.com/connorads) for helping make SSO generate/populate expected behaviour much clearer on the Granted project ([#332](https://github.com/common-fate/granted/pull/332)).
- Shout out [@grantjoy](https://github.com/grantjoy) for improving logging around waiting for the browser ([#321](https://github.com/common-fate/granted/pull/321)). Cheers Grant.

### Latest Blog Posts

- [Granted Profile Registry, levelled up](https://commonfate.io/blog/profile-registries-v2)
- [Command palette for accessing the cloud](https://commonfate.io/blog/command-palette-v1)
- [Common Fate Terraform provider is here](https://commonfate.io/blog/terraform-provider)

# Events

Common Fate team members will be attending the [AWS Sydney Summit in April 2023](https://aws.amazon.com/events/summits/sydney/). To anyone else going along, please get in touch and let us know. Coffee is on us.

## Thanks for reading!

If you'd like to hear more from us, join our [Slack](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) and follow us on [Twitter](https://twitter.com/CommonFateTech). See you around!


Community Newsletter: February 2023


_Don't like reading? Check out a quick demonstration [here](https://www.loom.com/share/5ee3324326024854bfa5a0adf1223a58)._

Manage your IAM resources via Terraform? Now you can manage your Common Fate Access Rules via your Terraform workflow too!

Currently, the only way for users of Common Fate to create Access Rules is via the admin panel on the frontend. We chatted with our community and this seemed like a pain point. So we listened, and in [RFD #9](https://github.com/common-fate/rfds/discussions/9) we discussed the idea of a Common Fate Terraform Provider.

Fast forward a few weeks, and we have a freshly baked Terraform Provider!

So what does this all actually mean?

- Quickly and programmatically manage the life cycle of Access Rules with Terraform.
- Closely couple the creation of Access Rules with other cloud resources, like AWS IAM Identity Centre resources.

Here’s an example:

```hcl
resource "commonfate_access_rule" "s3-example" {
  name ="s3ListBuckets"
  description="Allows users to view buckets in AWS"
  groups=["common_fate_administrators"]
  target=[
    {
      field="accountId"
      value=["123456789012"]
    },
    {
      field="permissionSetArn"
      value=[aws_ssoadmin_permission_set.example.arn]
    }
  ]
  target_provider_id="aws-sso-v2"
  duration="3600"
}
```

Great! Now how do you get started? If you already have a Common Fate deployment [visit the docs](https://registry.terraform.io/providers/common-fate/commonfate/latest/docs). Don’t have a Common Fate deployment yet? Get started in 5 minutes [here](https://docs.commonfate.io/common-fate/deploying-common-fate/deploying-common-fate)!

Let us know how you go, we’d love to hear from you!


Manage your IAM resources via Terraform? Now you can manage your Common Fate Access Rules via your Terraform workflow too!

Common Fate Terraform Provider


At Common Fate we want to make our user experience as fast as possible, so you can get on with your work. We put some thought into this, reflected on the SaaS apps we love and launched our own command palette feature!

True to our core values, we started out simple. Currently, the command palette allows you to search through Access Rules and easily find what you’re looking for.

Our goal is to make the Common Fate dashboard feel like the terminal to the Cloud. We want you to be able to make an Access Request without leaving your keyboard.

We have some grand plans for the command palette, but we’d love to hear what your ideal search feature looks like and prioritize implementing that! [Join our community Slack](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) and flick us a message, we’re always keen to take your feedback!


Getting access to the cloud just got a lot faster with Common Fate’s command palette.

Our Command Palette for Accessing the Cloud


Back in November we [released Profile Registries](https://commonfate.io/blog/granteds-profile-registry) - an easy way of centralising your AWS config file across your team, and syncing it with [Granted](https://github.com/common-fate/granted). Based on Profile Registries v1, we got some excellent feedback from [Eric](https://github.com/sosheskaz) and [Loren](https://github.com/lorengordon) ([RFD #2](https://github.com/common-fate/rfds/discussions/2#discussioncomment-4192655)), and collaboratively made some changes.

We value our community and our highest priority is to build products you love! If you see an opportunity like this, don’t hesitate to reach out, we always love to collaborate. You can get in touch via our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or by posting an [RFD](https://github.com/common-fate/rfds).

## Handling duplicate profile names

When multiple registries are in use, registries are synced in descending priority where the default priority is zero. This allows you to consistently define which registry config should be prefixed upon duplication.

## Variable substitution for profile configurations

Variable substitution allows you to set variables within your profile configurations and have them be automatically populated by predefined key-name pairs. Additionally, these values can be user specific and defined from CLI prompts. Variable substitution can also be used for arbitrary variables, allowing you to reuse a variable within your config file.

Here’s an example:

```yaml
awsConfig:
  - ./dev/config1
templateValues:
  - <YourKeyName>
    - ...
  - BaseProfile:
    - value: "my-profile"
  - SessionName:
      - isRequired: true
      - prompt: "Enter your user name (e.g john.doe)"

[profile prod]
session_name = {{ .Required.SessionName }}
role_arn = arn:aws:iam::0123456789012:role/example

[profile uat]
source_profile = {{ .Variables.BaseProfile}}
role_arn = arn:aws:iam::0123456789012:role/example
```

You can get started with Profile Registries [here](https://docs.commonfate.io/granted/usage/profile-registry/).

Let us know how you go, we’d love to hear from you!


Profile Registries have had an update! Granted now handles duplicate profile names, and allows variable substitution for AWS profile configurations.

Granted's Profile Registry Leveled Up


Before we started Common Fate in September 2021, we were building a cloud consulting business. We worked with clients from many different sectors: enterprise, defence, startups and everything in between.

During this time, we saw the pain of permissions management first-hand. Many teams have embraced continuous deployment and cloud-native development, resulting in developers being brought closer to production environments. Teams need access to CI/CD systems, cloud providers, source control management systems, and many other services to develop modern software. This has led to an access management nightmare for security teams, with some dealing with hundreds of access requests per week from engineers.

[Least-privileged access is a hard problem](https://commonfate.io/blog/who-cares-about-least-privilege), and it seemed like security teams faced a dilemma: allow team members to have excessive permissions in order to move quickly, or restrict permissions to minimise risk?

Many teams opted for the former - we saw that platform engineers and SREs at many companies were simply granted full administrative access to production, just in case there was an incident that they needed access to respond to.

Overprivileged access presents a real business risk for companies. [Earlier this year, compromise of a single Uber employee’s identity](https://www.wired.com/story/lapsusdollar-uber-rockstar-breach-multifactor-authentication-weaknesses/) resulted in breaches of multiple critical internal applications.

Our view is that this is as much a workflow problem as it is a security problem. We saw the need for a framework which allowed fast workflows for teams to access permissions when needed, while allowing visibility and oversight from a company’s security team. In order for teams to adopt it, the framework should have excellent developer experience. The framework must also be extensible enough to provision permissions in all applications that software teams use day-to-day.

With this vision we founded Common Fate.

The name “Common Fate” comes from the [Gestalt Law of Common Fate](https://isle.hanover.edu/Ch05Object/Ch05CommonFate_evt.html): the phenomenon that elements moving together are perceived as a wider whole. For us, this means software and security teams moving together to build greater products.

We’re excited to announce our seed funding round of $3.1M USD from Work Bench, Haystack and Essence VC to help us unite software and security teams and we’re very thankful to be partnered with investors of this calibre as we navigate the next phase. The funds will be used to accelerate development of the Common Fate platform and the [Granted](https://granted.dev/) open source project, plus continue to support our growing developer community.

You can read more about our recent funding announcement in [TechCrunch here](https://techcrunch.com/2022/12/13/common-fate-wants-to-make-it-easier-to-provide-privileged-access-for-developers/).

We’re extremely fortunate to have met so many talented security and engineering professionals and very grateful for all contributions made to Granted to date and Common Fate’s roadmap. If you’d like to join our community, [please click here](https://commonfatecommunity.slack.com/ssb/redirect). We’d love to have you!

As we accelerate product development and work closely with early users, we’re looking to add a [Community Success Engineer](https://commonfate.io/careers) to our team. We’re very open to a discussion around defining suitable roles in cloud security and engineering, even if we don’t have the role advertised. Please reach out to us at [careers@commonfate.io](mailto:careers@commonfate.io) if you’d like to chat with us.


We’re excited to announce our seed funding round of $3.1M USD from Work Bench, Haystack and Essence VC to help us unite software and security teams.

Announcing Our $3.1M Seed Raise


How many times have you copy-pasted your local AWS SSO profiles to your team members because the ones they had were outdated? We get it. We have been there ourselves. Consistently sharing AWS profiles needs a defined workflow when you have a large number of AWS Permission Roles.

To alleviate this and to ease the onboarding of new members to your team effortlessly, we have introduced a new feature of Granted: **Profile Registry**.

The idea is to create a git repository (a profile registry) which is a central store of AWS profile configuration. Any changes to the AWS config will now not only be consistent but also version controlled and reviewed. You can now let Granted sync the config to your local machine and update your local AWS config file regularly. 🎉

If you have a monorepo setup with multiple config files dedicated to subset of your engineering team then you can only sync those profiles by specifying them in granted.yml config file like this:

```yaml
awsConfig:
  - ./devFolder/feat1Config
  - ./devFolder/feat2Config
```

This will now only sync “feat1config” & “feat2config” files inside “devFolder” when user runs the following command:

```bash
granted registry add
```

### Usage Guide:

1.  If you are new to Granted then follow [this link](https://docs.commonfate.io/granted/getting-started) for installation.
2.  To create a Profile Registry and copy the contents of your local AWS config file into Granted, run the command below. This will create a new _granted-registry_ folder with a _granted.yml_ config file. Now, push this to your git hosting service.

```bash
granted registry setup
```

1.  You can add any git-based repository to Granted's Profile Registry. By default, Granted looks for a _granted.yml_ file in the root of the repository. To add a repository to Granted's Profile Registry, run the following command:

```bash
granted registry add ${YOUR-REPO-GIT-URL}.git
```

Granted allows you to specify a repository subfolder for your Profile Registry's configuration. Should you wish to specify a subfolder, run:

```bash
granted registry add ${YOUR-REPO-GIT-URL}.git/${subfolder}
```

Granted allows you to specify an alternative YAML file for your Profile Registry's configuration. Should you wish to specify a different YAML file, run:

```bash
granted registry add ${YOUR-REPO-GIT-URL}.git/${subfolder}/${filename.yml}
```

‍

For more details, you can always checkout [our documentation](https://docs.commonfate.io/granted/usage/profile-registry) or join our [Slack community](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg).


Managing AWS SSO profiles across your team can be hard. Here to make your life a whole lot easier - Granted's Profile Registry!

Granted's Profile Registry


According to most companies that sell security tools, the world is a dangerous place. Hackers are everywhere. They’re crawling around in your EC2 instances, in your employee laptops, in your Gmail inboxes. They’re hiding behind your watercoolers and under your meetings tables and in your breakout booths. Half of your employees are hackers. Hell, your CISO is probably a hacker too — you should fire her and buy more tools.

Billions of dollars are spent around this issue. State-of-the-art WAFs, AI-assisted endpoint protections, eye-wateringly priced security logging solutions that take entire teams just to set up and manage — and yet almost zero care seems to be directed towards one of the simplest and most cost-effective defenses: least privilege.

I’d like to state upfront that this won’t be a persuasive article. I have no grand idea to sell you, no concrete answer to this problem that we’re facing. I’m the Developer Advocate for a company that makes least privilege workflow software, which means the bulk of my job is arguing in comment sections about why least privilege even matters. This article, if anything, is a cry for help.

All I can really do is share the things that we’ve discovered while working in this space, and hope that you’ll share your own insights too. And maybe then we can start thinking about how to solve this thing.

So then why _do_ so few organizations bother to properly scope employee privilege?

### Problem 1: They think it’s about trust

Imagine, for the sake of argument, that there is a lava pit in the middle of your office. Most of your co-workers are so used to the lava pit that they don’t even notice it’s there, while a few others have actually created entire geothermic systems that require the lava pit to function. Occasionally someone will fall into the lava pit, suffer grievous injuries, and then be sent into lava pit awareness training.

One day you meet with one of the infrastructure teams to discuss how maybe instead of having lava pit awareness training, we should just get rid of the lava pit. The outrage is immediate: we’ve always had the lava pit! Too many systems rely on it! Getting rid of the lava pit would mean redesigning the entire floor!

Out of all these objections, one of them seems to stand out the most: _but we trust our people to not fall into it._

Of course, it’s a ridiculous argument. No one _chooses_ to fall into the lava pit, just as no one chooses to get phished. But it’s one of the more difficult points to argue against. As an engineer, it’s hard to not feel patronized when your lava pit is taken away. Sure, maybe _other_ people in the company are incompetent goons — but you’d _never_ fall into the pit. You’re too smart for that.

Accepting least privilege means admitting to yourself that no matter how smart and good at computers you might be, sometimes shit happens — and you are not immune to it. This is a difficult realization for anyone.

### Problem 2: Move fast, break things

No one ever got seed funding for not getting hacked.

Many growth-focused companies tend to sacrifice security in favor of pushing out their product quicker. The narrative is usually “we’ll make it secure once we’ve actually built it”. The issue is that security debt works just the same way that tech debt does — all these oversights and shortcuts accumulate to eventually make any sort of positive change almost impossible. Giving people sweeping amounts of access results in them creating workflows that rely on that over-privileged access, and as more time passes those processes become more ingrained. Removing people’s access is a hell of a lot harder than just not having given them that access in the first place.

This is a problem that mostly applies to startups and rapidly scaling companies (large business have no problem putting red tape around every single access request and process — most of their executives probably have KPIs based around doing so).

### Problem 3: What’s your job again?

Implementing least privilege requires actually knowing what all your coworkers do.

That’s an easy enough thing if you work in an organization where everyone has clearly defined roles and never has to step outside those roles to help someone else or meet a changing requirement. But you don’t work in that organization, because it doesn’t exist and we live in Hell.

Any good least privilege architecture must assume that people will sometimes need to do things outside their roles. Overly broad permissions are dangerous, while extremely scoped permissions can limit cross-team functionality and kill creativity. It’s not an easy balance to strike, and ultimately this requires a lot of communication between the security team and everyone else — which, let’s face it, is a whole other article.

### Problem 4: It’s all business, baby

This is a section that I hesitate to add, and if it’s included in the final article then it’s only due to the good grace and patience of the people who pay me. But there’s a problem in the business of security: and it’s the _business_ part.

In an earlier company I worked at, I once met with the CFO to request budget approval for a new security hire. I will never forgot what he told me: “What’s the ROI on security?”

I could have replied “what’s the ROI on looking both ways when you cross the street?”, but I didn’t. That was a line that came to me months later, when I was still the only security hire and still bitter about the meeting.

At the time, I thought the CFO was naive and had no business sense. But he was right: there _is_ no ROI on security, only on security optics.

Good security can save you lots of money years down the line, but businesses don’t work on a timescale of years. They work in quarters. Investors want to see what you’ve achieved in the past three months, and telling them that you’ve become unhackable by buying a machine-learning anti-virus is a hell of a lot more impressive than telling them you’ve taken away Dylan’s root access to all the customer data. The first one lets you show off slides full of cool graphs and mean-looking falcon logos, and the second one gets people asking: why the \*\*\*\* did Dylan have root access to all the customer data?

The problem, of course, is that buying the cool anti-virus is often a lot cheaper and less problematic than taking away Dylan’s access. So, here we are.

### Problem 5: Implementation

In security, the most interesting (and difficult) problems tend to involve people, not technology. Unfortunately, most least privilege solutions are blatantly anti-people.

No one wants to fill out a Google document and then figure out who to email it to just to get access to a basic part of their job. No one wants to look at tickets on a kanban board just to figure out who they need to give access to. And no one wants to go through all the IAM roles to discover that the penetration tester from two years ago still has AWS access just because no one remembered to revoke it.

So that’s why we’ve created [Common Fate](https://commonfate.io/), an open-source developer workflow tool that helps you request and approve specific, timeboxed permissions with just a few clicks.

What? Did you think we were going to write this whole thing without advertising our product even once? Nah.

### So what do we do about all this?

Honestly? I don’t know. On a more granular level, each of the above problems have their own solution. Talk to your coworkers about how you _trust_ them, you just don’t want to take unnecessary risks. Make sure to do good security design _before_ you need to pay KPMG $25 million to fix it for you. Talk to your coworkers about what their jobs actually are. Check out our [Github repo](https://github.com/common-fate/granted-approvals), etc. etc.

On a more holistic level, many of these problems are underpinned by a common factor: an organization’s inability or unwillingness to properly map out their structure and commit to designing better permission workflows. The inability part can be solved with a bit of time and strategy — the unwillingness part, not so much.


Everyone knows that least privilege is a foundational part of secure design. So then why do so few organizations seem to care about it?

Who Cares About Least Privilege?


At Common Fate, we decided to open source our software for one simple reason: users have the right to know what’s running on their machines and in their environments. We don’t believe that our software development processes can or should be insulated from our users, their experiences or their critiques.

So, the next obvious step was to create an [RFD repo](https://github.com/common-fate/rfds). Broadly, our RFD process will follow the same philosophy as [NWG’s RFC 3](https://www.rfc-editor.org/rfc/rfc3):

_The content of a note may be any thought, suggestion, etc. related to the software or other aspect of the network. Notes are encouraged to be timely rather than polished. The minimum length for a note is one sentence. These standards (or lack of them) are stated explicitly for two reasons. First, there is a tendency to view a written statement as ipso facto authoritative, and we hope to promote the exchange and discussion of considerably less than authoritative ideas. Second, there is a natural hesitancy to publish something unpolished, and we hope to ease this inhibition._

We want to emphasize the fact that we welcome _all_ discussion and feedback on our tools, our development process or any other aspect of how Common Fate functions as a company.

We’re also particularly keen to hear feedback from people in demographics that have been sidelined and discriminated against in tech, since we understand that such users are often wrongly lead to believe that their opinions are not as valuable as others.

# When to start an RFD

Here are some examples of when we might open an RFD:

- Adding or changing a company process
- An architectural design decision impacting the existing software or proposed a new feature
- A change that affects the way people use our tools, especially if it could break integrations or impact their workflow
- Changes to our public-facing strategies, such as the way we write content, manage our social media or do developer advocacy

Of course, we also welcome our users to open RFDs for any ideas, suggestions, concerns they may have.

If you have an idea for a discussion but don’t know if it might be too trivial or silly — just post it! We want to hear from you. Our Developer Advocate isn’t afraid of looking dumb when he makes our [Twitter posts](https://twitter.com/CommonFateTech/status/1552457541061586945), so you shouldn’t worry either.

Participating in RFDs
All our open RFDs will be in the [Discussions tab](https://github.com/common-fate/rfds/discussions) of our [RFD Github repo](https://github.com/common-fate/rfds). Check out the [pinned discussion](https://github.com/common-fate/rfds/discussions/1) for info on how to start your own RFD.


We're starting an RFD process!

Our RFD Process


In our codebase for [Granted Approvals](https://docs.commonfate.io/granted-approvals/introduction/), we’ve got a structure that looks like this:

```go
type Provider struct {
    OrgUrl string
    APIToken string
}
```

In this case, we’ve got a value named _apiToken_. It’s a secret, and we’d rather it doesn’t get leaked somewhere. Your secret value could also be an API token, or maybe it’s a password or a user address or anything else that you don’t want to get a Privacy Act lawsuit for.

The trouble with storing your secrets in strings like this is that it’s very easy to accidentally log them. It only takes one _fmt_ or _zap_ line for your secret value to be printed in plaintext and then possibly even sent to your external logging solutions. Using unexported fields can help, but Zap will still include them anyway.

If you’re reading this, then you probably already know why having sensitive data in your logs is dangerous. If you don’t, you can check out [this](https://www.theregister.com/2022/05/27/github_publishes_a_post_mortem/). Or [this](https://www.bleepingcomputer.com/news/security/twitter-admits-recording-plaintext-passwords-in-internal-logs-just-like-github/). Or [this](https://techcrunch.com/2022/07/26/justalk-spilled-millions-of-user-messages-and-locations-for-months/). Or…. you get the point.

And if you’re rolling your eyes and saying _I’d never log sensitive data_, I’d ask: are you sure? You’re never going to accidentally type the wrong variable name in your print function? You’re never going to have a new dev join your team? Nobody on your team is ever going to be one night away from a deadline debugging why the hell the password reset function isn’t working and just go _screw it, I don’t get paid enough to care about security anyway_? I’m not so sure.

**Our solution**: custom types.

```go
type Provider struct {
    OrgUrl StringValue
    APIToken SecretStringValue
}
```

Now instead of _orgUrl_ and _apiToken_ being type _string_, they’re now _StringValue_ and _SecretStringValue_. Both of these custom types provide a small abstraction over a standard string type:

```go
type StringValue struct {
    Value string
}

type SecretStringValue struct {
    Value string
}
```

The part that’s important to us though is how they both implement the [Stringer](https://go.dev/tour/methods/17) and MarshalJSON interfaces:

```go
func (s StringValue) String() string {
    return s.Value
}

func (s StringValue) MarshalJSON() ([]byte, error) {
    return json.Marshal(s.String())
}

func (s SecretStringValue) String() string {
    return "*****"
}

func (s SecretStringValue) MarshalJSON() ([]byte, error) {
    return json.Marshal(s.String())
}
```

The String() implementation for _SecretStringValue_ will only return the redacted string “\*\*\*\*\*”, and same goes for the JSON. This makes it a whole lot more difficult to accidentally log the secret by just plugging it into fmt or zap.

So now, if you’re got something like:

```go
oops := Provider{OrgURL:"commonfate.io",APIToken:"secret"}
fmt.Printf("%s", oops.APIToken)
```

or:

```go
oops := Provider{OrgURL: "commonfate.io", APIToken: "secret"}
b, \_ := json.Marshal(oops)
fmt.Print(string(b))
```

All you should hopefully get in return is `********` or `{"OrgUrl":"commonfate.io","APIToken":"\*\*\*\*\*"}`

Is it totally foolproof? No. You can still log the secret if someone decides to deliberately print the Value, but at least now the team has clearer context on whether or not something is intended to be a Secret or just a regular Value. It makes it just that little bit harder to make a mistake — and in security, that’s all we can really ask.

If you want to check out the code for yourself, here’s a [Go Playground link](https://go.dev/play/p/Ha3ade158vi). And if you’re interested in seeing how we’ve implemented this in our own project, you can check out our [gconfig package](https://github.com/common-fate/granted-approvals/tree/main/pkg/gconfig).

p.s.: you can totally just use string aliases instead of custom types too. we found that custom types work better for our implementation, but here's an example with [string aliases](https://go.dev/play/p/v1AR9qrbNl7) too.


A quick post on how we make it harder to log secrets in Go.

Prevent Logging Secrets in Go by Using Custom Types


_Don't like reading? Check out a demonstration [here](https://www.loom.com/share/580e7bf3aeaa4843b672a5f33e5d7d86)._

It’s 4:30pm on a Friday afternoon. There are 52 access request tickets in your Security kanban board. One of your policy guys spent a week putting together a template for permission requests, but no one actually cares enough to use it. Over half the tickets don’t have the Reason field filled out, and even fewer have specified a Duration. While setting up permissions for one user, you notice that a pentester you contracted two years ago still has cloud admin access.

The newest DevOps hire is already considering going back to college. The Risk team has given up. Even the CISO can barely afford her therapy bills anymore. You try to blink away the tired, but it only makes your eyes burn more.

It’s 5pm on a Friday afternoon. There are 51 access request tickets in your Security kanban board.

If your job is anywhere adjacent to cloud security, then this has probably been you at some point. Maybe this is you right now. But what if we told you that there’s a better way — and that it’s free and open source?

Introducing: _Granted Approvals_.

![](/blog_posts/granted_new_access_request.png)

![](/blog_posts/granted_access_requests.png)

Granted Approvals is a privileged access management framework that you can self-host in your own AWS environment right now, today. We’ve worked hard to make this a tool that streamlines your access pipeline, with a key focus on:‍

**Simplifying access**: set up rules defining who can request access to what, and the resource owners who can approve access.

**Seamless integration with your services**: install Access Providers to provision fine-grain access to your SaaS services and cloud providers. Current support for AWS SSO, Okta groups, and Azure AD groups.

**Fast and vocal approvals**: approve access with just a few clicks, and connect to your team’s communication tools like Slack.

**Auditability**: see past and upcoming access requests. No more pulling all-nighters right before your ISO audits.

Concerned about security? Us too. We’ve designed Approvals so that it only has the ability to assign roles to existing users, rather than create new roles or new users. By design, the blast radius of Granted Approvals being compromised is that existing users in your directory could be granted access to roles, rather than external users being created. Better yet — Approvals is deployed as a serverless application which runs in your own AWS account, so Common Fate won’t have access to any data in your Granted Approvals deployment. Check out our [Security Architecture](https://docs.commonfate.io/granted-approvals/security-architecture) page — and if you’re still not convinced, send us your concerns over [Slack](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg) or [Twitter](https://twitter.com/CommonFateTech).

You can get started with Approvals over at our [Introduction](https://docs.commonfate.io/granted-approvals/introduction) page, or check out our [Github repo](https://github.com/common-fate/granted-approvals). It’s still in early access, so we’d be totally chuffed if you’ve got any feedback or bug reports you want to send our way.

Stay in touch, and happy ClickOps-ing.


An open source privileged access management framework which makes requesting access a breeze.

Granted Approvals - an Open Source Permission Management Framework


# What is Granted?

Granted is a command line interface (CLI) application which simplifies access to cloud roles and allows multiple cloud accounts to be opened in your web browser simultaneously. The goals of Granted are:

- Provide a fast experience around finding and assuming roles;
- Leverage native browser functionality to allow multiple accounts to be accessed at once; and
- Encrypt cached credentials to avoid plaintext SSO tokens being saved on disk.

# Why we created Granted

As cloud practitioners we follow best practices and use [multi-account environments](https://aws.amazon.com/organizations/getting-started/best-practices/). This frequently led to situations where we were cross-referencing resources or viewing logs across multiple accounts. When using the AWS console this becomes quite painful as only one account and region is accessible at a time per browser.

Yes, one way to solve this is to simply stop using the console and develop your own abstractions and visualisation layer on top of AWS's APIs. However, we believe the native console can be a useful tool for viewing your cloud resources; namely because you don't need to build anything yourself in order to use it.

An additional motivation on developing Granted is the way that the AWS CLI handles session credentials when using AWS SSO. We're big fans of AWS SSO as it removes the need for long-lived IAM credentials; however the AWS CLI stores [the SSO access token in plaintext](https://aws.amazon.com/premiumsupport/knowledge-center/sso-temporary-credentials/). If this token is compromised it can be [painful to revoke](https://stackoverflow.com/questions/65848394/how-to-revoke-a-user-session-when-using-aws-sso). Granted offers an improvement over the AWS CLI in this regard, as the SSO access token is stored in the system's keychain rather than on disk.

We've been using Granted internally for all our cloud access at Common Fate for the past few months and we've found it's greatly increased our productivity when working in the cloud.

# Give it a try

To get started using Granted in AWS, follow this [Getting Started](https://docs.commonfate.io/granted/getting-started) guide and you will be up and running in about 5 minutes.

# Let us know what you think

You can take a look at the open source project on GitHub [here](https://github.com/common-fate/granted).

If you have any questions or need some help getting started, please reach out to one of our team members over in our [Slack channel](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg).


We’re pleased to announce the release of our new open source tool, Granted.

Granted - Open Source Release


[IAM Power Editor](https://editor.iamzero.dev/) was created to alleviate some of the pains associated with Identity and Access Management (IAM) policy creation.

Here are some of the pain points we identified

- Wasted time looking up ARNs or Privilege descriptions
- Time spent fighting syntax and spelling errors
- Unknowingly introducing vulnerabilities

Welcome to [Power Editor](https://editor.iamzero.dev/). Sift through 9000+ privileges in just a few key presses, ARN's are instantly recommended, their input/validation is streamlined. Additional statements can be added via hotkey, and your policy will be checked in real time for syntax errors or other bugs (thanks [Parliament](https://github.com/duo-labs/parliament)!).

We'll be incrementally making improvements to Power Builder over coming months and we would love to hear your feedback.

Common Fate is creating novel solutions to the inherent problems facing Identity and Access Management in the Cloud.


IAM Power Editor was created to alleviate some of the pains associated with Identity and Access Management (IAM) policy creation.

IAM Power Editor - Initial Release


Our major focus this release was core usability features to make IAM Zero useful for developers in a day to day environment. We're not fully there yet - we aim to fix [#27](https://github.com/common-fate/iamzero/issues/27) and [#28](https://github.com/common-fate/iamzero/issues/28) in v0.3.0 which should make IAM Zero usable for AWS day-to-day to help you build least-privilege permissions.

# Reworked policy editor

IAM Zero now groups permission issues recorded for the same token and policy together into a more convenient interface!

![](/blog_posts/reworked_policy_editor.png)

# Support for multiple tokens

In v0.1.0, we only supported a single token (set as an environment variable). This has now been improved and we support multiple tokens to help you identify actions coming from different services or team members. Our v0.2.0 supports using DynamoDB and in-memory token stores (if you'd like support for a different storage backend please let us know in our [Slack](https://join.slack.com/t/commonfatecommunity/shared_invite/zt-q4m96ypu-_gYlRWD3k5rIsaSsqP7QMg)) and we aim to improve performance here in future releases by caching tokens in our event collection endpoint.

![](/blog_posts/multiple_token_support.png)

# Initial support for hosting IAM Zero as a service

At Common Fate we are now running an internal deployment of IAM Zero hosted on AWS ECS. We're working on documentation to provide a deployment guide for IAM Zero. If you're interested in deploying IAM Zero to build least-privilege permissions in a team environment we'd love to hear from you so that we can best package IAM Zero as a CloudFormation deployment.


Our major focus this release was core usability features to make IAM Zero useful for developers in a day to day environment.

IAM Zero - v0.2.0 Release


A month ago I made a [post](https://www.reddit.com/r/aws/comments/mlfbcw/i_built_a_tool_which_automatically_suggests/) about IAM Zero, a tool which detects IAM issues and suggests least-privilege policies.

It uses an instrumentation layer to capture AWS API calls and send alerts to a collector - similar to how Sentry, Rollbar, etc capture errors in web applications. The collector has a mapping engine to interpret the API call and suggest one or more policies to resolve the issue.

The response from the post has been overwhelmingly positive (a big thankyou to all of you in the [r/aws](https://www.reddit.com/r/aws/) community for sharing your IAM pain points) - so I decided to spend the last month building IAM Zero to get it ready enough to be released as open source. I've also set up an open-source [company](https://commonfate.io/) to provide long-term support for the tool.

Website here: [https://iamzero.dev/](https://iamzero.dev/)

The initial release has automatic least-privilege advisories for S3 and DynamoDB, and will be scaled out to support all AWS services prior to a stable release. IAM Zero currently supports applications and scripts written in Python with support for other languages coming soon. Support for generating infrastructure-as-code deployment roles and requesting roles through the AWS web console are on the [roadmap](https://github.com/common-fate/iamzero/projects/1).

IAM Zero is released under the Apache 2.0 licence [on GitHub](https://github.com/common-fate/iamzero) - we're planning on separating the least-privilege advisory library as a separate repository with an API which could be integrated into other projects too (currently the library is part of the main repository). Let me know if you'd be interested in this.

If you're interested in testing IAM Zero I'd love to hear from you via comment or DM. Any feedback is welcome too.
