
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/early-access) 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


Here's our product and community news for March.

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/early-access). 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!


Here's our product and community news for February.

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.
