Carta has experienced tremendous growth since our founding in 2012. As the company grew, our cloud infrastructure was growing rapidly. Carta’s cloud infrastructure is all on AWS. We had a legacy setup with a handful of AWS accounts.
- Managing user identity across AWS accounts was getting tedious and manual
- Management for the AWS accounts was via Terraform but it would still have some policy drift
- More scalable and secure infrastructure without causing any disruptions to production account
The above challenges were occuring and for a fast-growing company, waiting to address these challenges creates larger issues down the road.
Traditional way
There are tons of silicon valley startups and tech giants all over the world are using public clouds like AWS, GCP, Azure, etc.
It is a general practice that a lot of cloud infrastructure teams use AWS service Identity & Access Management (IAM) for controlling users, roles, and permissions policies. And Carta is no exception to this.
When users are managed by IAM, they can be created manually from the console or with the Terraform module, Infrastructure as a code. In most cases, infrastructure teams will have a naming standard (highly recommended) for IAM usernames, roles, policies, etc. selecting whichever standard is easiest for them to maintain consistency across various AWS environments. These environments are commonly staging, production, etc, and they are segregated within different AWS accounts.
The problem with the traditional approach:
- Maintaining consistency in naming standards
- Manual user account management per AWS account
- Rotating user access keys & passwords with policies
- Not easily scalable while going multi-account or even multi-cloud
AWS Organizations
AWS Organizations is a service used for managing all the AWS member accounts, including the management account also referred as the master account, programmatically and for grouping or applying policies.
Integration with external identity provider is done from the management AWS account. AWS SSO service supports SAML 2.0 integration with Single Sign-On applications like Okta, OneLogin, etc. & System for Cross-domain Identity Management (SCIM) standard for automating the process of provisioning groups and users from external IDP.
The safest way of doing it!
It is always tedious and risky to change the identity for your live management account whether for staging or production environment. Carta already had multiple AWS environments and we opted to go with setting up a new AWS management account from scratch, this can be completely empty.
The process is...
- Setup a new management AWS account. It will require a valid email address, contact information, and billing card. We highly recommend using an email distribution list with a naming standard, it will make things easily readable when you receive any notifications on emails, for example,
Tech+management-account@company.com and Tech+production-account@company.com
- Integrate AWS SSO service with your external identity provider with SAML 2.0. Carta was able to use Okta once it supported full integration.
- Move your existing member AWS accounts under the new management AWS account by making them standalone first and then enrolling them to the new management AWS account. Existing resources like EC2 instances, S3 buckets, etc will not be affected. It is highly recommended to test out with sandbox environment first and have AWS support on-call during production environment migration.
- Configure the SCIM integration which requires a Base URL (SCIM endpoint) and an access token generated from AWS SSO, it will allow auto-provisioning, de-provisioning, and group push automatically from your external IDP.
Note: This will change the default billing for member accounts to the new management AWS account. The consolidated billings will be under the new management account.
Access key rotation
The user access keys are valid for a maximum of 12 hours which includes the console access session and programmatic access with CLI. This means there is now one less thing for Carta’s Infrastructure or Security team to manage or keep eyes on. Any active session which requires more than 12 hours of time should be done with a service account.
AWS CLI v2 supports direct integration with AWS SSO and you can create profiles that are linked to SSO accounts and roles. The CLI will automatically retrieve AWS credentials from SSO and refresh them on your behalf.
AWS CLI v2 will create .aws file on your local directory containing a config file and credentials file. And users can update the config file for setting up the access profile and the users will not need to configure keys all the time.
$ aws configure sso SSO start URL [None]: https://your-sso-url/start
SSO Region [None]: us-east-xAttempting to automatically open the SSO authorization page in your default browser. If the browser does not open or you wish to use a different device to authorize this request, open the following URL: https://device.sso.region.amazonaws.com/
Then enter the code:ABCD-EFGH Successfully logged into Start URL: https://d-1234567890.awsapps.com/start
Once it is authenticated with CLI, it will list all the AWS accounts that user has access to. Config file can be modified with profile names and directly call out specific AWS account from CLI like
$ aws sso login —-profile profile_name
The users will need to use aws sso login & aws sso logout commands for starting and terminating a session.
Multiple role assignments
AWS SSO uses permission sets similar to IAM policies which are only used for AWS accounts, they are not used to manage access to cloud applications. The permission sets could be either custom made or managed policies. The permission sets are used across AWS Organizations and a single user can be given access to an AWS account with multiple roles. We always want to go with least-privileged access for reducing the risk.
Scalability for multi-account & multi-cloud architecture
“Even scalable clouds fails to scale sometimes and that is the day lightning falls on you”
Centrally managed identity is scalable and easy to manage when the infrastructure team decides to implement multi-account architecture or going multi-cloud in a possible future.
It is always a good practice to centrally manage cloud identity with no dependencies on any of your existing infrastructure. Externally managed identities will open up lot of possibilities by adding more flexibility to your overall cloud infrastructure.
Thank you so much!
