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.
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.
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.