Common Fate Terraform Provider

[meyerjrr]

Background

Currently the only way for users of Common Fate to create access rules is via a deployment in the admin panel of the front-end.

Something that has become apparent to us internally is that many users already have processes in place to manage the creation and lifecycle of IAM resources in AWS (including IAM management!).

The purpose of this RFD is to explore the development of a Common Fate Terraform provider. Which would enable users to fit Common Fate workflow rules into their Terraform at build time!

The desired effect of having a Common Fate Terraform provider would be the speed and simplicity gained by being able to build access rules into pre-existing Terraform workflows.

I think this can be best showcased through some proof of concept examples of what we were thinking! Keep in mind these are just proof of concept Terraform code samples, and have been shortened for simplicity.

Example 1:

AWS Identity Centre provider for IAM Access

module "permission_sets" {
  source = "https://github.com/cloudposse/terraform-aws-sso.git//modules/permission-sets?ref=master"

  permission_sets = [
    {
      name               = "GrantedAdministratorAccess",
      description        = "Allow Full Access to the account",
      policy_attachments = ["arn:aws:iam::aws:policy/AdministratorAccess"]
    }
  ]
  context = module.this.context
}

resource "commonfate_access_rule" "dev-admin-access" {
  name               = "Developer Admin Access"
  description        = "Allow engineers to request access to an admin role for the developer account"
  target_provider_id = "aws-sso"

   target {
    field = "accountId"
    value = ["123456789012", "123434589012"]
  }

  target {
    field = "permissionSetArn"
    value = [permission_sets.GrantedAdministratorAccess.permissionSetArn]
  }

duration = "12h"

request [
{
	type = "group"
	value = "developers"
},
{
	type = "user"
	value = "[email protected]"
},
]

approval [
{
	type = "user"
	value = "[email protected]"
},
{
	type = "group"
	value = "cf-admins"
},
]
		
}

Example 2:

AWS Saml SSO provider for privilege escalation (prototype)

resource "aws_iam_role" "test_base_role" {
  name = "test_base_role"

  # Base role to be assumed by okta sso
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      },
    ]
  })

  tags = {
    tag-key = "tag-value"
  }
}

resource "aws_iam_role" "test_escalated_role" {
  name = "test_escalated_role"

  # Common Fate escalated role
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect =  "Allow",
        Action =  "*",
        Resource = "*"
      },
    ]
  })

  tags = {
    tag-key = "tag-value"
  }
}

resource "commonfate_access_rule" "saml-sso-example" {
  name               = "Rule Name"
  description        = "Allow engineer to escalate their privilege with Common Fate"
  target_provider_id = "aws-saml-sso"

  target {
    field = "baseRoleArn"
    value = [aws_iam_role.test_base_role.arn]
  }

  target {
    field = "escalatedRoleARN"
    value = [aws_iam_role.test_escalated_role.arn]
  }

duration = "2h"

request [
{
	type = "group"
	value = "developers"
},
]

approval [
{
	type = "user"
	value = "[email protected]"
},
]
}

These Terraform examples would then create the necessary AWS resources and then create the Common Fate access rules which can then be managed in the apps frontend. With developers able to request access to the created resources.

The Terraform code would mimic that of the create access rule interface that you would find in the admin UI.

Challenges

• This would introduce the challenge of drift to Common Fate. Which is a challenge in itself. This would mean challenges if users wanted to create resources via CF and Terraform.

Expansions

• Cloud Posse style prefabs to create all the resources necessary to manage your AWS account permissions + creating best practice Common Fate rules to be able to provision and de-provision those managed resources.

Would be keen to hear some thoughts on this approach to creating and managing access rules!

[nicgrayson]

This is a great idea. I already configure my aws sso permission sets and other iam resources with terraform so I would use this provider in a heartbeat.

[Zordrak]

This is a killer feature for me and one I've been hoping for since day 1. This is the final piece of the puzzle in making a properly enterprise solution where all the configuration can be stored as code allowing for completely repeatable deployments; supporting end-to-end path-to-live testing and total production resilience; along with the simplicity of one-touch deployment with everything in one terraform component.

Every justification that exists for Infrastructure as Code applies to the ability to configure this application as code.

Common Fate is also in the lucky position of being a Go development shop which is an enormous benefit to the question of whether a terraform provider can be created and maintained to a high quality standard.

As to the question of whether it would only be a boon to the terraform-user I think the question is actually deeper than just whether to operate a terraform provider, the question is whether to operated an API that allows modification of the running configuration. If the API exists and is a first-class alternative to the web user interface for config modification, then the terraform provider is only one of many options. The next step is the Granted Go SDK that enables any developer to easily write Go to interact with the configuration API; and then finally the terraform provider would be the best-in-class (because terraform is best-in-class) way to make use of the configuration API. The Granted CLI is then another api-client making use of the SDK - and anyone who wants to operate a different way can do so. You could write a Lambda-backed Custom CloudFormation resource if you wanted to, where the Lambda operated on the API such that it presented CloudFormation with a way to control the configuration. You would effectively become agnostic to the solution the customer wanted to use, but supporting a terraform provider would be an enabler to the widest audience. Even a customer using CloudFormation for their AWS infrastructure could still make use of the terraform provider so as to effect their application configuration as code, for want of any alternative mechanism.

To play devil's advocate the only other useful option I can see would effectively be to declare the entire configuration as a JSON String that is fed into the application environment at launch time; but there are several objections I would have to such an approach; not least the requirement to relaunch the application to make change and how one would manage run-time drift. It's an alternative option that doesn't require an API or provider, but one I don't think I would enjoy trying to make use of. I would feel like I was back in the world of trying to manage Jenkins configuration through EC2 userdata. What a nightmare.

Hope that helps.