Before my time, part of the AWS Infrastructure was built and put into production. Unfortunately as a PoC was rolled into Production without a roadmap, I inherited a number of security concerns.
The What and the Why
We had a number of separate production accounts for each business (Good) but inside those accounts were both production and development workloads (not so great), but the real issue was the disconnect from our ‘single point of truth’ - Active Directory (bad).
The majority of our business applications (Gsuite / Atlassian stack) utilise Active Directory as an identity provider, some more clunky than others (Atlassian Crowd). However, the user accounts for our AWS accounts were utilising IAM, with no standard or structured policies or enforced MFA & password policies.
With the expectation we would be moving the majority of our systems into AWS, it was crucial to find a way to address:
- Single Point of Truth
- Enforced MFA
- Multiple options for MFA (Google Authenticator & SMS)
- Scalable (Doubling our accounts when we split Production & Development)
- Ephemeral Credentials (Specifically CLI)
- Operate under the principle of Least Privilege
The Who
AWS SSO
Initially it made sense to look into AWS SSO. We are an AWS shop with no plans moving to other cloud providers, so the ‘locked in’ factor wasn’t an issue.
The basic configuration is to create an AD Connector In the N.Virginia region (only region currently supported by AWS SSO), if your Domain Controller is in a different region (as ours was) just create a peering connection between the VPCs.
Disappointingly AWS SSO doesn’t include MFA built in, so a Radius server is required, this can be achieved for free, there are a number of github projects out there offering open source solutions (I was able to utilise AWS SNS as well to enable SMS MFA).
As SSO assumes a role when authenticated, CLI Credentials are ephemeral and can be issued up to 12hrs at a time - this is far better security than users creating their own CLI Credentials that persist. One of the great features AWS SSO has implemented is easy to access CLI Credentials, once signed in, users are presented an option to log into the aws console or generate CLI Credentials
One drawback of AWS SSO is currently the options for mapping policies to roles are limited. You can assign up to 10 AWS Managed Policies (not Customer Managed Policies), or an inline policy, this really limits the easy customisation of roles.
Okta
Okta has been around for close to a decade and specialises in SSO, they have a catalog of integrations making it easy to add SSO to most SAML supported services.
Setting up Okta with AWS is fairly straight forward, it involves setting Okta as an identity provider in IAM and creating a user for Okta to list roles in the Okta Settings. To join Okta to Active Directory, you can download the AD agent and setup a sync.
Roles & Policies are managed in individual accounts, however as they are standard roles, Customer Managed Policies can be used.
Another benefit for Atlassian users, is Okta offer a SAML broker agent for Jira and Confluence to remove the requirement of Crowd as an authenticator.
CLI access is more difficult with Okta, they currently offer a Java app to request credentials which is not ideal but it does the job.
The Verdict
We went with Okta, whilst AWS SSO shows alot of promise especially the CLI Credentials generator, Okta feels more polished and integrates with more services seamlessly.
The one drawback with Okta has been their CLI tool, however there are a few ways around this, the one we implemented I’ll cover in another post.