How Segment uses Okta to Secure Access to Dozens of Accounts

Guest post by Evan Johnson, lead security engineer at Segment

Segment receives billions of events from our customers daily and has grown into dozens of AWS accounts. Expanding into many more accounts was necessary in order to best align with our GDPR and security initiatives. In order to continue scaling gracefully, we are centrally managing employee access to AWS with terraform and our identity provider.

To organize the expansion into numerous accounts, we needed a mechanism to control our accounts, which accounts employees have access to, and each employee’s permissions in each account.

Segment uses Okta as an identity provider and consulted their integration guide for managing multiple AWS accounts. The integration guide recommended connecting the identity provider to one AWS “hub” account and using sts:AssumeRoleto access each spoke account. This is the classic “hub-and-spoke” architecture.

We used terraform and wrote reusable modules in order to simplify the process of creating roles that were accessible from our identity provider. We could then write terraform to create granular IAM policies and roles for each team, that could be accessed by Okta! One simple example of a granular policy is the role of our Financial Planning and Analysis (FP&A) team, who keeps a close watch on our AWS spend. Our FP&A team only has access to billing information and information about our reserved capacity.

    module "fpa" {
      source = "git@github.com:segmentio/terracode-access//modules/okta-role"
      name       = "fpa"
      idp_arn    = "${module.idp.idp_arn}"
      policy_arn = "arn:aws:iam::aws:policy/job-function/Billing"
    }
    resource "aws_iam_policy" "fpa_reserved_policy" {
      name        = "fpa_reserved_policy"
      description = "FP&A team needs ability to describe our reserved instances."
      policy = <<EOF
    {
      "Version": "2012-10-17",
      "Statement": [
        {   
          "Action": [
            "ec2:GetHostReservationPurchasePreview",
            "ec2:DescribeReservedInstancesModifications",
            "ec2:DescribeReservedInstances",
            "ec2:DescribeHostReservations",
            "ec2:DescribeReservedInstancesListings",
            "ec2:GetReservedInstancesExchangeQuote",
            "ec2:DescribeReservedInstancesOfferings",
            "ec2:DescribeHostReservationOfferings",
            "ec2:CreateReservedInstancesListing"
          ],  
          "Effect": "Allow",
          "Resource": "*" 
        }   
      ]
    }
    EOF
    }
    resource "aws_iam_role_policy_attachment" "fpa_reserved_attach" {
      role       = "fpa"
      policy_arn = "${aws_iam_policy.fpa_reserved_policy.arn}"
    }

After providing employees with their roles, we needed the tooling to provide our employees with an amazing engineering experience. Even though this system is far more secure, we couldn’t justify this change if it was overly burdensome to our engineers.

In order to access AWS using this new IAM architecture, our tooling team built a near drop-in replacement for aws-vault. This replacement is called aws-okta and it works using a SAML assertion instead of IAM user credentials. It is now open-source and available on GitHub.

The aws-okta login subcommand will log in to a specified role in only a couple of seconds after our engineers respond to the Duo push notification. This feature is supported by the AWS Custom Federated Login feature but feels more like magic when using it.

Beyond 100 accounts

This system we have built is plenty robust and usable enough to scale our AWS usage to many hundreds of AWS accounts and many more engineering teams.

Deleting all employee AWS keys was extremely satisfying from a security perspective, and this alone is a compelling enough reason to integrate your identity provider with your AWS hub account.

_______________________________________________________________________________

For a more detailed explanation, read on the Segment blog