
# 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


Here's our product and community news for July.

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.


Here's our product and community news for May.

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.
